很多程序员用面向对象语言写了多年的代码， 仍然不知道设计模式为何物， 这不奇怪， 设计模式并不是非有不可，可是它能让代码变的更美好。
程序员大可闷头堆代码， 复制粘贴， 然后不断的感慨代码难以维护， 难以复用， 难以扩展， 而继续不思进取。
当然也可以选折不断去追求更美好， 更合理的代码， 把自己从bug调试， 需求变动等噩梦中拯救出来， 进而真正体会到编码的乐趣。
你如果选折后者那么设计模式对于你而言， 是真正必不可少的， 只有当你真正认真考虑过代码的复用性，扩展性，和合理性时， 你才能真正体会到设计模式的好处。
想知道一样东西的价值, 最好的方法就是想想, 如果没有它, 你会怎么样.
对于学习模式, 也是一样, 不要拘泥于其中, 要多想想为什么需要它. 如果没有这种模式, 一样是很好的code, 那就说明这个模式在这种情况下没有价值, 那就不要去用他.
如果使用了一种模式, 能使你的code从可扩展性, 可维护性和可复用性上有些提高, 那么这个就是他的价值所在.
下面是面向对象设计的7大原则，是学习编程和模式的基础
单一职责原则 (SRP)
一个类，只有一个引起它变化的原因。应该只有一个职责。如果一个类有一个以上的职责，这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责. 这严重影响了代码的可维护性, 可复用性.
开闭原则（OCP）
开闭原则是面向对象设计中“可复用设计”的基石，是面向对象设计中最重要的原则之一，其它很多的设计原则都是实现开闭原则的一种手段。1988 年，Bertrand Meyer在他的著作《Object Oriented Software Construction》中提出了开闭原则，它的原文是这样：“Software entities should be open for extension,but closed for modification”。翻译过来就是：“软件实体应当对扩展开放，对修改关闭”。一句好说不好做的话......
依赖倒置原则（DIP）
依赖倒置原则（Dependence Inversion Principle）就是要依赖于抽象，不要依赖于具体。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。
A.高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。
B.抽象不应该依赖于具体，具体应该依赖于抽象。
依赖倒置原则的本质就是通过抽象（接口或者抽象类）使各个类或模型的实现彼此独立，不互相影响，实现模块间的松耦合。
接口隔离原则(ISP)
接口是我们设计时对外提供的契约，通过分散定义多个接口，可以预防未来变更的扩散，提高系统的灵活性和可维护性。
要求在接口中尽量少公布public方法，而不是建立一个庞大的臃肿的接口，容纳所有的客户端访问。
接口是对外的承诺，承诺地越少对系统开发越有利，变更的风险也就越少，同时也有利于降低成本。
迪米特法则（LoD，LKP）
迪米特法则（Law of Demeter，LoD）也称为最少知识原则（Least Knowledge Principle，LKP）, 迪米特法则的核心观念就是类间解耦，弱耦合. 一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的public方 法，我就调用这么多，其他的一概不关心。
设计模式的门面模式（Facade）和中介模式（Mediator），都是迪米特法则应用的例子。
里氏替换原则 (LSP)
Liskov 于1987年提出了一个关于继承的原则“Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.”——“继承必须确保超类所拥有的性质在子类中仍然成立。”也就是说，当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有 is-A关系。 该原则称为Liskov Substitution Principle——里氏替换原则。
继承是个耦合性很强的关系, 所以不能随便轻率的使用继承关系, 如果子类并不能完全替换父类的话, 应该使用聚集, 组合来代替继承.
举个例子, 鸟-->企鹅, 可是企鹅不会飞, 无法实现fly函数, 这样的继承关系就违反了里氏替换原则.
合成/聚合复用原则(CARP)
合成/聚合复用原则(Composite/Aggregate Reuse Principle)的核心思想就是：要尽量使用合成/聚合，不要滥用继承.
说到这, 先来谈谈Aggregation(聚合关系)和Composition(组合关系)
Aggregation(聚合关系), 一种弱的'拥有'关系, 比如人群和人, 就是一般的list和list item, 即表示集合和个体的关系, 用空心的菱形表示
Composition(组合关系), 一种强的'拥有'关系, 比如人和腿, 它们具有相同的生命周期, 即表示整体和部分的关系, 用实心的菱形表示
一般遇到的都是聚合关系, 组合关系只是聚合关系的一个特例. 组合模式(Composite)也是基于聚合关系来讨论的(虽然叫Composite模式).
继承作为面向对象的基础, 非常强大和重要, 但是滥用继承也会带来很多问题, 所以我们要明确区分"Is-A"和"Has-A"关系.
"Is-A"是严格的分类学意义上定义，意思是一个类是另一个类的"一种"。而"Has-A"则不同，它表示某一个角色具有某一项责任。导致错误的使用继承而不是合成/聚合的一个常见的原因是错误的把"Has-A"当作"Is-A"。所以只有真正存在"Is-A"关系时, 我们才考虑使用继承, 否则尽量使用合成/聚合.
滥用继承会有如下问题,
1. 对象的继承关系时编译时就定义死的,无法运行时改变从父类继承的实现, 缺乏灵活性
2. 子类和父类是紧耦合的,存在紧密的依赖关系, 父类的任何变化必然会导致子类的变化.
3. 子类复用的问题, 当继承下来的实现不适合新的问题时, 必须要修改父类.
4. 当然滥用继承, 会导致继承层次迅速膨胀, 成为不可控制的庞然大物.