(轉載)23種設計模式的uml圖表示及通俗介紹

轉載自： https://www.cnblogs.com/ningskyer/articles/3615312.html

0.分類

建立型模式 

一、FACTORY   二、BUILDER  三、FACTORY METHOD  四、PROTOTYPE  五、SINGLETON

結構型模式 

六、ADAPTER  七、BRIDGE 八、COMPOSITE  九、DECORATOR 十、FACADE  十一、FLYWEIGHT  十二、PROXY

行爲模式 

1三、CHAIN OF RESPONSIBLEITY  1四、COMMAND  1五、INTERPRETER  1六、ITERATOR  1七、MEDIATOR

1八、MEMENTO  1九、OBSERVER  20、STATE  2一、STRATEGY  2二、TEMPLATE METHOD  2三、VISITOR

1.圖示版

 

責任鏈模式

Purpose

Gives more than one object an opportunity to handle a request by linking receiving objects together.

Use When

• Multiple objects may handle a request and the handler doesn't have to be a specific object.
• A set of objects should be able to handle a request with the handler determined at runtime.
• A request not being handled is an acceptable potential outcome.

Example

Exception handling in some languages implements this pattern. When an exception is thrown in a method the runtime checks to see if the method has a mechanism to handle the exception or if it should be passed up the call stack. When passed up the call stack the process repeats until code to handle the exception is encountered or until there are no more parent objects to hand the request to.

命令模式

解釋器模式

Purpose

Defines a representation for a grammar as well as a mechanism to understand and act upon the grammar.

Use When

• There is grammar to interpret that can be represented as large syntax trees.
• The grammar is simple.
• Efficiency is not important.
• Decoupling grammar from underlying expressions is desired.

Example

Text based adventures, wildly popular in the 1980's, provide a good example of this. Many had simple commands, such as "step down" that allowed traversal of the game. These commands could be nested such that it altered their meaning. For example, "go in" would result in a different outcome than "go up". By creating a hierarchy of commands based upon the command and the qualifier (non-terminal and terminal expressions) the application could easily map many command variations to a relating tree of actions.

迭代器模式

Purpose

Allows for access to the elements of an aggregate object without allowing access to its underlying representation.

Use When

• Access to elements is needed without access to the entire representation.
• Multiple or concurrent traversals of the elements are needed.
• A uniform interface for traversal is needed.
• Subtle differences exist between the implementation details of various iterators.

Example

The Java implementation of the iterator pattern allows users to traverse various types of data sets without worrying about the underlying implementation of the collection. Since clients simply interact with the iterator interface, collections are left to define the appropriate iterator for themselves. Some will allow full access to the underlying data set while others may restrict certain functionalities, such as removing items.

中介者模式

Purpose

Allows loose coupling by encapsulating the way disparate sets of objects interact and communicate with each other. Allows for the actions of each object set to vary independently of one another.

Use When

• Communication between sets of objects is well defined and complex.
• Too many relationships exist and common point of control or communication is needed.

Example

Mailing list software keeps track of who is signed up to the mailing list and provides a single point of access through which any one person can communicate with the entire list. Without a mediator implementation a person wanting to send a message to the group would have to constantly keep track of who was signed up and who was not. By implementing the mediator pattern the system is able to receive messages from any point then determine which recipients to forward the message on to, without the sender of the message having to be concerned with the actual recipient list.

備忘錄模式

Purpose

Allows for capturing and externalizing an object's internal state so that it can be restored later, all without violating encapsulation.

Use When

• The internal state of an object must be saved and restored at a later time.
• Internal state cannot be exposed by interfaces without exposing implementation.
• Encapsulation boundaries must be preserved.

Example

Undo functionality can nicely be implemented using the memento pattern. By serializing and deserializing the state of an object before the change occurs we can preserve a snapshot of it that can later be restored should the user choose to undo the operation.

觀察者模式

Purpose

Lets one or more objects be notified of state changes in other objects within the system.

Use When

• State changes in one or more objects should trigger behavior in other objects
• Broadcasting capabilities are required.
• An understanding exists that objects will be blind to the expense of notification.

Example

This pattern can be found in almost every GUI environment. When buttons, text, and other fields are placed in applications the application typically registers as a listener for those controls. When a user triggers an event, such as clicking a button, the control iterates through its registered observers and sends a notification to each.

狀態模式

Purpose

Ties object circumstances to its behavior, allowing the object to behave in different ways based upon its internal state.

Use When

• The behavior of an object should be influenced by its state.
• Complex conditions tie object behavior to its state.
• Transitions between states need to be explicit.

Example

An email object can have various states, all of which will change how the object handles different functions. If the state is "not sent" then the call to send() is going to send the message while a call to recallMessage() will either throw an error or do nothing. However, if the state is "sent" then the call to send() would either throw an error or do nothing while the call to recallMessage() would attempt to send a recall notification to recipients. To avoid conditional statements in most or all methods there would be multiple state objects that handle the implementation with respect to their particular state. The calls within the Email object would then be delegated down to the appropriate state object for handling.

策略模式

Purpose

Defines a set of encapsulated algorithms that can be swapped to carry out a specific behavior.

Use When

• The only difference between many related classes is their behavior.
• Multiple versions or variations of an algorithm are required.
• Algorithms access or utilize data that calling code shouldn't be exposed to.
• The behavior of a class should be defined at runtime.
• Conditional statements are complex and hard to maintain.

Example

When importing data into a new system different validation algorithms may be run based on the data set. By configuring the import to utilize strategies the conditional logic to determine what validation set to run can be removed and the import can be decoupled from the actual validation code. This will allow us to dynamically call one or more strategies during the import.

模板方法模式

Purpose

Identifies the framework of an algorithm, allowing implementing classes to define the actual behavior.

Use When

• A single abstract implementation of an algorithm is needed.
• Common behavior among subclasses should be localized to a common class.
• Parent classes should be able to uniformly invoke behavior in their subclasses.
• Most or all subclasses need to implement the behavior.

Example

A parent class, InstantMessage, will likely have all the methods required to handle sending a message. However, the actual serialization of the data to send may vary depending on the implementation. A video message and a plain text message will require different algorithms in order to serialize the data correctly. Subclasses of InstantMessage can provide their own implementation of the serialization method, allowing the parent class to work with them without understanding their implementation details.

訪問者模式

Purpose

Allows for one or more operations to be applied to a set of objects at runtime, decoupling the operations from the object structure.

Use When

• An object structure must have many unrelated operations performed upon it.
• The object structure can't change but operations performed on it can.
• Operations must be performed on the concrete classes of an object structure.
• Exposing internal state or operations of the object structure is acceptable.
• Operations should be able to operate on multiple object structures that implement the same interface sets.

Example

Calculating taxes in different regions on sets of invoices would require many different variations of calculation logic. Implementing a visitor allows the logic to be decoupled from the invoices and line items. This allows the hierarchy of items to be visited by calculation code that can then apply the proper rates for the region. Changing regions is as simple as substituting a different visitor.

適配器模式

Purpose

Permits classes with disparate interfaces to work together by creating a common object by which they may communicate and interact.

Use When

• A class to be used doesn't meet interface requirements.
• Complex conditions tie object behavior to its state.
• Transitions between states need to be explicit.

Example

A billing application needs to interface with an HR application in order to exchange employee data, however each has its own interface and implementation for the Employee object. In addition, the SSN is stored in different formats by each system. By creating an adapter we can create a common interface between the two applications that allows them to communicate using their native objects and is able to transform the SSN format in the process.

橋接模式

Purpose

Defines an abstract object structure independently of the implementation object structure in order to limit coupling.

Use When

• Abstractions and implementations should not be bound at compile time.
• Abstractions and implementations should be independently extensible.
• Changes in the implementation of an abstraction should have no impact on clients.
• Implementation details should be hidden from the client.

Example

The Java Virtual Machine (JVM) has its own native set of functions that abstract the use of windowing, system logging, and byte code execution but the actual implementation of these functions is delegated to the operating system the JVM is running on. When an application instructs the JVM to render a window it delegates the rendering call to the concrete implementation of the JVM that knows how to communicate with the operating system in order to render the window.

組合模式

Purpose

Facilitates the creation of object hierarchies where each object can be treated independently or as a set of nested objects through the same interface.

Use When

• Hierarchical representations of objects are needed.
• Objects and compositions of objects should be treated uniformly.

Example

Sometimes the information displayed in a shopping cart is the product of a single item while other times it is an aggregation of multiple items. By implementing items as composites we can treat the aggregates and the items in the same way, allowing us to simply iterate over the tree and invoke functionality on each item. By calling the getCost() method on any given node we would get the cost of that item plus the cost of all child items, allowing items to be uniformly treated whether they were single items or groups of items.

裝飾者模式

Purpose

Allows for the dynamic wrapping of objects in order to modify their existing responsibilities and behaviors.

Use When

• Object responsibilities and behaviors should be dynamically modifiable.
• Concrete implementations should be decoupled from responsibilities and behaviors.
• Subclassing to achieve modification is impractical or impossible.
• Specific functionality should not reside high in the object hierarchy.
• A lot of little objects surrounding a concrete implementation is acceptable.

Example

Many businesses set up their mail systems to take advantage of decorators. When messages are sent from someone in the company to an external address the mail server decorates the original message with copyright and confidentiality information. As long as the message remains internal the information is not attached. This decoration allows the message itself to remain unchanged until a runtime decision is made to wrap the message with additional information.

 門面模式

Purpose

Supplies a single interface to a set of interfaces within a system.

Use When

• A simple interface is needed to provide access to a complex system.
• There are many dependencies between system implementations and clients.
• Systems and subsystems should be layered.

Example

By exposing a set of functionalities through a web service the client code needs to only worry about the simple interface being exposed to them and not the complex relationships that may or may not exist behind the web service layer. A single web service call to update a system with new data may actually involve communication with a number of databases and systems, however this detail is hidden due to the implementation of the façade pattern.

享元模式

Purpose

Facilitates the reuse of many fine grained objects, making the utilization of large numbers of objects more efficient.

Use When

• Many like objects are used and storage cost is high.
• The majority of each object's state can be made extrinsic.
• A few shared objects can replace many unshared ones.
• The identity of each object does not matter.

Example

Systems that allow users to define their own application flows and layouts often have a need to keep track of large numbers of fields, pages, and other items that are almost identical to each other. By making these items into flyweights all instances of each object can share the intrinsic state while keeping the extrinsic state separate. The intrinsic state would store the shared properties, such as how a textbox looks, how much data it can hold, and what events it exposes. The extrinsic state would store the unshared properties, such as where the item belongs, how to react to a user click, and how to handle events.

代理模式

Purpose

Allows for object level access control by acting as a pass through entity or a placeholder object.

Use When

• The object being represented is external to the system.
• Objects need to be created on demand.
• Access control for the original object is required.
• Added functionality is required when an object is accessed.

Example

Ledger applications often provide a way for users to reconcile their bank statements with their ledger data on demand, automating much of the process. The actual operation of communicating with a third party is a relatively expensive operation that should be limited. By using a proxy to represent the communications object we can limit the number of times or the intervals the communication is invoked. In addition, we can wrap the complex instantiation of the communication object inside the proxy class, decoupling calling code from the implementation details.

抽象工廠模式

Purpose

Provide an interface that delegates creation calls to one or more concrete classes in order to deliver specific objects.

Use When

• The creation of objects should be independent of the system utilizing them.
• Systems should be capable of using multiple families of objects.
• Families of objects must be used together.
• Libraries must be published without exposing implementation details.
• Concrete classes should be decoupled from clients.

Example

Email editors will allow for editing in multiple formats including plain text, rich text, andHTML Depending on the format being used, different objects will need to be created. If the message is plain text then there could be a body object that represented just plain text and an attachment object that simply encrypted the attachment into Base64. If the message is HTML then the body object would represent HTML encoded text and the attachment object would allow for inline representation and a standard attachment. By utilizing an abstract factory for creation we can then ensure that the appropriate object sets are created based upon the style of email that is being sent.

建造模式

Purpose

Allows for the dynamic creation of objects based upon easily interchangeable algorithms.

Use When

• Object creation algorithms should be decoupled from the system.
• Multiple representations of creation algorithms are required.
• The addition of new creation functionality without changing the core code is necessary.
• Runtime control over the creation process is required.

Example

A file transfer application could possibly use many different protocols to send files and the actual transfer object that will be created will be directly dependent on the chosen protocol. Using a builder we can determine the right builder to use to instantiate the right object. If the setting is FTP then the FTP builder would be used when creating the object.

工廠方法模式

Purpose

Exposes a method for creating objects, allowing subclasses to control the actual creation process.

Use When

• A class will not know what classes it will be required to create.
• Subclasses may specify what objects should be created.
• Parent classes wish to defer creation to their subclasses.

Example

Many applications have some form of user and group structure for security. When the application needs to create a user it will typically delegate the creation of the user to multiple user implementations. The parent user object will handle most operations for each user but the subclasses will define the factory method that handles the distinctions in the creation of each type of user. A system may have AdminUser and StandardUser objects each of which extend the User object. The AdminUser object may perform some extra tasks to ensure access while the StandardUser may do the same to limit access.

原型模式

Purpose

Create objects based upon a template of an existing objects through cloning.

Use When

• Composition, creation, and representation of objects should be decoupled from a system.
• Classes to be created are specified at runtime.
• A limited number of state combinations exist in an object.
• Objects or object structures are required that are identical or closely resemble other existing objects or object structures.
• The initial creation of each object is an expensive operation.

Example

Rates processing engines often require the lookup of many different configuration values, making the initialization of the engine a relatively expensive process. When multiple instances of the engine is needed, say for importing data in a multi-threaded manner, the expense of initializing many engines is high. By utilizing the prototype pattern we can ensure that only a single copy of the engine has to be initialized then simply clone the engine to create a duplicate of the already initialized object. The added benefit of this is that the clones can be streamlined to only include relevant data for their situation.

單例模式

Purpose

Ensures that only one instance of a class is allowed within a system.

Use When

• Exactly one instance of a class is required.
• Controlled access to a single object is necessary.

Example

Most languages provide some sort of system or environment object that allows the language to interact with the native operating system. Since the application is physically running on only one operating system there is only ever a need for a single instance of this system object. The singleton pattern would be implemented by the language runtime to ensure that only a single copy of the system object is created and to ensure only appropriate processes are allowed access to it.

2.大話版

建立型模式

一、FACTORY—追MM少不了請吃飯了，麥當勞的雞翅和肯德基的雞翅都是MM愛吃的東西，雖然口味有所不一樣，但無論你帶MM去麥當勞或肯德基，只管向服務員說「來四個雞翅」就好了。麥當勞和肯德基就是生產雞翅的Factory

工廠模式：客戶類和工廠類分開。消費者任什麼時候候須要某種產品，只需向工廠請求便可。消費者無須修改就能夠接納新產品。缺點是當產品修改時，工廠類也要作相應的修改。如：如何建立及如何向客戶端提供。

二、BUILDER—MM最愛聽的就是「我愛你」這句話了，見到不一樣地方的MM,要可以用她們的方言跟她說這句話哦，我有一個多種語言翻譯機，上面每種語言都有一個按鍵，見到MM我只要按對應的鍵，它就可以用相應的語言說出「我愛你」這句話了，國外的MM也能夠輕鬆搞掂，這就是個人「我愛你」builder。（這必定比美軍在伊拉克用的翻譯機好賣）

建造模式：將產品的內部表象和產品的生成過程分割開來，從而使一個建造過程生成具備不一樣的內部表象的產品對象。建造模式使得產品內部表象能夠獨立的變化，客戶沒必要知道產品內部組成的細節。建造模式能夠強制實行一種分步驟進行的建造過程。

三、FACTORY METHOD—請MM去麥當勞吃漢堡，不一樣的MM有不一樣的口味，要每一個都記住是一件煩人的事情，我通常採用Factory Method模式，帶着MM到服務員那兒，說「要一個漢堡」，具體要什麼樣的漢堡呢，讓MM直接跟服務員說就好了。

工廠方法模式：核心工廠類再也不負責全部產品的建立，而是將具體建立的工做交給子類去作，成爲一個抽象工廠角色，僅負責給出具體工廠類必須實現的接口，而不接觸哪個產品類應當被實例化這種細節。

四、PROTOTYPE—跟MM用QQ聊天，必定要說些深情的話語了，我搜集了好多肉麻的情話，須要時只要copy出來放到QQ裏面就好了，這就是個人情話prototype了。（100塊錢一份，你要不要）

原型模式：經過給出一個原型對象來指明所要建立的對象的類型，而後用複製這個原型對象的方法建立出更多同類型的對象。原始模型模式容許動態的增長或減小產品類，產品類不須要非得有任何事先肯定的等級結構，原始模型模式適用於任何的等級結構。缺點是每個類都必須配備一個克隆方法。

五、SINGLETON—俺有6個漂亮的老婆，她們的老公都是我，我就是咱們家裏的老公Sigleton，她們只要說道「老公」，都是指的同一我的，那就是我(剛纔作了個夢啦，哪有這麼好的事)

單例模式：單例模式確保某一個類只有一個實例，並且自行實例化並向整個系統提供這個實例單例模式。單例模式只應在有真正的「單一實例」的需求時纔可以使用。

結構型模式

六、ADAPTER—在朋友聚會上碰到了一個美女Sarah，從香港來的，可我不會說粵語，她不會說普通話，只好求助於個人朋友kent了，他做爲我和Sarah之間的Adapter，讓我和Sarah能夠相互交談了(也不知道他會不會耍我)

適配器模式：把一個類的接口變換成客戶端所期待的另外一種接口，從而使本來因接口緣由不匹配而沒法一塊兒工做的兩個類可以一塊兒工做。適配類能夠根據參數返還一個合適的實例給客戶端。

七、BRIDGE—早上碰到MM，要說早上好，晚上碰到MM，要說晚上好；碰到MM穿了件新衣服，要說你的衣服好漂亮哦，碰到MM新作的髮型，要說你的頭髮好漂亮哦。不要問我「早上碰到MM新作了個髮型怎麼說」這種問題，本身用BRIDGE組合一下不就好了

橋樑模式：將抽象化與實現化脫耦，使得兩者能夠獨立的變化，也就是說將他們之間的強關聯變成弱關聯，也就是指在一個軟件系統的抽象化和實現化之間使用組合/聚合關係而不是繼承關係，從而使二者能夠獨立的變化。

八、COMPOSITE—Mary今天過生日。「我過生日，你要送我一件禮物。」「嗯，好吧，去商店，你本身挑。」「這件T恤挺漂亮，買，這條裙子好看，買，這個包也不錯，買。」「喂，買了三件了呀，我只答應送一件禮物的哦。」「什麼呀，T恤加裙子加包包，正好配成一套呀，小姐，麻煩你包起來。」「……」，MM都會用Composite模式了，你會了沒有？

合成模式：合成模式將對象組織到樹結構中，能夠用來描述總體與部分的關係。合成模式就是一個處理對象的樹結構的模式。合成模式把部分與總體的關係用樹結構表示出來。合成模式使得客戶端把一個個單獨的成分對象和由他們複合而成的合成對象同等看待。

九、DECORATOR—Mary過完輪到Sarly過生日，仍是不要叫她本身挑了，否則這個月伙食費確定玩完，拿出我去年在華山頂上照的照片，在背面寫上「最好的的禮物，就是愛你的Fita」，再到街上禮品店買了個像框（賣禮品的MM也很漂亮哦），再找隔壁搞美術設計的Mike設計了一個漂亮的盒子裝起來……，咱們都是Decorator，最終都在修飾我這我的呀，怎麼樣，看懂了嗎？

裝飾模式：裝飾模式以對客戶端透明的方式擴展對象的功能，是繼承關係的一個替代方案，提供比繼承更多的靈活性。動態給一個對象增長功能，這些功能能夠再動態的撤消。增長由一些基本功能的排列組合而產生的很是大量的功能。

十、FACADE—我有一個專業的Nikon相機，我就喜歡本身手動調光圈、快門，這樣照出來的照片才專業，但MM可不懂這些，教了半天也不會。幸虧相機有Facade設計模式，把相機調整到自動檔，只要對準目標按快門就好了，一切由相機自動調整，這樣MM也能夠用這個相機給我拍張照片了。

門面模式：外部與一個子系統的通訊必須經過一個統一的門面對象進行。門面模式提供一個高層次的接口，使得子系統更易於使用。每個子系統只有一個門面類，並且此門面類只有一個實例，也就是說它是一個單例模式。但整個系統能夠有多個門面類。

十一、FLYWEIGHT—天天跟MM發短信，手指都累死了，最近買了個新手機，能夠把一些經常使用的句子存在手機裏，要用的時候，直接拿出來，在前面加上MM的名字就能夠發送了，再不用一個字一個字敲了。共享的句子就是Flyweight，MM的名字就是提取出來的外部特徵，根據上下文狀況使用。

享元模式：FLYWEIGHT在拳擊比賽中指最輕量級。享元模式以共享的方式高效的支持大量的細粒度對象。享元模式能作到共享的關鍵是區份內蘊狀態和外蘊狀態。內蘊狀態存儲在享元內部，不會隨環境的改變而有所不一樣。外蘊狀態是隨環境的改變而改變的。外蘊狀態不能影響內蘊狀態，它們是相互獨立的。將能夠共享的狀態和不能夠共享的狀態從常規類中區分開來，將不能夠共享的狀態從類裏剔除出去。客戶端不能夠直接建立被共享的對象，而應當使用一個工廠對象負責建立被共享的對象。享元模式大幅度的下降內存中對象的數量。

十二、PROXY—跟MM在網上聊天，一開頭老是「hi,你好」,「你從哪兒來呀？」「你多大了？」「身高多少呀？」這些話，真煩人，寫個程序作爲個人Proxy吧，凡是接收到這些話都設置好了自動的回答，接收到其餘的話時再通知我回答，怎麼樣，酷吧。

代理模式：代理模式給某一個對象提供一個代理對象，並由代理對象控制對源對象的引用。代理就是一我的或一個機構表明另外一我的或者一個機構採起行動。某些狀況下，客戶不想或者不可以直接引用一個對象，代理對象能夠在客戶和目標對象直接起到中介的做用。客戶端分辨不出代理主題對象與真實主題對象。代理模式能夠並不知道真正的被代理對象，而僅僅持有一個被代理對象的接口，這時候代理對象不可以建立被代理對象，被代理對象必須有系統的其餘角色代爲建立並傳入。

行爲模式

1三、CHAIN OF RESPONSIBLEITY—晚上去上英語課，爲了好開溜坐到了最後一排，哇，前面坐了好幾個漂亮的MM哎，找張紙條，寫上「Hi,能夠作個人女友嗎？若是不肯意請向前傳」，紙條就一個接一個的傳上去了，糟糕，傳到第一排的MM把紙條傳給老師了，據說是個老處女呀，快跑!

責任鏈模式：在責任鏈模式中，不少對象由每個對象對其下家的引用而接起來造成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。客戶並不知道鏈上的哪個對象最終處理這個請求，系統能夠在不影響客戶端的狀況下動態的從新組織鏈和分配責任。處理者有兩個選擇：承擔責任或者把責任推給下家。一個請求能夠最終不被任何接收端對象所接受。

1四、COMMAND—俺有一個MM家裏管得特別嚴，無法見面，只好藉助於她弟弟在咱們倆之間傳送信息，她對我有什麼指示，就寫一張紙條讓她弟弟帶給我。這不，她弟弟又傳送過來一個COMMAND，爲了感謝他，我請他吃了碗雜醬麪，哪知道他說：「我同時給我姐姐三個男友送COMMAND，就數你最小氣，才請我吃麪。」，:-(

命令模式：命令模式把一個請求或者操做封裝到一個對象中。命令模式把發出命令的責任和執行命令的責任分割開，委派給不一樣的對象。命令模式容許請求的一方和發送的一方獨立開來，使得請求的一方沒必要知道接收請求的一方的接口，更沒必要知道請求是怎麼被接收，以及操做是否執行，什麼時候被執行以及是怎麼被執行的。系統支持命令的撤消。

1五、INTERPRETER—俺有一個《泡MM真經》，上面有各類泡MM的攻略，好比說去吃西餐的步驟、去看電影的方法等等，跟MM約會時，只要作一個Interpreter，照着上面的腳本執行就能夠了。

解釋器模式：給定一個語言後，解釋器模式能夠定義出其文法的一種表示，並同時提供一個解釋器。客戶端可使用這個解釋器來解釋這個語言中的句子。解釋器模式將描述怎樣在有了一個簡單的文法後，使用模式設計解釋這些語句。在解釋器模式裏面提到的語言是指任何解釋器對象可以解釋的任何組合。在解釋器模式中須要定義一個表明文法的命令類的等級結構，也就是一系列的組合規則。每個命令對象都有一個解釋方法，表明對命令對象的解釋。命令對象的等級結構中的對象的任何排列組合都是一個語言。

1六、ITERATOR—我愛上了Mary，不顧一切的向她求婚。

Mary：「想要我跟你結婚，得答應個人條件」

我：「什麼條件我都答應，你說吧」

Mary：「我看上了那個一克拉的鑽石」

我：「我買，我買，還有嗎？」

Mary：「我看上了湖邊的那棟別墅」

我：「我買，我買，還有嗎？」

Mary：「你的小弟弟必需要有50cm長」

我腦殼嗡的一聲，坐在椅子上，一咬牙：「我剪，我剪，還有嗎？」

……

迭代子模式：迭代子模式能夠順序訪問一個彙集中的元素而沒必要暴露彙集的內部表象。多個對象聚在一塊兒造成的整體稱之爲彙集，彙集對象是可以包容一組對象的容器對象。迭代子模式將迭代邏輯封裝到一個獨立的子對象中，從而與彙集自己隔開。迭代子模式簡化了彙集的界面。每個彙集對象均可以有一個或一個以上的迭代子對象，每個迭代子的迭代狀態能夠是彼此獨立的。迭代算法能夠獨立於彙集角色變化。

1七、MEDIATOR—四個MM打麻將，相互之間誰應該給誰多少錢算不清楚了，幸好當時我在旁邊，按照各自的籌碼數算錢，賺了錢的從我這裏拿，賠了錢的也付給我，一切就OK啦，俺獲得了四個MM的電話。

調停者模式：調停者模式包裝了一系列對象相互做用的方式，使得這些對象沒必要相互明顯做用。從而使他們能夠鬆散偶合。當某些對象之間的做用發生改變時，不會當即影響其餘的一些對象之間的做用。保證這些做用能夠彼此獨立的變化。調停者模式將多對多的相互做用轉化爲一對多的相互做用。調停者模式將對象的行爲和協做抽象化，把對象在小尺度的行爲上與其餘對象的相互做用分開處理。

1八、MEMENTO—同時跟幾個MM聊天時，必定要記清楚剛纔跟MM說了些什麼話，否則MM發現了會不高興的哦，幸好我有個備忘錄，剛纔與哪一個MM說了什麼話我都拷貝一份放到備忘錄裏面保存，這樣能夠隨時察看之前的記錄啦。

備忘錄模式：備忘錄對象是一個用來存儲另一個對象內部狀態的快照的對象。備忘錄模式的用意是在不破壞封裝的條件下，將一個對象的狀態捉住，並外部化，存儲起來，從而能夠在未來合適的時候把這個對象還原到存儲起來的狀態。

1九、OBSERVER—想知道我們公司最新MM情報嗎？加入公司的MM情報郵件組就好了，tom負責蒐集情報，他發現的新情報不用一個一個通知咱們，直接發佈給郵件組，咱們做爲訂閱者（觀察者）就能夠及時收到情報啦

觀察者模式：觀察者模式定義了一種一隊多的依賴關係，讓多個觀察者對象同時監聽某一個主題對象。這個主題對象在狀態上發生變化時，會通知全部觀察者對象，使他們可以自動更新本身。

20、STATE—跟MM交往時，必定要注意她的狀態哦，在不一樣的狀態時她的行爲會有不一樣，好比你約她今天晚上去看電影，對你沒興趣的MM就會說「有事情啦」，對你不討厭但還沒喜歡上的MM就會說「好啊，不過能夠帶上我同事麼？」，已經喜歡上你的MM就會說「幾點鐘？看完電影再去泡吧怎麼樣？」，固然你看電影過程當中表現良好的話，也能夠把MM的狀態從不討厭不喜歡變成喜歡哦。

狀態模式：狀態模式容許一個對象在其內部狀態改變的時候改變行爲。這個對象看上去象是改變了它的類同樣。狀態模式把所研究的對象的行爲包裝在不一樣的狀態對象裏，每個狀態對象都屬於一個抽象狀態類的一個子類。狀態模式的意圖是讓一個對象在其內部狀態改變的時候，其行爲也隨之改變。狀態模式須要對每個系統可能取得的狀態創立一個狀態類的子類。當系統的狀態變化時，系統便改變所選的子類。

2一、STRATEGY—跟不一樣類型的MM約會，要用不一樣的策略，有的請電影比較好，有的則去吃小吃效果不錯，有的去海邊浪漫最合適，單目的都是爲了獲得MM的芳心，個人追MM錦囊中有好多Strategy哦。

策略模式：策略模式針對一組算法，將每個算法封裝到具備共同接口的獨立的類中，從而使得它們能夠相互替換。策略模式使得算法能夠在不影響到客戶端的狀況下發生變化。策略模式把行爲和環境分開。環境類負責維持和查詢行爲類，各類算法在具體的策略類中提供。因爲算法和環境獨立開來，算法的增減，修改都不會影響到環境和客戶端。

2二、TEMPLATE METHOD——看過《如何說服女生上牀》這部經典文章嗎？女生從認識到上牀的不變的步驟分爲巧遇、打破僵局、展開追求、接吻、前戲、動手、愛撫、進去八大步驟(Template method)，但每一個步驟針對不一樣的狀況，都有不同的作法，這就要看你隨機應變啦(具體實現)；

模板方法模式：模板方法模式準備一個抽象類，將部分邏輯以具體方法以及具體構造子的形式實現，而後聲明一些抽象方法來迫使子類實現剩餘的邏輯。不一樣的子類能夠以不一樣的方式實現這些抽象方法，從而對剩餘的邏輯有不一樣的實現。先制定一個頂級邏輯框架，而將邏輯的細節留給具體的子類去實現。

2三、VISITOR—情人節到了，要給每一個MM送一束鮮花和一張卡片，但是每一個MM送的花都要針對她我的的特色，每張卡片也要根據我的的特色來挑，我一我的哪搞得清楚，仍是找花店老闆和禮品店老闆作一下Visitor，讓花店老闆根據MM的特色選一束花，讓禮品店老闆也根據每一個人特色選一張卡，這樣就輕鬆多了；

訪問者模式：訪問者模式的目的是封裝一些施加於某種數據結構元素之上的操做。一旦這些操做須要修改的話，接受這個操做的數據結構能夠保持不變。訪問者模式適用於數據結構相對未定的系統，它把數據結構和做用於結構上的操做之間的耦合解脫開，使得操做集合能夠相對自由的演化。訪問者模式使得增長新的操做變的很容易，就是增長一個新的訪問者類。訪問者模式將有關的行爲集中到一個訪問者對象中，而不是分散到一個個的節點類中。當使用訪問者模式時，要將盡量多的對象瀏覽邏輯放在訪問者類中，而不是放到它的子類中。訪問者模式能夠跨過幾個類的等級結構訪問屬於不一樣的等級結構的成員類。

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~