常用设计模式与六大原则
2016-07-31 本文已影响47人
背影杀手不太冷
标签（空格分隔）： java
六大原则###
参考博客：博客，以下的内容请参考博客里的例子
- 单一职责原则：一个类只负责一项职责。
弊端：
类T只负责一个职责P，这样设计是符合单一职责原则的。后来由于某种原因，也许是需求变更了，也许是程序的设计者境界提高了，需要将职责P细分为粒度更细的职责P1，P2，这时如果要使程序遵循单一职责原则，需要将类T也分解为两个类T1和T2，分别负责P1、P2两个职责。
这样做的风险在于职责扩散的不确定性，因为我们不会想到这个职责P，在未来可能会扩散为P1，P2，P3，P4……Pn。所以记住，在职责扩散到我们无法控制的程度之前，立刻对代码进行重构。）
所以必要时可以适当违反单一职责原则：
情况一：只有逻辑足够简单，才可以在代码级别上违反单一职责原则；
情况二：只有类中方法数量足够少，才可以在方法级别上违反单一职责原则；
情况三：若不满足以上两种情况的话，还是要遵循单一职责原则，一个类负责一个功能职责
需要说明的一点是单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。
- 里氏替换原则：所有引用基类的地方必须能透明地使用其子类的对象。
具体操作：
当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。
继承作为面向对象三大特性之一，在给程序设计带来巨大便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。
- 依赖倒置原则：核心思想是面向接口编程
- 接口隔离原则：
接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
（与单一职责原则还是有区别的）
单一职责原则原注重的是职责；而接口隔离原则注重对接口依赖的隔离。其二，单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节；而接口隔离原则主要约束接口接口，主要针对抽象，针对程序整体框架的构建。
- 迪米特法则：一个对象应该对其他对象保持最少的了解。（低耦合，高内聚）
原因：
类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
迪米特法则还有一个更简单的定义：只与直接的朋友通信。
耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。
- 开闭原则：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭
当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
开闭原则可能是设计模式六项原则中定义最模糊的一个了，它只告诉我们对扩展开放，对修改关闭，可是到底如何才能做到对扩展开放，对修改关闭，并没有明确的告诉我们。我们遵循设计模式前面5大原则，以及使用23种设计模式的目的就是遵循开闭原则
- 总结
单一职责原则告诉我们实现类要职责单一；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合。而开闭原则是总纲，他告诉我们要对扩展开放，对修改关闭。
常用的设计模式###
- 单例模式
参考：博客
未完，待续！
