前言: 最近在看设计模式,本文仅作为第一次学习设计模式的笔记。 仅作为学习参考。如有不足,希望各位大神能指出,我修改。

另外,所有的设计原则不是绝对的,要根据实际项目作出相应的妥协和调整才能达到最好的效果。 本文仅说明理论,具体的 需要“代码量的积累”和“写前的思考” 才能实现。

单一职责原则:SRP


  • 定义:应该有且仅有一个原因引起类的变更。 即 “一个职责一个接口”。 职责分明,结构清晰。
  • 例如:用户的属性和用户的行为,需要分开写成两个接口。 一个为用户的行为,一个为用户的属性。

  • 原话:There should never be more than one reason for a class to change.
  • 好处:
    1. 降低类的复杂性
    2. 可读性提高
    3. 可维护性提高
    4. 耦合性降低,变更引起的风险降低

里氏替换原则:LSP


  • 定义:只要父类能出现的地方子类就可以出现。 其中包括4层: 1.子类必须完全实现父类的方法 2.子类可以有自己的个性 3.覆盖或实现父类的方法时输入参数可以被放大 4.覆写或实现父类的方法时输出结果可以被缩小

  • 目的:增加程序的健壮性,添加子类,原有子类还可以继续运行。 传递不同的子类完成不同的业务逻辑。

依赖倒置原则:DIP


  • 含义: 1.高层模块不能依赖底层模块,模块都应该依赖其抽象 2.抽象不应该依赖细节 3.细节应该依赖抽象

  • 实现: 1.模块间依赖抽象,实现类之间不发生直接的依赖关系,其依赖关系通过接口或抽象类产生的 2.接口或抽象类不依赖于实现类 3.实现类依赖接口或抽象类

  • 好处:减少类间的耦合性,提高系统的稳定性,降低并行开发引起的风险,提高代码的可读性和可维护性。

  • 写法:如何模板依赖抽象? 1.构造函数传递依赖对象 2.Setter方法传递依赖对象 3.接口声明依赖对象

  • 最佳实践: 1.每个类尽量都有抽象类或接口 2.变量的表面类型尽量是接口或者是抽象类 3.任何类都不应该从具体类派生 4.尽量不要覆写基类的方法

接口隔离原则:ISP


  • 定义:客户端应仅依赖它需要的接口 1.客户端不应该依赖它不需要的接口 2.类间的依赖关系应该建立在最小的接口上

  • 写法: 1.接口要尽量小,职责单一,符合单一职责。 2.通过业务逻辑压缩接口中的public方法(满身筋骨肉)

  • 最佳实践: 1.一个接口只服务于一个子模块(业务逻辑) 2.通过业务逻辑压缩接口中的public方法(满身筋骨肉) 3.已经污染了的接口,尽量去修改,风险大用适配器模式。

迪米特法则:LoD


又叫“最小知识原则”

  • 定义:一个对象应该对其他的对象有最少的了解。 即 一个类应该对自己需要耦合或调用的类知道得最少。
  • 四层含义: 1.只与直接的朋友交流 2.朋友间也是有距离的 3.是自己的就是自己的 4.谨慎使用Serializable

  • 写法:编写时 反复斟酌: 1.是否可以减少public的方法和属性 2.是否可以加上private、protected、package-private 3.是否可以加上final(防止被继承)

开闭原则:OCP


原话:Software entities like classes ,modules and functions should be open for extendsion but closed for modifications. 直译:软件实体应该对扩展开放,对修改关闭。 实体包括:逻辑模块、抽象和类、方法

  • 定义:开闭原则是对前5个原则的总结,前五个原则对开闭原则的具体解释。

  • 写法: 1.抽象约束 2.元数据(配置参数,来源于数据库、本地文件)控制子模块 3.指定项目章程 4.封装变化

  • 好处: 1.减少测试压力 2.提高代码复用性 3.提高项目可维护性 4.面向对象开发的要求

最后,开闭原则是项目的最终目标,不可能百分百做到,但朝着这个方向努力,可以改善架构,永远拥抱‘变化”,百变我不怕。