Design-Pattern设计模式

图说设计模式

图说设计模式 在线书籍

  软件模式是将模式的一般概念应用于软件开发领域，即软件开发的 总体指导思路或参照样板。
  软件模式并非仅限于设计模式，还包括 架构模式、分析模式和过程模式等，
  实际上，在软件生存期的每一个阶段都存在着一些被认同的模式。

1.UML类图和时序图

  1.车的类图结构为<<abstract>>，表示车是一个抽象类；
  2.它有两个继承类：小汽车和自行车；它们之间的关系为实现关系，使用带空心箭头的虚线表示；
  3.小汽车为与SUV之间也是继承关系，它们之间的关系为泛化关系，使用带空心箭头的实线表示；
  4.小汽车与发动机之间是组合关系，使用带实心箭头的实线表示；
  5.学生与班级之间是聚合关系，使用带空心箭头的实线表示；
  6.学生与身份证之间为关联关系，使用一根实线表示；
  7.学生上学需要用到自行车，与自行车是一种依赖关系，使用带箭头的虚线表示；

泛化关系(generalization)

  继承关系为 is-a的关系；两个对象之间如果可以用 is-a 来表示，就是继承关系：（..是..)
  eg：自行车是车、猫是动物
  汽车与SUV之间为泛化关系；
  泛化关系表现为继承非抽象类；

实现关系(realize)

  eg：”车”为一个抽象概念，在现实中并无法直接用来定义对象；
  只有指明具体的子类(汽车还是自行车)，才 可以用来定义对象
  （”车”这个类在C++中用抽象类表示，在JAVA中有接口这个概念，更容易理解）

聚合关系(aggregation）

  聚合关系用一条带空心菱形箭头的直线表示，如下图表示A聚合到B上，或者说B由A组成。
  聚合关系用于表示实体对象之间的关系，表示整体由部分构成的语义；例如一个部门由多个员工组成；
  与组合关系不同的是，整体和部分不是强依赖的，即使整体不存在了，部分仍然存在；
  例如， 部门撤销了，人员不会消失，他们依然存在；

组合关系(composition)

  组合关系用一条带实心菱形箭头直线表示，如下图表示A组成B，或者B由A组成；   
  与聚合关系一样，组合关系同样表示整体由部分构成的语义；比如公司由多个部门组成；
  但组合关系是一种强依赖的特殊聚合关系，如果整体不存在了，则部分也不存在了；
  例如， 公司不存在了，部门也将不存在了；

关联关系(association)

  关联关系是用一条直线表示的；它描述不同类的对象之间的结构关系；
  它是一种静态关系， 通常与运行状态无关，一般由常识等因素决定的；
  它一般用来定义对象之间静态的、天然的结构； 所以，关联关系是一种“强关联”的关系；
  比如，乘车人和车票之间就是一种关联关系；学生和学校就是一种关联关系；
  关联关系默认不强调方向，表示对象间相互知道；
  如果特别强调方向，如下图，表示A知道B，但 B不知道A；

依赖关系(dependency)

  依赖关系是用一套带箭头的虚线表示的；如下图表示A依赖于B；
  他描述一个对象在运行期间会用到另一个对象的关系；
  
  与关联关系不同的是，它是一种临时性的关系，通常在运行期间产生，并且随着运行时的变化； 
  依赖关系也可能发生变化；
  显然，依赖也有方向，双向依赖是一种非常糟糕的结构，我们总是应该保持单向依赖，杜绝双向依赖的产生；
  注：在最终代码中，依赖关系体现为类构造方法及类方法的传入参数，箭头的指向为调用关系；
  依赖关系除了临时知道对方外，还是“使用”对方的方法和属性；

创建型模式

  创建型模式(Creational Pattern)对类的实例化过程进行了抽象，
  能够将软件模块中对象的创建和对象的使用分离。
  为了使软件的结构更加清晰，外界对于这些对象只需要知道它们共同的接口，
  而不清楚其具体的实现细节，使整个系统的设计更加符合单一职责原则。
  
  创建型模式在创建什么(What)，由谁创建(Who)，
  何时创建(When)等方面都为软件设计者提供了尽可能大的灵活性。
  创建型模式隐藏了类的实例的创建细节，
  通过隐藏对象如何被创建和组合在一起达到使整个系统独立的目的。

包含模式

  1.简单工厂模式（Simple Factory），重要程度：4 （5为满分）
  2.工厂方法模式（Factory Method），重要程度：5
  3.抽象工厂模式（Abstract Factory），重要程度：5
  4.建造者模式（Builder），重要程度：2
  5.原型模式（Prototype），重要程度：3
  6.单例模式（Singleton），重要程度：4

1. 简单工厂模式( Simple Factory Pattern )

  又称为静态工厂方法(Static Factory Method)模式
  模式动机
    考虑一个简单的软件应用场景，一个软件系统可以提供
    多个外观不同的按钮（如圆形按钮、矩形按钮、菱形按钮等）， 
    这些按钮都源自同一个基类，不过在继承基类后不同的子类修改了
    部分属性从而使得它们可以呈现不同的外观，如果我们希望在使用这些按钮时，
    不需要知道这些具体按钮类的名字，只需要知道表示该按钮类的一个参数，
    并提供一个调用方便的方法，把该参数传入方法即可返回一个相应的按钮对象，
    此时，就可以使用简单工厂模式。

模式结构
简单工厂模式包含如下角色：

  Factory：工厂角色 
       工厂角色负责实现创建所有实例的内部逻辑
  Product：抽象产品角色
       抽象产品角色是所创建的所有对象的父类，负责描述所有实例所共有的公共接口
  ConcreteProduct：具体产品角色
       具体产品角色是创建目标，所有创建的对象都充当这个角色的某个具体类的实例。

2. 工厂方法模式(Factory Method Pattern)

  模式动机
    现在对该系统进行修改，不再设计一个按钮工厂类来统一负责所有产品的创建，
    而是将具体按钮的创建过程交给专门的工厂子类去完成，我们先定义一个抽象的按钮工厂类，
    再定义具体的工厂类来生成圆形按钮、矩形按钮、菱形按钮等，它们实现在抽象按钮工厂类中定义的方法。
    这种抽象化的结果使这种结构可以在不修改具体工厂类的情况下引进新的产品，
    如果出现新的按钮类型，只需要为这种新类型的按钮创建一个具体的工厂类就可以获得该新按钮的实例，
    这一特点无疑使得工厂方法模式具有超越简单工厂模式的优越性，更加符合“开闭原则”。

模式结构

工厂方法模式包含如下角色：

  Product：抽象产品
  ConcreteProduct：具体产品
  Factory：抽象工厂
  ConcreteFactory：具体工厂