设计模式介绍和原则

       ☆什么是设计模式

  Christopher Alexander这样解释：每个模式描述了一个在我们周围不断重复发生的问题以及该问题解决方案的核心。

   设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

      ☆ 设计模式的原则

  设计模式现在越来越多，千变万化。要领悟设计模式需先掌握其根本的原则，以不变应万变。

      ☆开发原则

  Closed for Modification; Open for Extension（对变更关闭，对扩展开放）。模块应尽量在不修改原有的代码下进行扩展。在"开-闭"原则中，不允许修改的是抽象的类或者接口，允许扩展的是具体的实现类，抽象类和接口在"开-闭"原则中扮演着极其重要的角色，即要预知可能变化的需求，又预见所有可能已知的扩展，所以在这里"抽象化"是关键！

      ☆里氏代换原则(Liskov Substitution Principle LSP)

    一个软件实体如果使用的是一个基类的话那么一定适用于其子类，而且它察觉不出基类对象和子类对象的区别。也就是说，在软件里面，把基类都替换成它的子类，程序的行为没有变化。

     LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。

    【实例说明：http://www.mangbar.com/document/5d023bd415fb321601160ef2c7916ddd 】

      ☆合成/聚合复用原则(CARP)

  合成/聚合复用原则（Composite/Aggregate Reuse Principle或CARP）经常又叫做合成复用原则（Composite Reuse Principle或CRP），就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新对象通过向这些对象的委派达到复用已有功能的目的。简而言之，尽量使用合成/聚合，不要使用继承。应尽量针对Interface编程，区分Is-A和Has-A。

      ☆依赖倒转原则(Dependence Inversion Principle DIP)

    要针对借口编程，而不针对实现编程。那么当实现变化时，不会影响到其他的地方。 在java中应当使用接口和抽象类来进行变量的类型声明。依照依赖倒转原则，在系统中会出现大量的类，如抽象类和接口，因为它假定所有的具类都是有可能变化的。但实际上这也不总是正确的，有些具体类是非常稳定的，就不需要为他抽象一种新的类型。

      ☆接口隔离原则(Interface Segregation Principle   ISP)

    使用多个专门的接口比使用单一的总接口要好，一个类对另外一个类的依赖性应当是建立在最小的接口上的。一个接口代表一个角色，不应当将不同的角色都交给一个接口。

      ☆迪米特法则(Law Of Demeter LOD)/最少知识原则(Least Knowledge Principle LKP)

  狭义的迪米特法则
  如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

  朋友圈的确定
     1）当前对象本身（this）
     2）以参量形式传入到当前对象方法中的对象
     3）当前对象的实例变量直接引用的对象
     4）当前对象的实例变量如果是一个聚集，那么聚集中的元素也都是朋友
     5）当前对象所创建的对象

  缺点：会在系统里造出大量的小方法，散落在系统的各个角落。这些方法仅仅是传递间接的调用,因此系统与系统中的商业逻辑无关.当设计师试图从一张类图看出总体的构架时,这些小方法会造成迷惑和困扰

  为了克服狭义迪米特法则的缺点，可以使用依赖倒转原则，引入一个抽象的类型引用"抽象陌生人"对象，使"某人"依赖于"抽象陌生人"，换言之，就是将"抽象陌生人"变成朋友。


  广义的迪米特法则
  迪米特法则的主要用意是控制信息的过载。在将迪米特法则运用到系统设计中时，要注意下面的几点：
    1）在类的划分上，应当创建有弱耦合的类。
    2）在类的结构设计上，每一个类都应当尽量降低成员的访问权限。
    3）在类的设计上，只要有可能，一个类应当设计成不变类。
    4）在对其他类的引用上，一个对象对其对象的引用应当降到最低。

  广义迪米特法则在类的设计上的体现
    1）优先考虑将一个类设置成不变类
    2）尽量降低一个类的访问权限
    3）谨慎使用Serializable
    4）尽量降低成员的访问权限
    5）取代C Struct(避免直接访问数据)

【http://www.blogjava.net/qixiangnj/archive/2006/09/28/72683.html 】
【http://www.cnblogs.com/renrenqq/archive/2004/07/13/23701.html 】

      ☆设计模式的四个基本要素


      ☆模式名称（pattern name）

  一个助记名，它用一两个词来描述模式的问题、解决方案和效果。命名一个新的模式增加了我们的设计词汇。设计模式允许我们在较高的抽象层次上进行设计。基于一个模式词汇表，我们自己以及同事之间就可以讨论模式并在编写文档时使用它们。模式名可以帮助我们思考，便于我们与其他人交流设计思想及设计结果。找到恰当的模式名也是我们设计模式编目工作的难点之一。

      ☆问题(problem)

  描述了应该在何时使用模式。它解释了设计问题和问题存在的前因后果，它可能描述了特定的设计问题，如怎样用对象表示算法等。也可能描述了导致不灵活设计的类或对象结构。有时候，问题部分会包括使用模式必须满足的一系列先决条件。

      ☆解决方案(solution)

  描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象组合）来解决这个问题。

      ☆效果(consequences)

   描述了模式应用的效果及使用模式应权衡的问题。尽管我们描述设计决策时，并不总提到模式效果，但它们对于评价设计选择和理解使用模式的代价及好处具有重要意义。软件效果大多关注对时间和空间的衡量，它们也表述了语言和实现问题。因为复用是面向对象设计的要素之一，所以模式效果包括它对系统的灵活性、扩充性或可移植性的影响，显式地列出这些效果对理解和评价这些模式很有帮助。

      【http://www.itisedu.com/phrase/200603061631585.html 】 
      【http://lixianhuei.cnblogs.com/archive/2006/01/12/315849.html 】