面向对象 -- 六大设计原则

面向对象

1. 单一职责原则 -- SRP（Single Responsiblity Principle）

There should never be more than one reason for a class to change 。通俗来讲，系统中的每一个类应该具有单一职责，该类的所有服务都应该聚焦在实现该职责上。当你的每一个对象都只有一个改变的理由时， 你已经争取地实现单一职责原则。

单一职责的优点

1. 类的复杂度降低，实现的职责都有清晰明确的定义
2. 可读性提高，复杂性降低
3. 可维护性提高，可读性提高
4. 使得变更引起的风险降低，此时，一个接口的修改只对相应的实现类有影响，对其他接口无影响，这对系统扩展，维护性都有很大帮助。

如何划分类的职责

一个类到底负责哪些职责，这些职责该如何细化，细化后是否都要有一个接口和类，这要从实际项目中出发。

• 单一职责适用于接口，类以及方法
• 单一职责原则采用“职责”或“变化原因”来衡量接口或类设计的是否优良，但“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。
• 对于接口，我们在设计的时候一定要做到单一，但是对于实现类就需要多方面考虑了。
• 生搬硬套单一直接原则会引起类的剧增，给维护带来很多麻烦，而且过分细分类的职责也会人为的增加系统的复杂性。
• 对于单一职责原则，我的建议是接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。

如何找出多重职责的类？

• 在一张纸上写下 ： 该 [类] [类方法] 自己
• 在每一行的第一个空格中写下类名，在第二个空格中写下类中的方法之一
• 思考你的类真的具有该方法所指的职责吗，如果不合理，请移除它。

里氏交换原则 -- LSP(Liskov Substitution Principle)

定义：只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误和异常， 使用者可能根本就不需要知道是父类还是子类。但是有子类出现的地方，父类就未必能适应。

• 里氏替换原则为良好的继承定义了一个规范：
  

  • 子类必须完全实现父类的方法。如果子类不能完整的实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”， 则建议断开父子继承关系，采用其余关系替代。
    
  • 子类可以有自己的方法和属性
    
  • 覆盖或实现父类的方法时输入参数可以被放大。
    
  • 覆写或实现父类方法时输出结果可以被缩小。

  
  在项目中，采用里式交换时，尽量避免子类的个性

• 委托： 将特定工作的责任委派给另一个类或方法。

要先总结一下类图然后再看一下

依赖倒置原则

定义：
- 高层模块不应该依赖低层模块，两者都应该依赖其抽象
- 抽象不应该依赖细节，抽象指的是接口或抽象类，细节指的是实现类。
- 细节应该依赖抽象

依赖倒置原则在Java中的表现是：
- 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象产生的。
- 接口或抽象类不依赖于实现类
- 实现类依赖于接口或抽象类

注意： 在Java中，只要定义变量就必然有类型， 一个变量可以有两种类型：表面类型和实际类型。 表面类型是在定义的时候赋予的类型， 实际类型是对象的类型。

两个类支架有依赖关系，只要制定出两者之间的接口（抽象类） 就可以独立开发了，而且项目之间的单元测试也可以独立的运行。

依赖的三种写法：

依赖是可以多层传递的，但只要做到抽象依赖， 即使是多层的依赖传递也无所畏惧
1. 构造函数传递依赖对象
2. Setter方法春娣依赖对象
3. 接口声明依赖对象

接口隔离原则

定义

接口分为两类：

• 实例接口：在Java中声明一个类，然后用new关键字产生一个实例，它是对一个类型的十五的描述。
• 类接口： java中用interface关键字定义的接口

隔离的意思是： 建立单一接口，不要建立臃肿庞大的接口。接口尽量细化，接口中的方法尽量少。提供给莫格模块的都应该是单一接口

保证接口的纯洁性

接口隔离原则对接口的规范约束有：
1. 接口要尽量小， 但是不能违反单一职责原则。
2. 接口要高内聚。高内聚就是提高接口，类，模块的处理能力，减少对外的交互。具体是要求在接口中尽量少公布public方法，接口是对外的承诺，承诺越少对系统的开发越有利，变更的风险也就越少。
3. 定制服务。要求：只提供访问者需要的方法。
4. 接口设计是有限度的。不要一味追求粒度。

迪米特发法则

定义

一个对象一个对其他对象有最少的了解，即一个类一个对自己需要耦合和调研的类知道的最少，被i耦合和调用的类的内部是如何复杂斗鱼该类没有关系。

要求

迪米特法则针对类的低耦合：

1. 只和朋友交流。朋友类的定义： 出现在成员变量，方法的输入输出参数中的类称为成员朋友类，而出现在方法内部的类不属于朋友类。
2. 朋友间也是有距离的。一个类公开的public属性或方法越多，修改时涉及的面也就越大，变更引起的风险扩散也就越大。因此为了保持朋友类间的距离，在设计时需反复衡量： 是否还可以减少piblic方法和属性，是否可以修改为private, package-private,protected等访问权限，是否可以加上final关键字。
3. 是自己的就是自己的。如果一个方法放在本类中，即不增加类间关系，也对本类不产生负面影响，就放置在本类中。
4. 谨慎使用Serializable

开闭原则

一个软件实体如类，模块和函数都应该对扩展开放，对修改关闭。

什么是开闭原则？

一个软件实体应该通过扩展来实现变化，而不是通过修改已有代码来实现变化。

软件实体包括：

• 项目或软件产品中按照一定的逻辑规划划分的模块
• 抽象和类
• 方法

注意： 开闭原则多扩展开放，对修改关闭，并不意味着不做任何改变，低层模块的变更，必然要有高层模块进行耦合，否则就是一个孤立无意义的代码片段。

变化可以归纳为以下三类：

1. 逻辑变化：只变化一个逻辑，而不涉及其他模块。这时可以通过修改原有类中的方法的方式来完成，前提是所有依赖或关联类都按照相同的逻辑处理。
2. 子模块变化：一个模块变化，会对其他模块产生影响，特别是一个低层次的模块变化必然引起高层模块的变化，因此在通过扩展完成变化时，高层次的模块修改是必然的。
3. 可见视图变化：

为什么要采用开闭原则

1. 开闭原则对测试的影响

2 开闭原则可以提高复用性

3. 开闭原则可以提高可维护性

4. 面向对象开发的要求

参考

《设计模式之禅》
《深入浅出面向对象分析》
《冒号课堂》

设计原则是能被应用到设计或编写程序代码中的工具或技术， 让程序代码更可维护， 更具灵活性或更易扩展。

开闭原则（OCP）

类应该允许为扩展而开放， 禁止为修改而关闭

OCP关系到灵活性，但不只是继承， 继承通常是最容易实现的，但的确不是唯一的选择。

不自我重复原则（DRY）

通过将共同之物抽取出来并置于单一地方来避免重复的程序代码