单一职责原则（Single Responsibility Principle） There should never be more than one reason for a class to change. （一个接口或一个类只有一个原因引起变化） 在一定的业务场景下如果类A去实现职责a,职责b，这时候应该定义类A去实现职责a，类B去实现职责b。但是需求有时候是会不断变化的，这就需要从项目的实际去考虑了。通常的做法就是：接口一定要做到单一职责，方法尽量做到单一职责。 好处：1.类的复杂性降低，实现什么职责都有清晰明确的定义；2.可读性提高；3.可维护性提高；4.变更引起的风险降低。里氏替换原则（Liskov Substitution Priciple） If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T,the behavior of P is unchanged when o1 is substituted for o2 then S is a type of T.(如果对每一个类型为S的对象o1,都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都替换成o2时，程序P的行为没有发生变化，那么类型S就是类型T的子类型) 通俗的讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误和异常。 四层含义：1.子类必须完全实现父类的方法。2.子类可以有自己的新的方法。3.覆盖或实现父类的方法时输入参数可以被放大。4.覆盖或实现父类的方法时输出结果可以被缩小。 在类中调用其它类时务必使用父类或接口，然后每个子类对应不同的业务含义，传递不同的子类就可以完成不同的业务逻辑。依赖倒置原则（Dependence Inversion Priciple） Hign level modules should not depend upon low level modules,Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.(高层模块不应该依赖底层模块，两者都应该依赖其抽象。抽象不应该依赖细节。细节应该依赖抽象。) 模块间的依赖应该通过抽象发生，其实就是“面向接口编程”。 依赖通常有三种写法：1.构造函数传递依赖对象。2.setter方法传递依赖对象。3.接口声明依赖对象（方法中的参数为接口）. 在实际开发中应注意几点：1.每个类尽量都有接口或抽象类（工具类除外）2.变量的表面类型尽量是接口或抽象类（以接口或抽象类声明变量）3.任何类都不应该从具体类派生（项目处于开发阶段时）4.尽量不要覆写基类方法。接口隔离原则（Inteface Segregation Priciple） Clients should not be forced to depend upon interfaces that then do not use.（客户端不应该依赖它不需要的接口） 1.接口应该尽量细化，接口中的方法应该尽量少，细化时首先必须满足单一职责原则（两者不同在于，单一职责原则是从业务角度出发的）。2.接口要高内聚。3.定制服务。 在实践过程中可以根据几个规则去衡量：1.一个接口只服务于一个子模块或业务逻辑。2.通过业务逻辑压缩接口中的public方法。3.已经污染了的接口，尽量去修改，若变更风险较大，则采用是配给模式进行优化。迪米法特原则（Law Of Demeter） 一个对象应该对其它对象有最少的了解。 四层含义：1.只和朋友交流（朋友类是指出现在成员变量和方法输入输出参数中的类，不包括方法体内部的类）。2.朋友间也有距离（尽量减少public方法和属性）。3.是自己的就是自己的（如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，就放在本类中）。4.谨慎使用Serializable开闭原则（Open Close Priciple） Software entities like classes,modules and functions should be open for extension but closed for modifications.（一个软件实体如类、模块和函数应该对扩展开放，对修改关闭）。 应该尽量通过扩展软件实体的行为来实现变化（逻辑变化，子模块变化，可见视图变化），而不是通过修改已有代码的方式。 实际运用： 1. 抽象约束 a. 通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法 b. 参数类型、引用对象尽量使用接口或抽象类。 c. 抽象层尽量保持稳定。 2. 元数据控制模块行为 使用配置参数控制模块行为。 3. 制定项目章程 约定优于配置 4. 封装变化 a. 将相同的变化封装到一个接口中 b. 将不同的变化封装到不同的接口中
秦小波《设计模式之禅》
转载请注明原文地址: https://ju.6miu.com/read-7413.html
