一、单一职责原则。
Single Responsibility Principle，应该有且仅有一个原因引起类的变更，实际中比较不好把握，因为职责的划分没有一个统一的标准。
二、里氏替换原则。
Liskov Substitution Principle，通俗点讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。
三、依赖倒置原则。
Dependence Inversion Principle，高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象
不应该依赖细节；细节应该依赖抽象；在Java语言中的表达就是，模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；接口或抽象类不依赖于实现类；实现类依赖接口或抽象类。
四、接口隔离原则。
Interface Segregation Principle，建立单一接口，不要建立臃肿庞大的接口，接口尽量
细化，同时接口中的方法尽量少。（单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要求接口的方法尽量少。例如一个接口的职责可能包含10个方法，这10个方法都放在一个接口中，并且提供给多个模块访问，各个模块按照规定的权限来访问，在系统外通过文档约束“不使用的方法不要访问”，按照单一职责原则是允许的，按照接口隔离原则是不允许的，因为它要求“尽量使用多个专门的接口”。）
五、迪米特原则。
Law of Demeter，一个对象应该对其他对象有最少的
了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的这么多public方法，我就调用这么多，其他的我一概不关心。
六、开闭原则。
Open Closed Principle，软件实体应该对扩展开放，对修改关闭，其含义是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。
总结：
之所以有这么多的原则来指导我们进行程序的设计和开发，是因为我们的程序存在未知的改变。为了以最低的代价拥抱这种未知的变化，前辈们给我们总结了这么多原则，开闭原则应该是每一个大师的终极目标。在所有这些原则中，很重要的一环就是抽象类和接口的灵活运用。后面的23种具体的设计模式也是对“变化“的总结。
阅读(5461) | 评论(1) | 转发(6) |
