大话设计模式

一、设计模式

• 创建型模式（共5种）：工厂方法模式，抽象工厂模式，单例工厂模式，建造者模式，原型模式
• 结构型模式（共7种）：适配器模式，装饰器 模式，代理模式，外观模式，桥接模式，组合模式，享元模式
• 行为型模式（共11种）：策略模式，模板方法模式，观察者模式，迭代器模式，责任链模式，命令模式，备忘录模式，状态模式，访问者模式，中介者模式，解释器模式
• 其他还有两类：并发型模式和线程池模式

二、设计模式的原则

1. 单一职责原则：不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，否则就应该把类拆分
2. 里氏替换原则（Liskov Substitution Principle）：任何基类可以出现的地方，子类一定可以出现。里氏替换原则是继承复用的基石，只有当衍生类可以替换基类，团建单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏替换原则是对“开-闭“原则的补充。实现”开-闭“原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏替换原则是对实现抽象化的具体步骤规范。里氏替换原则中，子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构，通过这个规范得接口与外界交互，子类不应该随便破坏它。
3. 依赖倒转原则（Dependence Inversion Principle）：面向接口编程，依赖于抽象而不依赖于具体。写代码时用到具体类时，不育具体类交互，而与具体类的上层接口交互
4. 接口隔离原则（Interface Segregation Principle）：每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个隔离接口，比使用单个接口（多个接口方法结合到一个的接口）要好。
5. 迪米特法则（最少知道原则）Demeter Principle）：一个类对自己依赖的类知道的越少越好。无论被依赖的类多么复杂，都应该将逻辑封装在方法的内部，通过public方法提供给外部。这样当被依赖的类变化时，才能最小的影响该类。最少知道原则的另一个表达方式是：只与直接的朋友通信。类之间只要有耦合关系，就叫朋友关系。耦合分为依赖、关联、聚合、组合等。我们称出现为成员变量、方法参数、方法返回值中的类为直接朋友。局部变量、临时变量则不是直接的朋友。我们要求陌生的类不要作为局部变量出现在类中。
6. 合成服用原则（Composite Reuse Principle）：尽量首先使用合成/聚合的方式，而不是使用继承。

三、UML

常见几种关系：泛化/继承（Generalization）、实现（Realization）、依赖（Dependency）、关联（Association）、聚合（Aggregation）、组合（Composition）

• 泛化/继承（继承父类）：带空心三角形的直线表示
• 实现（实现接口）：带空心三角形的虚线表示
• 依赖：类与类之间最弱的关系，依赖可以简单的理解一个类使用了另外一个类：带箭头的虚线表示依赖。例如：Person类使用car类里面的speed属性（一般在方法参数）
• 关联：一个类和另一类有联系：带箭头的实线表示关联

          例如：Person类里面有Address类属性（一般在成员变量）
        1.1：表示另一个类的一个对象只与该类的一个对象有关系
        1.2：表示另一个类的一个对象与该类的零个或多个对象有关系
        1.3：表示另一个类的一个对象与该类的一个或多个对象有关系
        1.4：表示另一个类的一个对象没有或只与该类的一个对象有关系
        1.5 ：任意多个对象关联

• 聚合：表示整体与部分的关系，但是部分可以脱离整体而存在:带空心菱形的直线加箭头表示，has-a关系，例如：Person类里面有car类属性，人拥有车，车可以脱离人存在。
• 组合：部分和整体的关系，但是部分存货周期收到整体的影响，若整体不存在则部分也将不存在。此时部分需在整体的构造方法中创建：带实心菱形的直线加箭头表示。Contains-a关系。例如：Person类里面有finger类属性，人拥有手指，手指不脱离人存在。

关系所表现的强弱程序依次为：组合>聚合>关联>依赖；聚合跟组合其实都属于关联，只不过它们是两种特殊的关联。