head-first-design-patterns-Java

Head First设计模式 Java 版源码

设计原则

  1. 找出应用中可能需要变化之处,把它们独立出来,不要和那些不需要变化的代码混在一起。

  2. 针对接口编程,而不是针对实现编程。

  3. 多用组合,少用继承。

  4. 为了交互对象之间的松耦合设计而努力。

  5. 类应该对扩展开放,对修改关闭。

  6. 最少知识原则:只和你的密友谈话。

    这是什么意思?当你正在设计一个系统,不管是任何对象,你都要注意它所交互的类有哪些,并注意它和这些类是如何交互的。

    这个原则希望我们在设计中,不要让太多的类耦合在一起,免得修改系统中一部分,会影响到其他部分。如果许多类之间相互依赖,那么这个系统就会变成一个易碎的系统,它需要花许多成本维护,也会因为太复杂而不容易被其他人了解。

  7. 好莱坞原则:别调用我们,我们会调用你。

    好莱坞原则可以给我们一种防止“依赖腐败”的方法。当高层组件依赖底层组件,而底层组件又依赖高层组件,而高层组件又依赖边侧组件,而边侧组件又依赖底层组件时,依赖腐败就发生了。在这种情况下,没有人可以轻易地搞懂系统是如何设计的。

    在好莱坞原则之下,我们允许底层组件将自己挂钩到系统上,但是高层组件会决定什么时候和怎样使用这些底层组件。换句话说,高层组件对待底层组件的方式是“别调用我们,我们会调用你”。

  8. 一个类应该只有一个引起变化的原因

    类的每个责任都有改变的潜在区域。超过一个责任,意味着超过一个改变的区域。

    这个原则告诉我们尽量让每个类保持单一责任。

设计模式

策略模式

定义了算法族,分别封装起来,让它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。

要点:

观察者模式

在对象之间定义一对多的依赖,这样一来,当一个对象改变状态,依赖它的对象都会收到通知,并自动更新。

要点:

装饰器模式

动态地将责任附加到对象上。想要扩展功能,装饰者提供有别于继承的另一种选择。

要点:

工厂方法模式

定义了一个创建对象的接口,但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。

抽象工厂模式

提供一个接口,用于创建相关或依赖对象的家族,而不需要明确指定具体类。

要点:

单例模式

确保一个类只有一个实例,并提供一个全局访问点。

要点:

命令模式

将“请求”封装成对象,以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。(当需要将发出请求的对象和执行请求的对象解耦的时候,使用命令模式)

要点:

适配器模式

将一个类的接口,转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。

要点:

外观模式

提供了一个统一的接口,用来访问子系统中的一群接口。外观定义了一个高层接口,让子系统更容易使用。

要点:

模板方法模式

在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。

要点:

迭代器模式

提供一种方法顺序访问一个聚合对象的各个元素,而又不暴露其内部的表示。

要点:

组合模式

允许你将对象组合成树形结构来表现“整体/部分”层次结构。组合能让客户以一致的方式处理个别对象以及对象组合。

要点:

状态模式

允许对象在内部状态改变时改变它的行为,对象看起来好像修改了它的类。

要点:

代理模式

为另一个对象提供一个替身或占位符以控制对这个对象的访问。

要点:

复合模式

结合两个或以上的模式,组成一个解决方案,解决一再发生的一般性问题.

要点:

其他模式

桥接模式

使用桥接模式不只改变你的实现,也改变你的抽象。

优点:

用途和缺点:

建造者模式

使用生成器模式封装一个产品的构造过程,并允许按步骤构造。

优点:

用途和缺点:

责任链模式

当你想要让一个以上的对象有机会能够处理某个请求的时候,就使用责任链模式。

优点:

用途和缺点:

享元模式

如想让某个类的一个实例能用来提供许多“虚拟实例”,就使用享元模式。

优点:

用途和缺点:

解释器模式

使用解释器模式为语言创建解释器。

优点:

用途和缺点:

中介者模式

使用中介者模式来集中相关对象之间复杂的沟通和控制方式。

优点:

用途和缺点:

备忘录模式

当你需要让对象返回之前的状态时(例如,你的用户请求“撤销”),就使用备忘录模式。

优点:

用途和缺点:

原型模式

当创建给定类的实例的过程很昂贵或很复杂时,就使用原型模式。

优点:

用途和缺点:

访问者模式

当你想要为一个对象的组合增加新的能力,且封装并不重要时,就使用访问者模式。

优点:

用途和缺点: