设计模式

---

采用模式时必须要考虑到这么做是否有意义，绝对不能为了使用模式而使用模式。

策略模式

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

场景：模拟鸭子游戏。游戏中会出现各种鸭子，一边游泳戏水，一边呱呱叫。

封装变化的代码

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

把会变化的部分取出并封装起来，以便以后可以轻易地改动或扩充此部分，而不影响不需要变化的其他部分。

针对接口编程

针对接口编程，而不是针对实现编程。

”针对接口编程“ 真正的意思是 ”针对超类型（supertype）编程“。

多用组合，少用继承

使用组合建立系统具有很大的弹性，不仅可将算法族封装成类，更可以 “在运行时动态地改变行为”，只要组合的行为对象符合正确的接口标准即可。

观察者模式

观察者模式定义对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。

场景：气象监测应用，有三种布告板，分别显示目前的状况、气象统计及简单的预报。当 WeatherObject 对象获得最新的测量数据时，三种布告板必须实时更新。

松耦合的威力

为了交互对象之间的松耦合设计而努力。松耦合将对象之间的互相依赖降到了最低。

举例：Java 内置的观察者

装饰者模式

装饰者模式动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。

场景：星巴兹咖啡连锁店的订单系统，订单系统必须考虑加入的各种调料对价格的影响。

开放-关闭原则

类应该对扩展开放，对修改关闭。

举例：Java I/O

工厂方法模式

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

场景：披萨的制作。

抽象工厂模式

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

依赖倒置原则

要依赖抽象，不要依赖具体类。

单件模式

单件模式确保一个类只有一个实例，并提供一个全局访问点。

场景：巧克力工厂。

注意 Java 多线程引起的创建单例模式出错问题。

命令模式

命令模式将“请求”封装成对象，以便使用不同的请求，队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。

场景：具有七个可编程插槽的遥控器，每个插槽都有对应的开关按钮。这个遥控器还具备一个整体的撤销按钮。创建一组控制遥控器的 API，让每个插槽都能够控制一个或一组装置。

适配器模式与外观模式

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

场景：如果你需要在欧洲国家使用美国制造的笔记本电脑，你可能需要使用一个交流电的适配器。

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

场景：家庭影院，将观赏电影所需要的一系列步骤封装到一个新类中，简化观赏电影的步骤。

最少知识原则

最少知识原则：只和你的密友交谈。

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

模板方法模式

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

场景：冲咖啡和冲茶的步骤部分一样，部分不一样。

好莱坞原则

别调用我，我会调用你。高层组件控制何时以及如何让低层组件参与，低层组件绝对不可以直接调用高层组件。

迭代器与组合模式

迭代器模式提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露其内部的表示。

场景：对乡村餐厅和对象村煎饼屋合并了。如何将两家餐厅的菜单合并呢？

单一责任原则

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

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

状态模式

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

场景：万能糖果公司的糖果机控制器。

代理模式

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

场景：远程查看糖果机的库存和机器状态的报告。

复合模式

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

场景：重建鸭子模拟器。

参考文档：
Head First 设计模式