Country full translation
text (English) Links: http://tmrts.com/go-patterns
introduction to design patterns
Design patterns (Design pattern) represents a best practice, commonly used by experienced object-oriented software developers. Design patterns are solutions to common problems faced by software developers in the software development process. These solutions are numerous software developers through trial and error for a long period of time summed up.
golang design patterns
1. Create a class ( Creational Patterns)
| first name | description | status |
| Abstract Factory (Abstract Factory) | It provides an interface for creating objects or abstract methods related to the family. | ✘ |
| Builders mode (Builder) | Build complex objects using Simple Object | ✔ |
| Factory pattern (Factory Method) | Examples of the delayed object to the dedicated function to create instances | ✔ |
| Pooled modes (Object Pool) | Examples of a group and maintain the same type of object instance | ✔ |
| Singleton pattern (the Singleton) | Examples of the type of the limit to only one object instance | ✔ |
2. structural class (Structural Patterns)
| first name | description | status |
| Bridge mode (Bridge) | Separation interface therewith, so that the two can vary independently | ✘ |
| Combined mode (Composite) | Package and provides access to a number of different objects | ✘ |
| Decorator (the Decorator) | Statically or dynamically add behavior to pair |
✔ |
| Appearance mode (the Facade) | One type as the many other types of API | ✘ |
| Flyweight (the Flyweight) | Examples of similar or identical to reuse the existing state of the object, in order to minimize resource use | ✘ |
| Agent mode (Proxy) | Providing an object alternatives to control its operation | ✘ |
3. Action (Behavioral Patterns)
| first name | description | status |
| Chain of Responsibility pattern (Chain of Responsibility) | To process the request by providing more opportunities to the subject, thereby avoiding the sender to the recipient couple | ✘ |
| Command Mode (Command) | Bundled commands and parameters for later recall |
✘ |
| Intermediary model (Mediator) | And acts as a proxy connection object |
✘ |
| Memo mode (Memento) | 生成不透明的令牌，该令牌可用于返回到先前的状态 | ✘ |
| 观察者模式(Observer) | 提供回调以通知事件或数据更改 | ✔ |
注册模式(Registry) |
跟踪给定类的所有子类 |
✘ |
| 状态模式(State) | 根据其内部状态封装不同对象的行为 | ✘ |
| 策略模式(Strategy) | 允许在运行时选择算法的行为 |
✔ |
| 模版模式(Strategy) | 定义一个骨架类，该骨架类将某些方法推迟到子类 | ✘ |
| 访问者模式(Visitor) | 将算法与对其进行操作的对象分开 | ✘ |
4. 同步类( Synchronization Patterns)
| 名字 | 描述 | 状态 |
| 条件变量(Condition Variable) | 提供一种机制，线程可以暂时放弃访问以等待某种条件 | ✘ |
| 互斥锁(Lock/Mutex) | 对资源强制实施互斥限制以获取互斥访问 |
✘ |
| 监视器(Monitor) | 互斥量和条件变量模式的组合 | ✘ |
| 读写锁(Read-Write Lock) | 允许并行读取访问，但仅对资源的写入操作具有独占访问权限 | ✘ |
| 信号量(Semaphore) | 允许控制对公共资源的访问 |
✔ |
5. 并发类(Concurrency Patterns)
| 名字 | 描述 | 状态 |
| N屏障(N-Barrier) | 阻止进程在所有N个进程到达障碍之前进行 | ✘ |
| 受限并行(Bounded Parallelism) | 在资源有限的情况下完成大量独立任务 | ✔ |
| 广播(Broadcast) | 同时将消息传送给所有收件人 |
✘ |
| 协程(Coroutines) | 允许在某些位置挂起和恢复执行的子例程 | ✘ |
| 生成器(Generators) | 一次产生一个值序列 | ✔ |
| 反应器(Reactor) | 解复用同时传递给服务处理程序的服务请求，并同步地将它们分派给关联的请求处理程序 | ✘ |
| 并行(Parallelism) | 完成大量独立任务 | ✔ |
| 生产者消费者(Producer Consumer) | 将任务与任务执行分离 | ✘ |
6. 消息类(Messaging Patterns)
| 名字 | 描述 | 状态 |
扇入(Fan-In) |
将任务集中到工作接收器（例如服务器） |
✔ |
| 扇出(Fan-Out) | 在workers（例如生产者）之间分配任务 | ✔ |
| Futures & Promises | 充当结果的占位符，该结果最初出于同步目的是未知的 | ✘ |
| 发布/订阅(Publish/Subscribe) | 将信息传递给订阅主题的收件人的集合 | ✔ |
| 推/拉(Push & Pull) | 将消息分发给安排在管道中的多个工作人员 | ✘ |
7. 稳定类(Stability Patterns)
| 名字 | 描述 | 状态 |
| 隔板模式(Bulkheads) | 实施故障遏制原则（即防止级联故障） | ✘ |
| 断路器模式(Circuit-Breaker) | 当请求可能失败时，停止请求流 | ✔ |
| 期限模式(Deadline) | 一旦响应的可能性变低（例如，在等待10秒钟的页面刷新之后），客户端就可以停止等待响应 | ✘ |
| 快速失败模式(Fail-Fast) | 在请求开始时检查所需资源的可用性，如果不满足要求，则失败 | ✘ |
| 握手模式(Handshaking) | 询问组件是否可以承受更多的负载，如果不能承受，则请求被拒绝 | ✘ |
| 稳定状态模式(Steady-State) | 对于每个积累资源的服务，其他一些服务必须回收该资源 | ✘ |
8. 分析类(Profiling Patterns)
| 名字 | 描述 | 状态 |
| 计时功能(Timing Functions) | 包装函数并记录执行 |
✔ |
9. 惯用类(Idioms)
| 名字 | 描述 | 状态 |
| 功能选项(Functional Options) | 允许使用默认设置和惯用替代创建干净的API | ✔ |
10. 反面类(Anti-Patterns)
| 名字 | 描述 | 状态 |
| 级联故障(Cascading Failures) | 互连零件系统中的故障，其中零件的故障会导致多米诺骨牌效应 | ✘ |
关注编程之颠，带来更多go编程知识