设计模式 从入门到住院 new

每一个模式都有自己的名字，通常用一两个词来描述，可以根据模式的问题、特点、解决方案、功能和效果来命名。模式名称（PatternName）有助于我们理解和记忆该模式，也方便我们来讨论自己的设计。

问题（Problem）描述了该模式的应用环境，即何时使用该模式。它解释了设计问题和问题存在的前因后果，以及必须满足的一系列先决条件。

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

描述了模式的应用效果以及使用该模式应该权衡的问题，即模式的优缺点。主要是对时间和空间的衡量，以及该模式对系统的灵活性、扩充性、可移植性的影响，也考虑其实现问题。显式地列出这些效果（Consequence）对理解和评价这些模式有很大的帮助。

偶然内聚性（Coincidental cohesion，最低）

逻辑内聚性（Logical cohesion）

时间内聚性（Temporal cohesion）

程序内聚性（Procedural cohesion）

联系内聚性/信息内聚/通信内聚（Communicational cohesion）

依序内聚性/顺序内聚（Sequential cohesion）

功能内聚性（Functional cohesion，最高）

软件实体 应该 对扩展开放，对修改封闭

软件实体包含部分

对软件测试的影响

可以提高代码的可复用性

可以提高软件的可维护性

通过“抽象约束、封装变化”来实现开闭原则。

前瞻性和预见性

软件需求中易变的细节，通过从抽象派生出实现类来扩展。

装饰者模式

一个类应该有且仅有一个引起它变化的原因，该类的职责是唯一的，且这个职责是唯一引起其他类变化的原因,否则类应该被拆分（There should never be more than one reason for a class to change）。

降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。

系统解耦合

提高类的可读性。复杂性降低，自然其可读性会提高。

提高系统的可维护性。可读性提高，那自然更容易维护了。

变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。

SingleResponsibility

SingleResponsibility2

SingleResponsibility3

将不同的职责封装到不同的类或者模块中。

当有新的需求将现有的职责分为颗粒度更小的职责的时候，应该及时对现有代码进行重构。

当系统逻辑足够简单，方法足够少，子类够少或后续关联够少时，也可以不必严格遵循SRP原则，避免过度设计、颗粒化过于严重。

只有类中方法数量足够少,可以在方法级别保持单一职责原则;

迭代器模式

优点

缺点

如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2 时，程序P的行为没有发生变化，那么类型 S 是类型 T 的子类型。

所有引用基类的地方必须能透明地使用其子类的对象。

避免系统继承体系被破坏,为良好的继承定义了一个规范。

是实现开闭原则的重要方式之一。

它克服了继承中重写父类造成的可复用性变差的缺点。

它是动作正确性的保证。即类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性。

子类可以实现父类的抽象方法，但是不能覆盖父类的非抽象方法；

子类中可以增加自己特有的方法；

当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松；

当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

如果子类不能完整地实现父类的方法，或者父类的一些方法在子类中已经发生畸变(鸵鸟是鸟不会飞)，则建议断开继承关系，采用依赖，聚合，组合等关系代替继承。

依赖正置:

依赖倒置:

High level modules should not depend upon low level modules. Both should depend up on abstractions. Abstractions should not depend upon details. Details should depend upon abstractions。

高层模块不应该依赖低层模块，二者都应该依赖其抽象；

抽象不应该依赖细节；

细节应该依赖抽象 ;

减少类间的耦合性,提高系统的稳定性,降低并行开发引起的风险,提高代码的可读性和可维护性;

原始

改进后

面向接口编程，使用接口或者抽象类制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

变量的表面类型,尽量是接口或者抽象类;

任何类都不应该从具体类派生;

尽量不要覆写基类(抽象类)的实现的方法;

结合里氏替换原则使用;

它是实现开闭原则的重要途径;

工厂模式

Clients should not be forced to depend upon interfaces that they don't use.（客户端不应该依 赖它不需要的接口。）

The dependency of one class to another one should depend on the smallest possible interface. （类间的依赖关系应该建立在最小的接口上。）

避免接口过于臃肿

接口要尽量小

接口要高内聚

定制服务

接口设计是有限度的

一个对象应该对其他对象有最少的了解 ;

Talk only to your immediate friends and not to strangers。（只与直接的朋友通信。）

降低了类之间的耦合度，提高了模块的相对独立性。

由于亲合度降低，从而提高了类的可复用率和系统的扩展性。

[object Object]

在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标。

在类的结构设计上，尽量降低类成员的访问权限。

在类的设计上，优先考虑将一个类设置成不变类。

在对其他类的引用上，将引用其他对象的次数降到最低。

不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）。

谨慎使用序列化（Serializable）功能。

外观模式

中介者模式

当要扩展类的功能时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。

如果要使用继承关系，则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范。

防止类的体系庞大

通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。

当类与类之间的关系是"Is-A"时，用继承；当类与类之间的关系是"Has-A"时，用组合。

桥接模式

是将对象的创建与使用分离.

是“怎样创建对象？”，它的主要特点是“将对象的创建与使用分离”。

这样可以降低系统的耦合度，使用者不需要关注对象的创建细节，对象的创建由相关的工厂来完成。

类创建型模式

对象创建型模式

如何将类或对象按某种布局组成更大的结构。

它分为类结构型模式和对象结构型模式，前者采用继承机制来组织接口和类，后者釆用组合或聚合来组合对象。

对象结构型模式

类结构型模式

用于描述程序在运行时复杂的流程控制，即描述多个类或对象之间怎样相互协作共同完成单个对象无法单独完成的任务，它涉及算法与对象间职责的分配。

按照其显示方式的不同，行为型模式可分为类行为模式和对象行为模式.

由于组合关系或聚合关系比继承关系耦合度低，满足“合成复用原则”所以对象行为模式比类行为模式具有更大的灵活性。

类型为模式

对象行为模式

指一个类只有一个实例，且该类能自行创建这个实例的一种模式。

单例类只有一个实例对象；

该单例对象必须由单例类自行创建；

单例类对外提供一个访问该单例的全局访问点；

8种

由于单例模式在内存中只有一个实例,减少了内存开支,特别是一个对象需要频繁地创建,销毁时,而且创建或销毁时性能又无法优化.

由于单例模式只生成一个实例，所以减少了系统的性能开销，当一个对象的产生需要 比较多的资源时，如读取配置、产生其他依赖对象时，则可以通过在应用启动时直接产生一 个单例对象，然后用永久驻留内存的方式来解决（在Java EE中采用单例模式时需要注意JVM 垃圾回收机制）。

单例模式可以避免对资源的多重占用，例如一个写文件动作，由于只有一个实例存在 内存中，避免对同一个资源文件的同时写操作。

单例模式可以在系统设置全局的访问点，优化和共享资源访问，例如可以设计一个单 例类，负责所有数据表的映射处理。

需要频繁的进行创建和销毁的对象；

创建对象时耗时过多或耗费资源过多，但又经常用到的对象；

工具类对象；

频繁访问数据库或文件的对象。

一个类的行为或其算法可以在运行时更改。这种类型的设计模式属于行为型模式。

把变化的代码从不变的代码中抽离出来

针对接口编程而不是具体类(定义了策略接口)

多用组合/聚合,少用继承(客户通过组合方式使用策略)

算法可以自由切换。

避免使用多重条件判断。

扩展性良好。

策略类会增多。

所有策略类都需要对外暴露。

分支主题

依赖关系(dependency)

泛华/继承(generalization)

实现(implementation)

关联(association)

聚合(aggregation)

组合(composition)