23常用设计模式的UML

Prototype 模式
通过给出一个原型对象来指明所要创建的对象的类型，然后用赋值这个原型对象的办法创 建出更多同类型的对象。
Cloneable
Client +Operation()
<<prototype>>
<<interface>> Prototype
+clone(): Object
p = prototype.clone();
<<interface>> Component
+getComposite(): Composite
0..*
+operation(): void
Leaf
+getComposite(): Composite +operation(): void
Composite
-components: List
+getComposite(): Composite +operation(): void +add(): void +remove(): void +components(): List
public void operation() { component.operation();
}
ComcreteDecoratorA -AddedState +operation(): void
ComcreteDecoratorB
+operation(): void +addBehavior()
public void operation() { super.operation(); //在 此 或 者 其 他 地 方 添 加 行 为 ， 以 扩 展 Component addBehavior();
是产品对象的一个组成部分。 需要生成的产品对象的属性相互以来。Builder 模式可以强制实行一种分步骤进行的建
造过程，因此，如果产品对象的一个属性必须在另一个属性被赋值之后才可以被赋值， 使用建造模式便是一个很好的设计思想。 在对象创建过程中会使用到系统中的其他一些对象，这些对象在产品对象的创建过程 中不易得到。
2. 透明式的 Composite 模式
<<interface>> Component
0..* +getComposite(): Composite
0..*
+operation(): void
+components(): List
+add(): void
+remove(): void
Leaf
+getComposite(): Composite +operation(): void +add(): void +remove(): void +components(): List
Factory 模式
1. 简单工厂模式，又称静态工厂模式
<<interface>> Product
Creator +factory(): Product
<<create>>
ConcreteProduct
2. 工厂方法模式
<<interface>> Creator
+factory(): Product
一些可能在将来引进的类一起工作。这些源类不一定有很复杂的接口。 （对对象的 Adapter 模式而言）在设计里，需要改变多个已有的子类的接口，如果使
用类的 Adapter 模式，就要针对每一个子类做一个 Adapter 类，而这不太实际。
Composite 模式
把部分和整体的关系用树结构表示出来。Composite 模式使得客户端把一个个单独的成分对 象和由他们符合而成的合成对象同等看待。 1. 安全式的 Composite 模式
+operationB()
Adapter
2. 对象的 Adapter 模式的结构
期待得到的接口，即 operationA()和 operationB()
已经存 在的接口（operationA()）， 即需要适配的接口
<<interface>> Target
+operationA() +operationB()
Director
-builder: Builder
+Director() +construct(): void
Builder
+buildPart1(): void +buildPart2(): void +getResult(): Product
<<interface>> Product
public void construct() { builder = new ConcreteBuilder(); builder.buildPart1(); builder.buildPart2(); builder.getResult(); //other code
Composite
-components: List
+getComposite(): Composite +operation(): void +add(): void +remove(): void +components(): List
Decorator 模式
此模式又称 Wrapper 模式。是以对客户端透明的方式扩展对象的功能，是继承关系的一个替 代方案。
<<interface>> Creator
+factoryA(): ProductA +factoryB(): ProductB
ConcreteCreator1
+factoryA(): ProductA +factoryB(): ProductB
<<create>>
<<create>>
ConcreteCreator2 +factoryA(): ProductA +factoryB(): ProductB
ConcretePrototype1 +clone(): Object
ConcretePrototype2 +clone(): Object
Adapter 模式
把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一 起工作的两个类能够在一起工作，也就是说把接口不同而功能相同或相近的多个接口加以 转换。
<<interface>> ProductA
ProductA1 <<create>>
ProductB1
<<create>>
ProductA2 ProductB2
<<interface>> ProductB
Singleton 模式
要点： 类只能有一个实例 必须自行创建这个实例 必须自行向外界提供这个实例
外部状态不可以影响 Flyweight 对象的内部状态。它们是相互独立的。 1. 单纯 Flyweight 模式的结构
FlyweightFactory
+files: HashMap
+FlyweightFactory() +getFlyweight(internal state): Flyweight
内部状态是存储在 Flyweight 对象内部的，并且是不会随环境改变而有所不同的。因此， 一个 Flyweight 可以具有内部状态并可以共享。
外部状态是随环境改变而改变的、不可以共享的状态。Flyweight 对象的外部状态必须 有客户端保存，并在 Flyweight 对象被创建之后，在需要使用的时候再传入到 Flyweight 对象内部。
+operation(): void
ComcreteComponent +operation(): void
ComcreteDecorator
-component: Component
+ComcreteDecorator() +operation(): void
2. 没有抽象接口 Component
<<interface>> Flyweight
+operation(external state): void
public Flyweight getFlyweight(internal state) { if(files.containsKey(internal state)) { return (Flyweight)files.get(internal state); } else { Flyweight fly = new ConcreteFlyweight(internal state); files.put(internal state, fly); return fly; }
1. 类的 Adapter 模式的结构
期待得到的接口，即 operationA()和 operationB()
已经存 在的接口（operationA()）， 即需要适配的接口
<<interface>> Target
+operationA() +operationB()
Adaptee +operationA()
ComcreteComponent +operation(): void
Decorator +component: Component +Decorator() +Decorator() +operation(): void
ComcreteDecorator
+operation(): void
Proxy 模式
<<interface>> Component
+operation(): void
ComcreteComponent +operation(): void
Decorator
+component: Component
+Decorator() +Decorator(: Component) +operation(): void
Proxy 模式是给某一个对象提供一个代理对象，并由代理对象控制对原对象的引用。
Client
<<interface>> Subject
+request(): void
public void request() { preRequest(); realSubject.request(); postRequest();
<<create>>
<<interface>> Product
ConcreteCreator1 +factory(): Product
ConcreteCreator2 +factory(): Product
ConcreteProduct1
ConcreteProduct2
3. 抽象工厂模式 抽象工厂模式与工厂方法模式的最大区别在于，工厂方法模式针对的是一个产品等级结构 ； 而抽象工厂模式则需要面对多个产品等级结构。
}源自文库
在以下情况下 Decorator 模式： 需要扩展一个类的功能，或给一个类增加附加责任。 需要动态地给一个对象增加功能，这些功能可以再动态的撤销。 需要增加由一些基本功能的排列组合个数的功能，从而使继承关系变得不现实。 Decorator 模式的简化 1. 没有抽象的 Decorator
<<interface>> Component
Adaptee +operationA()
Adapter -adaptee: Adaptee +Adapter(: Adaptee) +operationA() +operationB()
注意两种结构的区别：主要就是 Adaptee 和 Adapter 的关系，一个为继承关系，一个为依
赖关系。 使用 Adapter 模式的场合： 系统需要使用现在的类，而此类的接口不符合系统的需要。 想要建立一个可以重复使用的类，用语与一些彼此之间没有太大关联的一些类，包括
}
ProxySubject
+realSubject: RealSubject
+ProxySubject() +request(): void +preRequest() +postRequest()
RealSubject
+RealSubject() +request()
Flyweight 模式
Flyweight 模式以共享的方式高效地支持大量的细粒度对象。Flyweight 对象能做到共 享的关键是区分内部状态（Internal state）和外部状态（External state）。
}
ConcreteBuilder
+buildPart1(): void +buildPart2(): void +getResult(): Product
<<create>>
Product1
使用 Builder 模式的场合： 需要生成的产品对象有复杂的内部结构。每一个内部成分本身可以是对象，也可以紧紧
Builder 模式
Builder 模式利用一个 Director 对象和 ConcreteBuilder 对象一个一个地建造出所有的零 件，从而建造出完整的 Product。Builder 模式将产品的结构和产品的零件建造过程对客户 端隐藏起来，把对建造过程进行指挥的责任和具体的建造者零件的责任分割开来，达到责 任划分和封装的目的。