-
Notifications
You must be signed in to change notification settings - Fork 10
4 设计模式分类
对类的实例化过程进行了抽象，能够将软件模块中对象的创建和对象的使用分离。
- 抽象工厂模式(Abstract Factory)
- 建造者模式(Builder)
- 工厂方法模式(Factory Method)
- 原型模式(Prototype)
- 单例模式(Singleton)
结构型模式主要用于处理类或对象的组合，从而应对需求变化为对象结构带来的冲击。
- 适配器模式(Adapter)
- 桥接模式(Bridge)
- 组合模式(Composite)
- 装饰模式(Decorator)
- 外观模式(Facade)
- 享元模式(Flyweight)
- 代理模式(Proxy)
行为型模式主要用于描述对类或对象怎样交互和怎样分配职责，即关注它们之间的相互作用。
- 职责链模式(Chain of Responsibility)
- 命令模式(Command)
- 解释器模式(Interpreter)
- 迭代器模式(Iterator)
- 中介者模式(Mediator)
- 备忘录模式(Memento)
- 观察者模式(Observer)
- 状态模式(State)
- 策略模式(Strategy)
- 模板方法模式(Template Method)
- 访问者模式(Visitor)
根据模式主要是用于处理类之间关系还是处理对象之间的关系，可分为类模式和对象模式两种。
类模式处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，是属于静态的。
对象模式处理对象间的关系，这些关系在运行时刻变化，更具动态性。
现代软件专业分工的第一个结果是"框架与应用的划分"，组件协作模式通过晚绑定，实现框架与应用程序之间的松耦合，是二者之间协作时常用的模式。
- 模板方法模式(Template Method)
- 策略模式(Strategy)
- 观察者模式(Observer)
在软件组件设计中，如果责任划分不清晰，使用继承得到的结果往往随着需求的变化，子类急剧膨胀，同时充斥着重复代码，这时候的关键是划清责任。
- 桥接模式(Bridge)
- 装饰模式(Decorator)
通过对象创建，绕开new，来避免对象创建过程中所导致的紧耦合（依赖具体类），从而支持对象创建的稳定。它是接口抽象之后的第一步工作。
- 工厂方法模式(Factory Method)
- 抽象工厂模式(Abstract Factory)
- 原型模式(Prototype)
- 建造者模式(Builder)
面向对象很好解决了抽象的问题，但是不可避免要付出一定代价，在某些情况下面向对象带来的性能成本必须谨慎处理。
- 单例模式(Singleton)
- 享元模式(Flyweight)
在组件构建过程中，某些接口之间直接依赖会带来很多问题，甚至无法实现。采用添加一层间接（稳定）接口，来隔离本来互相紧密关联的接口。
- 外观模式(Facade)
- 代理模式(Proxy)
- 中介者模式(Mediator)
- 适配器模式(Adapter)
在组件构建过程中，某些对象状态经常变化，需要对象状态进行有效的管理，同时保持高层模块的稳定。
- 备忘录模式(Memento)
- 状态模式(State)
一些组件内部具有特定的数据结构，如果让客户依赖特定结构，将极大破坏组件的复用。这时将特定数据结构封装在内部，在外部提供统一的接口，实现数据结构无关的访问。
- 组合模式(Composite)
- 迭代器模式(Iterator)
- 职责链模式(Chain of Responsibility)
在组件的构建过程中，组件行为的变化经常导致组件本身剧烈的变化。将组建的行为和组件本身进行解耦，从而支持组件行为的变化。
- 命令模式(Command)
- 访问者模式(Visitor)
在特定领域中，某些变化虽然频繁，但可以抽象为某种规则。这时候，结合特定领域，将问题抽象为语法规则，从而给出在该领域下的一般性解决方案。
- 解释器模式(Interpreter)