首页手记设计模式之禅2之六大原则

设计模式之禅2之六大原则

标签：

Java 设计

------------------读书笔记--------------------------------
面向对象原则
1单一职责原则SRP （single ResponSibility Principle）
1.类的复杂性降低,实现什么职责都有明确的定义
2.可读性提高
3.可维护性提高
4.风险降低
2.里氏替换原则
定义
Liskov Substituition Principle（LSP），里氏代换原则，很严格的原则，规则是“子类必须能够替换基类，否则不应当设计为其子类。”也就是说，子类只能去扩展基类，而不是隐藏或覆盖基类
前置条件：契约设计
就是想你要拿我的东西，得满足我的条件经过我的同意

如果子类不能够完整的实现父类的方法，或者父类的某些方法在子类中已经发生畸变，则建议断开父子继承关系，采用依赖，聚合、组合等关系代替
有子类出现的地方，父类未必可以出现（）
子类继承父类，是可以与父类的方法重载的，但是参数值一定要比原来的参数范围大，但是仍然也是调用父类的方法（如果小的话，就会引起混乱）
重写或者显示父类的方法时输出结果可以被缩小
好处:
1.代码共享，减少创建类的工作，每个子类都有父类的方法和属性
2.提高代码的重用性
3.代码的可扩展性
4.提高产品或者项目的开放性
坏处:
1继承是入侵的，只要是继承，就必须有父类的方法和属性
2.降低代码的灵活性
3.增强了耦合性
3.依赖倒置原则
定义
Dependence Inversion Principle（DIP），依赖倒换原则，“设计要依赖于抽象而不是具体化”。换句话说就是设计的时候我们要用抽象来思考，而不是一上来就开始划分我需要哪些哪些类，因为这些是具体。这样做有什么好处呢？人的思维本身实际上就是很抽象的，我们分析问题的时候不是一下子就考虑到细节，而是很抽象的将整个问题都构思出来，所以面向抽象设计是符合人的思维的。另外这个原则会很好的支持OCP，面向抽象的设计使我们能够不必太多依赖于实现，这样扩展就成为了可能.
1高层模块不应该依赖低层模块
抽象不应该依赖细节
3.细节应该依赖抽象
在java语言中的表现
模块之间的依赖通过抽象发生，实现类之间不发生直接依赖关系，其依懒关系是通过接口或抽象类产生的
接口或抽象类不依赖实现类
面向接口编程
好处:
减少类的耦合性
提供系统的稳定性
降低并行开发带来的风险
提高代码的可读性和可维护性
4.接口隔离原则
定义
Interface Segregation Principle（ISP），接口隔离原则，“将大的接口打散成多个小接口”，这样做的好处很明显。
两种接口：
1.实例接口（类）
2.类接口（用interface）
1.客户端不应该依赖他不需要的接口
2.类之间的依赖关系应该建立在最小接口上(接口要纯洁)
3.接口要高内聚(高内聚就是提高接口，类，模块的处理能力，减少对外的交互)
(不讲条件，立刻完成任务)
最佳实践
一个接口只服务于一个子模块或者业务逻辑
通过业务逻辑去压缩接口中的public方法，经常回顾接口，瘦接口
已经被污染的接口尽量去修改，若修改风险大，则采用适配器模式进行转化处理
了解环境，拒绝盲从（根据需求去设计）
5.迪米特法则(最少知识原则)
Law of Demeter or Least Knowlegde Principle（LoD or LKP），迪米特法则或最少知识原则，这个原则首次在Demeter系统中得到正式运用，所以定义为迪米特法则。它讲的是“一个对象应当尽可能少的去了解其他对象”。也就是又一个关于如何松耦合（Loosely-Coupled）的法则
1. 只和朋友交流(朋友:对象和对象之间有耦合关系就叫做朋友关系)
2. 和最近的朋友交流(要保持距离，朋友妻不可欺)
3. 自己的就是自己的(如果一个方法放在本类中，既不产生类间关系，也对本类不产生负面影响，那么就放置在本类中)
4. 谨慎使用Serrializable
  6开闭原则
  Open-Close Principle（OCP），开-闭原则，讲的是设计要对扩展有好的支持，而对修改要严格限制。这是最重要也是最为抽象的原则，基本上我们所说的Reusable Software既是基于此原则而开发的。其他的原则也是对它的实现提供了路径。
  什么是软件实体：
5. 项目或者软件产品按照一定的逻辑划分的模块
6. 抽象和类
7. 方法
  面向对象原则
  1单一职责原则SRP （single ResponSibility Principle）
  1.类的复杂性降低,实现什么职责都有明确的定义
  2.可读性提高
  3.可维护性提高
  4.风险降低
  2.里氏替换原则
  定义
  Liskov Substituition Principle（LSP），里氏代换原则，很严格的原则，规则是“子类必须能够替换基类，否则不应当设计为其子类。”也就是说，子类只能去扩展基类，而不是隐藏或覆盖基类
  前置条件：契约设计
  就是想你要拿我的东西，得满足我的条件经过我的同意
如果子类不能够完整的实现父类的方法，或者父类的某些方法在子类中已经发生畸变，则建议断开父子继承关系，采用依赖，聚合、组合等关系代替
有子类出现的地方，父类未必可以出现（）
子类继承父类，是可以与父类的方法重载的，但是参数值一定要比原来的参数范围大，但是仍然也是调用父类的方法（如果小的话，就会引起混乱）
重写或者显示父类的方法时输出结果可以被缩小
好处:
1.代码共享，减少创建类的工作，每个子类都有父类的方法和属性
2.提高代码的重用性
3.代码的可扩展性
4.提高产品或者项目的开放性
坏处:
1继承是入侵的，只要是继承，就必须有父类的方法和属性
2.降低代码的灵活性
3.增强了耦合性
3.依赖倒置原则
定义
Dependence Inversion Principle（DIP），依赖倒换原则，“设计要依赖于抽象而不是具体化”。换句话说就是设计的时候我们要用抽象来思考，而不是一上来就开始划分我需要哪些哪些类，因为这些是具体。这样做有什么好处呢？人的思维本身实际上就是很抽象的，我们分析问题的时候不是一下子就考虑到细节，而是很抽象的将整个问题都构思出来，所以面向抽象设计是符合人的思维的。另外这个原则会很好的支持OCP，面向抽象的设计使我们能够不必太多依赖于实现，这样扩展就成为了可能.
1高层模块不应该依赖低层模块
抽象不应该依赖细节
3.细节应该依赖抽象
在java语言中的表现
模块之间的依赖通过抽象发生，实现类之间不发生直接依赖关系，其依懒关系是通过接口或抽象类产生的
接口或抽象类不依赖实现类
面向接口编程
好处:
减少类的耦合性
提供系统的稳定性
降低并行开发带来的风险
提高代码的可读性和可维护性
4.接口隔离原则
定义
Interface Segregation Principle（ISP），接口隔离原则，“将大的接口打散成多个小接口”，这样做的好处很明显。
两种接口：
1.实例接口（类）
2.类接口（用interface）
1.客户端不应该依赖他不需要的接口
2.类之间的依赖关系应该建立在最小接口上(接口要纯洁)
3.接口要高内聚(高内聚就是提高接口，类，模块的处理能力，减少对外的交互)
(不讲条件，立刻完成任务)
最佳实践
一个接口只服务于一个子模块或者业务逻辑
通过业务逻辑去压缩接口中的public方法，经常回顾接口，瘦接口
已经被污染的接口尽量去修改，若修改风险大，则采用适配器模式进行转化处理
了解环境，拒绝盲从（根据需求去设计）
5.迪米特法则(最少知识原则)
Law of Demeter or Least Knowlegde Principle（LoD or LKP），迪米特法则或最少知识原则，这个原则首次在Demeter系统中得到正式运用，所以定义为迪米特法则。它讲的是“一个对象应当尽可能少的去了解其他对象”。也就是又一个关于如何松耦合（Loosely-Coupled）的法则
1. 只和朋友交流(朋友:对象和对象之间有耦合关系就叫做朋友关系)
2. 和最近的朋友交流(要保持距离，朋友妻不可欺)
3. 自己的就是自己的(如果一个方法放在本类中，既不产生类间关系，也对本类不产生负面影响，那么就放置在本类中)
4. 谨慎使用Serrializable
  6开闭原则
  Open-Close Principle（OCP），开-闭原则，讲的是设计要对扩展有好的支持，而对修改要严格限制。这是最重要也是最为抽象的原则，基本上我们所说的Reusable Software既是基于此原则而开发的。其他的原则也是对它的实现提供了路径。
  什么是软件实体：
5. 项目或者软件产品按照一定的逻辑划分的模块
6. 抽象和类
7. 方法