设计模式-Design Patterns

设计模式的概念和分类如下：

 

below from wiki:

Classification and list

Design patterns were originally grouped into the categories: creational patterns, structural patterns, and behavioral patterns, and described using the concepts of delegation, aggregation, and consultation.

 

Name	Description	In Design Patterns	In Code Complete[12]	In POSA2[13]	In PoEAA[14]
Creational patterns
Abstract factory	Provide an interface for creating families of related or dependent objects without specifying their concrete classes.	Yes	Yes	No	No
Builder	Separate the construction of a complex object from its representation so that the same construction process can create different representations.	Yes	No	No	No
Factory method	Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.	Yes	Yes	No	No
Lazy initialization	Tactic of delaying the creation of an object, the calculation of a value, or some other expensive process until the first time it is needed.	No	No	No	Yes
Multiton	Ensure a class has only named instances, and provide global point of access to them.	No	No	No	No
Object pool	Avoid expensive acquisition and release of resources by recycling objects that are no longer in use. Can be considered a generalisation of connection pool and thread pool patterns.	No	No	No	No
Prototype	Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.	Yes	No	No	No
Resource acquisition is initialization	Ensure that resources are properly released by tying them to the lifespan of suitable objects.	No	No	No	No
Singleton	Ensure a class has only one instance, and provide a global point of access to it.	Yes	Yes	No	No
Structural patterns
Adapter or Wrapper	Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.	Yes	Yes	No	No
Bridge	Decouple an abstraction from its implementation so that the two can vary independently.	Yes	Yes	No	No
Composite	Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.	Yes	Yes	No	No
Decorator	Attach additional responsibilities to an object dynamically keeping the same interface. Decorators provide a flexible alternative to subclassing for extending functionality.	Yes	Yes	No	No
Facade	Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.	Yes	Yes	No	No
Flyweight	Use sharing to support large numbers of fine-grained objects efficiently.	Yes	No	No	No
Proxy	Provide a surrogate or placeholder for another object to control access to it.	Yes	No	No	No
Behavioral patterns
Blackboard	Generalized observer, which allows multiple readers and writers. Communicates information system-wide.	No	No	No	No
Chain of responsibility	Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.	Yes	No	No	No
Command	Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.	Yes	No	No	No
Interpreter	Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.	Yes	No	No	No
Iterator	Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.	Yes	Yes	No	No
Mediator	Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.	Yes	No	No	No
Memento	Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later.	Yes	No	No	No
Null object	Avoid null references by providing a default object.	No	No	No	No
Observer or Publish/subscribe	Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.	Yes	Yes	No	No
Specification	Recombinable business logic in a boolean fashion	No	No	No	No
State	Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.	Yes	No	No	No
Strategy	Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.	Yes	Yes	No	No
Template method	Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.	Yes	Yes	No	No
Visitor	Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.	Yes	No	No	No
Concurrency patterns
Active Object	Decouples method execution from method invocation that reside in their own thread of control. The goal is to introduce concurrency, by using asynchronous method invocation and a scheduler for handling requests.	No	No	Yes	No
Balking	Only execute an action on an object when the object is in a particular state.	No	No	No	No
Binding Properties	Combining multiple observers to force properties in different objects to be synchronized or coordinated in some way.[15]	No	No	No	No
Double-checked locking	Reduce the overhead of acquiring a lock by first testing the locking criterion (the 'lock hint') in an unsafe manner; only if that succeeds does the actual lock proceed. Can be unsafe when implemented in some language/hardware combinations. It can therefore sometimes be considered an anti-pattern.	No	No	Yes	No
Event-based asynchronous	Addresses problems with the Asynchronous pattern that occur in multithreaded programs.[16]	No	No	No	No
Guarded suspension	Manages operations that require both a lock to be acquired and a precondition to be satisfied before the operation can be executed.	No	No	No	No
Lock	One thread puts a "lock" on a resource, preventing other threads from accessing or modifying it.[17]	No	No	No	Yes
Monitor object	An object whose methods are subject to mutual exclusion, thus preventing multiple objects from erroneously trying to use it at the same time.	No	No	Yes	No
Reactor	A reactor object provides an asynchronous interface to resources that must be handled synchronously.	No	No	Yes	No
Read-write lock	Allows concurrent read access to an object but requires exclusive access for write operations.	No	No	No	No
Scheduler	Explicitly control when threads may execute single-threaded code.	No	No	No	No
Thread pool	A number of threads are created to perform a number of tasks, which are usually organized in a queue. Typically, there are many more tasks than threads. Can be considered a special case of the object pool pattern.	No	No	No	No
Thread-specific storage	Static or "global" memory local to a thread.	No	No	Yes	No

 

由上面图示我们可以清楚的看到出现在GOF中的23中设计模式。

GOF设计模式介绍：

below from wiki:

Design Patterns: Elements of Reusable Object-Oriented Software (ISBN 0-201-63361-2) is a software engineering book describing recurring solutions to common problems in software design. The book's authors are Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides with a foreword by Grady Booch. They are often referred to as the Gang of Four, or GoF^[1]. The book is divided into two parts, with the first two chapters exploring the capabilities and pitfalls of object-oriented programming, and the remaining chapters describing 23 classic software design patterns. The book includes examples in C++ and Smalltalk. It won a Jolt productivity award, and Software Development productivity award in 1994.^[2]

The original publication date of the book was October 21, 1994 with a 1995 copyright, and as of April 2007, the book was in its 36th printing. The book was first made available to the public at OOPSLA meeting held in Portland, Oregon in October 1994. It has been highly influential to the field of software engineering and is regarded as an important source for object-oriented design theory and practice. More than 500,000 copies have been sold in English and in 13 other languages.

 

 

Design Patterns: Elements of Reusable Object-Oriented Software（即《设计模式》一书），由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 合著（Addison-Wesley，1995）。这几位作者常被称为"四人组（Gang of Four）"，而这本书也就被称为"四人组（或 GoF）"书。

 

在《设计模式》这本书的最大部分是一个目录，该目录列举并描述了 23 种设计模式。另外，近来这一清单又增加了一些类别，最重要的是使涵盖范围扩展到更具体的问题类型。例如，Mark Grand 在 Patterns in Java: A Catalog of Reusable Design Patterns Illustrated with UML（即《模式 Java 版》一书）中增加了解决涉及诸如并发等问题的模式，而由 Deepak Alur、John Crupi 和 Dan Malks 合著的 Core J2EE Patterns: Best Practices and Design Strategies 一书中主要关注使用 Java 2 企业技术的多层应用程序上的模式。

对软件设计模式的研究造就了一本可能是面向对象设计方面最有影响的书籍：《设计模式》。

 

GOF的设计模式是一座"桥" ，就Java语言体系来说，GOF的设计模式是Java基础知识和J2EE框架知识之间一座隐性的"桥"。

 

会Java的人越来越多，但是一直徘徊在语言层次的程序员不在少数，真正掌握Java中接口或抽象类的应用不是很多，大家经常以那些技术只适合大型项目为由，避开或忽略它们，实际中，Java的接口或抽象类是真正体现Java思想的核心所在，这些你都将在GoF的设计模式里领略到它们变幻无穷的魔力。 

GoF的设计模式表面上好像也是一种具体的"技术"，而且新的设计模式不断在出现，设计模式自有其自己的发展轨道，而这些好像和J2EE .Net等技术也无关！

 

实际上，GoF的设计模式并不是一种具体"技术",它讲述的是思想，它不仅仅展示了接口或抽象类在实际案例中的灵活应用和智慧，让你能够真正掌握接口或抽象类的应用，从而在原来的Java语言基础上跃进一步，更重要的是，GoF的设计模式反复向你强调一个宗旨：要让你的程序尽可能的可重用。

 

这其实在向一个极限挑战：软件需求变幻无穷，计划没有变化快，但是我们还是要寻找出不变的东西，并将它和变化的东西分离开来，这需要非常的智慧和经验。

 

而GoF的设计模式是在这方面开始探索的一块里程碑。

 

J2EE等属于一种框架软件，什么是框架软件？它不同于我们以前接触的Java API等，那些属于Toolkist(工具箱)，它不再被动的被使用，被调用，而是深刻的介入到一个领域中去，J2EE等框架软件设计的目的是将一个领域中不变的东西先定义好，比如整体结构和一些主要职责(如数据库操作 事务跟踪 安全等)，剩余的就是变化的东西，针对这个领域中具体应用产生的具体不同的变化需求，而这些变化东西就是J2EE程序员所要做的。

 

由此可见，设计模式和J2EE在思想和动机上是一脉相承，只不过

      1.设计模式更抽象，J2EE是具体的产品代码，我们可以接触到，而设计模式在对每个应用时才会产生具体代码。
      2.设计模式是比J2EE等框架软件更小的体系结构，J2EE中许多具体程序都是应用设计模式来完成的，当你深入到J2EE的内部代码研究时，这点尤其明显，因此，如果你不具备设计模式的基础知识(GoF的设计模式)，你很难快速的理解J2EE。不能理解J2EE,如何能灵活应用？
      3.J2EE只是适合企业计算应用的框架软件，但是GoF的设计模式几乎可以用于任何应用！因此GoF的设计模式应该是J2EE的重要理论基础之一。

 

所以说，GoF的设计模式是Java基础知识和J2EE框架知识之间一座隐性的"桥"。为什么说隐性的？ 

因为很多人没有注意到这点，学完Java基础语言就直接去学J2EE,有的甚至鸭子赶架，直接使用起Weblogic等具体J2EE软件，一段时间下来，发现不过如此，挺简单好用，但是你真正理解J2EE了吗？你在具体案例中的应用是否也是在延伸J2EE的思想？

      如果你不能很好的延伸J2EE的思想，那你岂非是大炮轰蚊子，认识到J2EE不是适合所有场合的人至少是明智的，但我们更需要将J2EE用对地方，那么只有理解J2EE此类框架软件的精髓，那么你才能真正灵活应用Java解决你的问题，甚至构架出你自己企业的框架来。(我们不能总是使用别人设定好的框架，为什么不能有我们自己的框架？)

      因此，首先你必须掌握GoF的设计模式。虽然它是隐性，但不是可以越过的。