设计模式ch0 Intro

The GoF Patterns

设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。

每种模式在现实中都有相应的原理来与之对应，每种模式都描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是设计模式能被广泛应用的原因。

在 1994 年，由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人合著出版了一本名为 Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素）的书，该书首次提到了软件开发中设计模式的概念。

四位作者合称 GOF（四人帮，全拼 Gang of Four），所提出的设计模式主要是基于以下的面向对象设计原则：

1. 对接口编程而不是对实现编程。
2. 优先使用对象组合而不是继承。

Creational Patterns

创建型模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用new运算符直接实例化对象，使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。

1. 工厂模式Factory method
2. 抽象工厂模式Abstract factory
3. 建造者模式Builder
4. 原型模式Prototype
5. 单例模式Singleton

Structural Patterns

结构型模式关注类和对象的组合，继承的概念被用来组合接口和定义组合对象获得新功能的方式。

1. 适配器模式Adapter
2. 桥接模式Bridge
3. 组合模式Composite
4. 装饰器模式Decorator
5. 外观模式Facade
6. 享元模式Flyweight
7. 代理模式Proxy

Behavioral Patterns

行为型模式关注对象之间的通信。

1. 责任链模式Chain of responsibility
2. 命令模式Command
3. 解释器模式Interpreter
4. 迭代器模式Iterator
5. 中介者模式Mediator
6. 备忘录模式Memento
7. 观察者模式Observer
8. 状态模式State
9. 策略模式Strategy
10. 模板模式Template method
11. 访问者模式Visitor

Summary of Patterns

Patterns	Summary
Abstract factory	You want to create objects of a selected family of classes but you don’t want the client to be affected by the choice.
Adapter	You want to convert one interface to another.
Bridge	You want to switch between different implementations at run time without affecting the client.
Builder	You want to change the processes and process steps at run time to produce various categories of products.
Chain of responsibility	You want to pass a request along a reconfigurable chain of handlers until one that handles it.
Command	You want to encapsulate requests as (command) objects so that you can: (1) delegate the requests to the command objects, (2) queue the requests and execute them at a different time, (3) generate a plan of actions dynamically, and/or (4) stack the requests to support undo and redo.
Composite	You want to represent components with recursive part-whole relationships and allow the client to interact with components and composites uniformly.
Decorator	You want to dynamically add/remove functionality to/from objects.
Facade	You want to simplify the interface for a client that interacts with a web of components.
Factory method	You want to create or use objects of different classes but you want to delay the decision to the subclasses so that the decision can be changed at run time.
Flyweight	You want to save time and space incurred in the creation, initialization, and storage of many occurrences of an object.
Interpreter	You want dynamic modification of a portion of your program but you don’t want to recompile the system.
Iterator	You want a traversal mechanism that hides the structure traversed.
Mediator	You want to simplify the complex interaction among several components.
Memento	You want to store and restore the state of an object but you don’t want to expose the internals of the state to a third party.
Observer	You want to decouple change and related responses so that you can add or remove such dependencies freely and dynamically.
Prototype	You want to: (1) reduce object creation and initialization costs, (2) reduce number of classes, or (3) use dynamically loaded classes.
Proxy	You want to: (1) hide the use of a remote object, (2) defer creation of an object until it is actually used, (3) control access to an object, or (4) keep track of references or update to an object.
Singleton	You want to create at most one or a limited number of globally accessible instances of a class.
State	You want a low complexity and easy to extend solution to implement a state machine.
Strategy	You want to let the client select an algorithm from available algorithms to accomplish a given task.
Template	method You want the steps of a computation to vary but you don’t want to do so with conditional statements.
Visitor	You want to decouple type-dependent operations from a class structure to achieve high-cohesion and designing “stupid objects.”

赏

谢谢你请我吃糖果

支付宝

微信