第三，四，五，十一章 设计模式和面向对象的各种规则(读书笔记)

 第三章 拍摄UFO-单一职责原则

1.单一职责原则（SRP），就一个类而言，应该仅有一个引起它变化的原因。
2.如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会消弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。
3.所谓俄罗斯方块游戏的逻辑，不过就是数组的每一项值变化的问题，下落，旋转，碰撞判断，移动，堆积这些都是在做数组具体项的值的变化。而界面表示逻辑。不过是根据数组的数据进行绘出和察除，或者根据键盘命令调用数组的相应方法进行改变。
4.在编程时，我们要在类的职责分离上多思考，做到单一职责，这样你的代码才是真正的易维护，易扩展，易复用，灵活多样。
5.用多功能手机拍摄UFO，就不是单一职责原则。

-------------------------------------------------------
第四章 考研求职两不误-开放封闭原则

1.开放封闭原则（The Open-Closeed PrinciPle 简称OCP）：是说软件实体（类，模块，函数等等）应该可以扩展，但是不能修改。
2.无论模块是多么的封闭，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对他设计的模块应该对哪种变化封闭做出选择，它必须先猜测最有可能发生变化的种类，然后构造抽象来隔离那些变化。
3.在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化。
4.面对需求，对程序的改动是通过增加代码来进行的，而不是更改现有的代码。
5.开放封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护，可扩展，可复用，灵活性好。开发人员印尼改仅对程序中呈现出的频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。

-------------------------------------------------------
第五章 会修电脑不会修收音机？依赖倒转原则

1.依赖倒转原则：抽象不应该依赖细节，细节应该依赖于抽象。就是要针对接口来编程，不要对实现编程。组装机过程中，CPU，内存，硬盘都是在针对接口设计的，如果针对实现来设计，那就会出现换内存需要把主板也换了的尴尬。
2.高层模块不应该依赖底层模块。两个都应该依赖抽象。
3.里氏代换原则：子类型必须能够替换掉他们的父类型。子类继承了父类，那么子类可以以父类的形式出现。
4.在编程世界里，企鹅不能以父类--鸟的身份出现，因为前提说所有鸟都能飞，而企鹅飞不了，所以企鹅不能继承鸟类。如果企鹅继承了鸟，那么企鹅就会飞。
5.只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。
6.高层模块不应该依赖于底层模块，两个都应该依赖抽象。
7.依赖倒转其实就是谁也不要依靠谁，除了约定的接口，大家都可以灵活自如。
8.收音机跟电脑相比就是耦合过度，只要收音机出故障，不管是没有声音，不能调频，还是有杂音，反正都很难修理，不懂得人根本修不来。
9.依赖倒转其实可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者借口，那就是面向对象的设计，反之就是过程化的设计了。

-------------------------------------------------------
第11章 无熟人难办事 --迪米特法则

1.如果公司IT部就一个小张，那什么问题也没有，就是效率低点。如果有几个人的话，他们都是找到谁，就请谁去工作，如果都熟悉，有事可以协调着办，如果不熟悉，那么就会出现等待的情况了，有人忙死有人累死。
2.如果公司IT部有一个主管，哪怕主管正好不在外出了，小张小李谁有空谁先去处理，然后汇报给主管，再来进行工作的协调，这样才是最好的。在这里，小张小李就是代表具体类，IT部代表的是抽象类或接口。
3.迪米特法则（LoD）：如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
4.迪米特法则首先强调的是在类的结构设计上，每一个类都应当尽量降低成员的访问权限，不需要让别的类知道的字段或行为就不要公开。也就是强调了类之间的松耦合。
5.类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。