【面向对象】——六原则
《大话设计模式》通看一遍了，虽然只是泛读，但其实还是有很多收获的，至少知道了设计模式有23个，原则有6个......呵呵
当然继而通过和小伙伴交流和看大家的博客，对他们又有了进一步的了解。
关于《大话设计模式》，我认为可以分成两部分学习——<原则>与<模式>
首先先把六大原则理解透彻，然后看模式的时候就可以以辩证的眼光去学习，用六大原则帮我们理清各模式的区别，差异。并且，这样还能让我们看书变得更主动，不是让书牵着我们走，而是我们从中挑选我们想要的：看书过程中，用六大原则去验证每个模式，看哪些适用，哪些不适用，从而发现他们的不同......（听一些人说过，“怎么感觉每个模式都一样啊”......那不妨这样试试）
好了，这篇我是打算先整理一下六原则的......
单一职责原则：
定义：就一个类而言，应该仅有一个引起它变化的原因。
手机类中，有打电话、发短信、照相三个动机可以改变它。而照相机类只有一个动机可以改变它，照相机集所有功力于照相功能，不用多想它必将战胜手机的非单纯照相功能......
所以，一个类，不是功能越多越好，越多，耦合性就越强，互相之间约束就会越多。
在软件设计中，如果你能够想到多余一个的动机去改变一个类，那么这个类就是具有多余一个的职责，就应该考虑类的职责分离.....即做到单一职责。
开放-封闭原则：
定义：是说软件实体（类、模块、函数等等）应该可以扩展，但是不可修改。
即：开放扩展，封闭修改......
当需要增加乘法方法时，左边就需修改运算法，将乘法加入，右边则只用扩展运算类即可，这样会减少很多出错的可能~
开放-封闭原则是面向对象设计的核心所在，遵循这个原则可使软件可维护、可扩展、可复用、灵活性好（即完美表现面向对象的好处）。
开发人员应该仅对程序中呈现出频繁变化的那些部分作出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意，拒绝不成熟的抽象和抽象本身一样重要。
依赖倒转原则：
定义：高层模块不应该依赖低层模块.两个都应该依赖抽象。抽象不应该依赖细节，细节应该依赖抽象。
左边当内存损坏，CPU，主板都需更换，因为他们相当于绑在一起的。而右边，主板依赖的是CPU、内存的接口，当内存坏时，只需接口完好，就不需更换主板和CPU......
也就是说，不管高层模块还是低层模块，他们都应依赖于抽象，即接口或抽象类，这样，只要接口稳定，其它任何一个的更改都不用担心影响到其它~这也就使得无论高层模块还是低层模块都可以很容易的被复用......
其实依赖倒转原则就是我们一直说的做到：高内聚，低耦合吧~
依赖倒转其实可以说是面向对象的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，及程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之都是过程化的设计了。
里氏代换原则：
定义：子类型必须能够替换掉他们的父类型。
因为有了这个原则，才使得继承复用成为可能。只有子类可以替换掉父类，软件单位的功能不受影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。
其实有了里氏代换原则，才使得扩展成为可能，也就使得开放-封闭成为了可能。
合成/聚合复用原则：
定义：尽量使用合成/聚合，尽量不要使用类继承。
合成也就是UML中的组合：整体和部分拥有相同的生命周期。
这是不满足合成/复用原则的例子：
这样，当需要增加手机品牌或软件时，都需要进行很大的改动......
这是满足的例子：
经过这样的调整，使得结构更简单化。也符合了开放-封闭原则。
合成/聚合复用的好处是：优先使用对象的合成/聚合将有助于你保持每个类被封装，并被集中在单个任务上。这样类和类继承层次会保持较小规模，而且不太可能增长为不可控制的庞然大物。
迪米特法则：
定义：迪米特法则也叫最少知识原则：如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个的类的某一个方法的话，可以通过第三者转发这个调用。
这种方法，就导致耦合很强，当需要更换IT部成员时，维修者类也会受影响。
当遵循迪米特法则时，就不会有上述问题，因为需维修者关联的是一个接口，或者说是IT部负责人。这样，当IT部有变动时，需维修者类改动的几率就会变小......
该原则强调的是：在类的结构设计上，每一个类都应当尽量降低成员的访问权限。其根本思想是强调了类之间的松耦合......
其实每个原则，都很贴近生活哈~~生活知识化，知识生活化。
把六个原则理顺一遍，再有针对性的去看各个模式，应该就更有侧重点了吧......