[设计模式]Java程序设计原则

1. 单一职责原则

类被修改的几率很大，因此应该专注于单一的功能。如果你把多个功能放在同一个类中，功能之间就形成了关联，改变其中一个功能，有可能中止另一个功能，这时就需要新一轮的测试来避免可能出现的问题。
遵循单一职责原的优点有：

a.可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多;
b.提高类的可读性，提高系统的可维护性;
c.变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。

2. 开闭原则

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
简单的用一句经典的话来说：过去的事已成历史，是不可修改的，因为时光不可倒流，但现在或明天计划做什么，是可以自己决定(即扩展)的。

3. 依赖注入或倒置原则

这个设计原则的亮点在于任何被DI框架注入的类很容易用mock对象进行测试和维护，因为对象创建代码集中在框架中，客户端代码也不混乱。有很多方式可以实现依赖倒置，比如像AspectJ等的AOP（Aspect Oriented programming）框架使用的字节码技术，或Spring框架使用的代理等。

4. 里氏替换原则

一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别，也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化

例子：在生物学分类上，企鹅是一种鸟，但在编程世界里，企鹅却不能继承鸟。在面向对象设计时，子类拥有父类所有非private的行为和属性，鸟会飞，但企鹅不会飞，所以企鹅不能继承鸟类。

5. 接口隔离原则

接口隔离原则讲的是：使用多个专门的接口比使用单一的总接口要好。换言之，从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小的接口上的。
一个接口相当于剧本中的一种角色，而此角色在一个舞台上由哪一个演员来演则相当于接口的实现。因此，一个接口应当简单地代表一个角色。如果系统涉及到多个角色的话，那么每一个角色都应当由一个特定的接口代表。

采用接口隔离原则对接口进行约束时，要注意以下几点：
a. 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
b. 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
c. 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。