设计模式(0): 简介及SOLID原则

　　在软件工程中，设计模式（design pattern）是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案。
　　设计模式并不直接用来完成代码的编写，而是描述在各种不同情况下，要怎么解决问题的一种方案。面向对象设计模式通常以类或对象来描述其中的关系和相互作用，但不涉及用来完成应用程序的特定类或对象。设计模式能使不稳定依赖于相对稳定、具体依赖于相对抽象，避免会引起麻烦的紧耦合，以增强软件设计面对并适应变化的能力。
　　并非所有的软件模式都是设计模式，设计模式特指软件“设计”层次上的问题。还有其它非设计模式的模式，如架构模式。同时，算法不能算是一种设计模式，因为算法主要是用来解决计算上的问题，而非设计上的问题。
　　GOF《设计模式》一书涉及到23个模式，把设计模式分为创建型模式、结构型模式、行为型模式，分别从对象的创建，对象和对象间的结构组合以及对象交互这三个方面为面向对象系统建模方法给予了解析和指导。
　　　　

　　创建型设计模式(Creational Patterns)描述怎样创建一个对象。它隐藏对象创建的细节，使程序代码不依赖具体的对象，这样当我们增加一个新的对象时几乎不需要修改代码。
　　结构型设计模式(Structural Patterns)描述类和对象之间怎么组织起来形成大的结构，主要使用继承来组织接口或实现。
　　行为型设计模式(Behavioral Patterns)描述算法以及对象之间的任务分配，它所描述的不仅仅是对象或类的设计模式，还有它们之间的通讯模式。

SOLID原则：
　　SOLID（单一功能、开闭原则、里氏替换、接口隔离以及依赖反转）是由罗伯特?C?马丁在21世纪早期[1] 引入的记忆术首字母缩略字，指代了面向对象编程和面向对象设计的五个基本原则。当这些原则被一起应用时，它们使得一个程序员开发一个容易进行软件维护和扩展的系统变得更加可能。
　　单一功能原则（Single responsibility principle）规定每个类都应该有一个单一的功能，并且该功能应该由这个类完全封装起来。简单地说，就是保持单纯，别想那么多，做好一件事就好了。反过来，如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力，当变化发生时，设计会遭受到意想不到的破坏。
　　开闭原则规定“软件中的对象（类，模块，函数等等）应该对于扩展是开放的，但是对于修改是封闭的”。面对需求变化，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。但在最初编写代码时，难以预测到变化的产生，这就要求变化发生时，就创建抽象来隔离以后发生的同类变化。开发人员应该仅对程序中呈现出频繁变化的那些部分作出抽象，拒绝不成熟的抽象和抽象本身一样重要。
　　里氏替换原则（Liskov Substitution principle）是对子类型的特别定义。派生类（子类）对象能够替换其基类（超类）对象被使用。比如鸵鸟就不能从一个具有会飞特性的鸟类继承。
　　接口隔离原则（英语：interface-segregation principles， 缩写：ISP）指明没有客户(client)应该被迫依赖于它不使用方法。接口隔离原则(ISP)拆分非常庞大臃肿的接口成为更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。这种缩小的接口也被称为角色接口（role interfaces）。接口隔离原则(ISP)的目的是系统解开耦合，从而容易重构，更改和重新部署。还是以上面的鸵鸟为例，我们应该把鸟类接口拆分成会飞的鸟类接口和不会飞的鸟类接口，然后鸵鸟继承于不会飞的鸟类接口，如果鸵鸟直接继承于鸟类接口，那么它必须实现fly()操作，这就违背了接口隔离原则，因为它依赖了它不适用的方法。
　　依赖反转原则（Dependency inversion principle）指代了一种特定的解耦（传统的依赖关系建立在高层次上，而具体的策略设置则应用在低层次的模块上）形式。在这种形势下，为了使得高层次的模块不依赖于低层次的模块的实现细节的目的，依赖模块被颠倒了（例如：反转）。该原则规定：
　　高层次的模块不应该依赖于低层次的模块，两者都应该依赖于抽象接口。
　　抽象接口不应该依赖于具体实现。而具体实现则应该依赖于抽象接口。
　　比如有各种厂家制造的电脑，但为了使用和维修的方便，他们应该使用统一的鼠标接口、统一的键盘接口。说白了，就是每个厂家要依赖于统一的标准接口来生产他们的产品，消费者也只通过统一的接口来使用。

　　可复用面向对象软件的基础 – 设计模式，以其可复用的设计初衷、精巧的逻辑思维被广大面向对象程序设计所追捧。但不少程序设计者却经常将思考的问题转换为遇到了什么场景就要用什么模式。这种八股文式的思维在某种程度上严重影响了程序设计的艺术性，并固化了程序设计者的思想，违背了设计模式的初衷。其实也不必死记这几个原则的名字，程序写多了，你肯定会注意到这些东西，掌握实质才是最重要的。

参考：
https://zh.wikipedia.org/wiki/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F_(%E8%AE%A1%E7%AE%97%E6%9C%BA)
https://zh.wikipedia.org/wiki/SOLID_(%E9%9D%A2%E5%90%91%E5%AF%B9%E8%B1%A1%E8%AE%BE%E8%AE%A1)
http://www.cnblogs.com/aehyok/archive/2013/05/21/3091917.html