AlphaCat的博客

一个类应该只有一个引起变化的原因高内聚优点：OCP缺点：类成对增加public interface Iterator{ boolean hasNext(); //返回一个布尔值，判断是否还有更多的元素 Object next(); //返回下一个元素}//实现迭代器接口 PancakeHouseMenupublic class PancakeHouseMenuIterator implements Iterator { ArrayList<Menu.

设计模式的代码仓库：设计模式适用环境：i. 一次性实现一个算法的不变的部分，并将可变的行为留给子类来实现。ii. 各子类中公共的行为应被提取出来并集中到一个公共父类中以避免代码重复。iii. 对一些复杂的算法进行分割，将其算法中固定不变的部分设计为模板方法和父类具体方法，而一些可以改变的细节由其子类来实现。iv. 控制子类的扩展。好莱坞原则：Don’t call me, we’ll call you.进一步3：策略模式与模板方法模式比较策略模式和模板方法模式很像，都是针对算法改变的情况

设计模式的代码仓库：设计模式1． 模式动机：引入外观角色后，用户只需要直接与外观角色交互，用户与子系统之间的复杂关系由外观角色来实现，降低了系统的耦合度。2． 原则应用：1） 单一职责原则。系统划分为多个子系统有利于降低系统的复杂性。外观模式中，将系统划分出多个子系统，使他们之间通信和相互依赖关系达到最小。外观对象为子系统的访问提供了一个简单又单一的入口。2） 迪米特法则——对象对另一个对象应尽可能少地了解，不和陌生人说话。通过引入外观类，降低了原有系统的复杂度，同时降低客户端与子系统类的耦

设计模式的代码仓库：设计模式外观和适配器可以包裹多个类，但外观的目的是简化，而适配器的目的是将接口转换为不同的东西。OO原则：使用组合优点：符合OCP目标类和适配类解耦增加类的透明性和复用性public interface IMediaPlayer { public void play(String audioType, String fileName);}public interface IMp4MediaPlayer { public void playMp4

命令队列和宏命令（MacroCommand，又称为组合命令，是命令模式和组合模式联用） 需要掌握优点：降低系统耦合度新命令容易加到系统中容易设计命令队列和宏命令方便Undo和Redo缺点：过多具体命令类public interface ICommand { void execute();}public class ConcreteCommandA implements ICommand { private Receiver receiver; publ.

设计模式的代码仓库：设计模式优点：增加新的工厂和产品族比较方便，符合开闭原则隔离了具体类的生成保证客户端只使用同一个产品族的对象缺点：难以扩展抽象工厂来生产新种类的产品增加新的产品等级结构困难interface Factory{ Product manufacture();}public class FactoryA implements Factory { @Override public Product manufacture() {

具体定义：工厂方法模式定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。优点：用户并不知道什么具体产品类被实例化当系统扩展需要添加新的产品对象时，仅仅需要添加一个具体产品对象以及一个具体工厂对象，原有工厂对象不需要进行任何修改，也不需要修改客户端，很好地符合了“开闭原则”。工厂自主决定创建什么对象缺点：复杂度依赖倒置public abstract class Pizza { public String name; public .

目的：动态地将额外的责任附加到一个对象上。装饰器为扩展功能提供了一个灵活的替代子类OO Principles：封装OCP优点：具体构件类和具体装饰类可以独立变化可以创造很多不同行为的组合动态的方式扩展一个对象的功能比继承更灵活缺点：容易出错产生许多小对象，增加系统复杂度矩形的例子（来自菜鸟）public interface Shape { void draw();}public class Circle implements Shape { @Over.

目的：定义对象之间的一对多依赖关系，这样当一个对象改变状态时，所有的依赖对象都会得到通知并自动更新在某些情况下，观察者依赖一个以上的主体可能是有意义的。例如，一个电子表格可能依赖于多个数据源。在这种情况下，有必要扩展Update接口，让观察者知道是哪个主题在发送通知。在Update操作中，主体可以简单地将自己作为参数传递，从而让观察者知道要检查哪个主体。主体和它的观察者依靠通知机制来保持一致。但实际上是什么对象调用Notify来触发更新呢？这里有两种选择。让Subject上的状态设置操作在改变主体.

与策略模式一样？是的，类图本质上是一样的，但两种模式的意图不同。对于状态模式，我们有一组行为封装在状态对象中；在任何时候，上下文都在委托给其中的一个状态。随着时间的推移，当前的状态会在状态对象集合中发生变化，以反映上下文的内部状态，所以上下文的行为也会随着时间的推移而变化。客户端通常对状态对象知之甚少，甚至一无所知。对于Strategy，客户端通常会指定上下文组成的策略对象。现在，虽然该模式提供了在运行时改变策略对象的灵活性，但往往有一个策略是最适合上下文对象的。一般来说，把Strategy .

设计模式的代码仓库：设计模式目的：定义一个算法家族，封装每一个算法，并使它们可以互换。策略让算法独立于使用它的客户而变化适用性：许多相关的类仅在行为上有所不同.策略提供了一种方法来配置一个具有多种行为之一的类。算法使用客户不应该知道的数据。使用Strategy模式来避免暴露复杂的、特定于算法的数据结构一个类定义了许多行为，这些行为在其操作中以多个条件语句的形式出现.与其说是许多条件语句，不如说是把相关的条件分支移到自己的Strategy类中客户必须了解不同的策略。这种模式有一个潜在的缺点，

public interface Icon { int getIconWidth(); int getIconHeight(); void paintIcon(Component c, Graphics g, int x, int y);}public class ImageProxy implements Icon { ImageIcon imageIcon; URL imageURL; Thread retrievalThread; bool

组合模式用单一责任设计原则换取了透明性。通过让组件的接口同时包含一些管理子节点和叶节点的操作，客户就可以将composite和leaf一视同仁，一个元素究竟是composite还是leaf，对于客户是透明的MenuComponent类中同时具有两种类型的操作。因为客户有机会对一个元素做一些不恰当或者无意义的操作(例如试图将菜单添加到菜单项中)，所以我们失去了一些“安全性”。这是设计上的抉择；我们也可以采用另一种设计：将责任区分开来放在不同的接口中，这样一来，设计上就比较安全，但我们也因此失去了透明性，客.