设计模式

最新推荐文章于 2024-10-12 23:21:51 发布

Sunny04

最新推荐文章于 2024-10-12 23:21:51 发布

阅读量928

点赞数

分类专栏：设计模式文章标签：设计模式

本文链接：https://blog.csdn.net/sunny04/article/details/45505933

版权

设计模式专栏收录该内容

5 篇文章 0 订阅

订阅专栏

最近看《head first设计模式》，收获很多。本打算写个读书笔记的，发现网上有人写的很不错，地址如下：

http://www.cnblogs.com/chenssy/p/3357683.html

设计模式目录： http://www.cnblogs.com/chenssy/category/482229.html

以下是我个人的学习心得，加深下理解（很多都是参考上面的网站内容）：

1. 设计模式

设计模式是基于以下6种设计原则，演化过来的，分别是：

1. 单一职责原则：一个类，只有一个引起它变化的原因。

2. 开闭原则：对扩展开放，对修改关闭。想要达到这样的效果，我们需要使用接口和抽象类。

3. 里氏替代原则：任何基类可以出现的地方，子类一定可以出现。

4. 依赖倒置原则：要依赖于抽象，不要依赖于具体。对抽象进行编程，不要对实现进行编程。面向过程的开发，上层调用下层，上层依赖于下层，当下层剧烈变动时上层也要跟着变动，这就会导致模块的复用性降低而且大大提高了开发的成本。如果在下层抽象出接口，让上层针对抽象出来的接口编程，这就是依赖倒置原则。

5. 接口隔离原则：使用多个专门的接口比使用单一的总接口要好。再通俗一点讲：接口尽量细化，同时接口中的方法尽量少。

举例说明：

使用场合,提供调用者需要的方法,屏蔽不需要的方法.满足接口隔离原则.比如说电子商务的系统,有订单这个类,有三个地方会使用到,

一个是门户,只能有查询方法,

一个是外部系统,有添加订单的方法,

一个是管理后台,添加删除修改查询都要用到.

根据接口隔离原则(ISP),一个类对另外一个类的依赖性应当是建立在最小的接口上.

也就是说,对于门户,它只能依赖有一个查询方法的接口.

UML结构如下:

下面是实现的代码.

//--这儿不用接口继承,因为可能出现修改了父接口影响了子接口

 
        interface  
        IOrderForPortal{ 
       
        String getOrder(); 
       
        } 
       
        interface  
        IOrderForOtherSys{ 
       
        String insertOrder(); 
       
        String getOrder(); 
       
        } 
       
        interface  
        IOrderForAdmin{  
        //extendsIOrderForPortal,IOrderForOtherSys 
       
        String deleteOrder(); 
       
        String updateOrder(); 
       
        String insertOrder(); 
       
        String getOrder(); 
       
        } 
       
        /* 
       
        interface IOrderForPortal{ 
       
        String getOrder(); 
       
        } 
       
        interface IOrderForOtherSys{ 
       
        String insertOrder(); 
       
        } 
       
        interface IOrderForAdmin extendsIOrderForPortal,IOrderForOtherSys{ 
       
        String updateOrder(); 
       
        String deleteOrder(); 
       
        } 
       
        */ 
       
        class  
        Order  
        implements  
        IOrderForPortal,IOrderForOtherSys,IOrderForAdmin{ 
       
        private  
        Order(){ 
       
        //--什么都不干,就是为了不让直接 new,防止客户端直接New,然后访问它不需要的方法. 
       
        } 
       
        //返回给Portal 
       
        public  
        static  
        IOrderForPortal getOrderForPortal(){ 
       
        return  
        (IOrderForPortal) 
        new  
        Order(); 
       
        } 
       
        //返回给OtherSys 
       
        public  
        static  
        IOrderForOtherSys getOrderForOtherSys(){ 
       
        return  
        (IOrderForOtherSys)newOrder(); 
       
        } 
       
        //返回给Admin 
       
        public  
        static  
        IOrderForAdmin getOrderForAdmin(){ 
       
        return  
        (IOrderForAdmin) 
        new  
        Order(); 
       
        } 
       
        //--下面是接口方法的实现.只是返回了一个String用于演示 
       
        public  
        String getOrder(){ 
       
        return  
        "implemented getOrder" 
        ; 
       
        } 
       
        public  
        String insertOrder(){ 
       
        return  
        "implementedinsertOrder" 
        ; 
       
        } 
       
        public  
        String updateOrder(){ 
       
        return  
        "implementedupdateOrder" 
        ; 
       
        } 
       
        public  
        String deleteOrder(){ 
       
        return  
        "implementeddeleteOrder" 
        ; 
       
        } 
       
        } 
       
        public  
        class  
        TestCreateLimit{ 
       
        public  
        static  
        void  
        main(String[] <a target= 
        "_blank" 
        href= 
        "/subview/1333371/1333371.htm" 
        >args</a>){ 
       
        IOrderForPortal orderForPortal =Order.getOrderForPortal(); 
       
        IOrderForOtherSys orderForOtherSys =Order.getOrderForOtherSys(); 
       
        IOrderForAdmin orderForAdmin = Order.getOrderForAdmin(); 
       
        System.out.println( 
        "<a target=" 
        _blank 
        " href=" 
        /subview/ 
        209420 
        / 
        209420 
        .htm 
        ">Portal</a>门户调用方法:" 
        +orderForPortal.getOrder()); 
       
        System.out.println( 
        "OtherSys外部<a target=" 
        _blank 
        " href=" 
        /subview/ 
        47173 
        / 
        47173 
        .htm 
        ">系统调用</a>方法:" 
        +orderForOtherSys.insertOrder()); 
       
        System.out.println( 
        "Admin管理后台调用方法:" 
        +orderForAdmin.getOrder()+ 
        ";" 
        +orderForAdmin.insertOrder()+ 
        ";" 
        +orderForAdmin.updateOrder()+ 
        ";" 
        +orderForAdmin.deleteOrder()); 
       
        } 
       
        }

http://baike.baidu.com/link?url=v9nWyF7d_XmIzjf8K7L1Tg9O4mnloquPQjD0Gf6zGHWsVbKA3nxXFe-L5o9_ZEYRQIZKs8mMc3qdxu8pLKRiy_

6. 迪米特原则（最小知道原则）：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。

2. 创建型模式

a. 抽象工厂：创建一组相关或者依赖的对象集。允许客户端使用抽象的接口来创建一组相关的产品，而不需要关心具体产品是什么。这样一来，客户就可以从具体的产品中被解耦。它的优点是隔离了具体类的生成，使得客户端不需要知道什么被创建了，而缺点就在于新增新的行为会比较麻烦，因为当添加一个新的产品对象时，需要更加需要更改接口及其下所有子类。其UML结构图如下：

参与者：

AbstractFactory：抽象工厂。抽象工厂定义了一个接口，所有的具体工厂都必须实现此接口，这个接口包含了一组方法用来生产产品。

ConcreteFactory：具体工厂。具体工厂是用于生产不同产品族。要创建一个产品，客户只需要使用其中一个工厂完全不需要实例化任何产品对象。

AbstractProduct：抽象产品。这是一个产品家族，每一个具体工厂都能够生产一整组产品。

Product：具体产品。

b. 工厂模式：工厂方法模式定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个，也就是说工厂方法模式让实例化推迟到子类。

c. 建造者模式：将复杂产品的构建过程封装分解在不同的方法中，使得创建过程非常清晰。

UML结构图：

参与者：

         Builder：抽象建造者。它声明为创建一个Product对象的各个部件指定的抽象接口。
         ConcreteBuilder：具体建造者。实现抽象接口，构建和装配各个部件。
         Director：指挥者。构建一个使用Builder接口的对象。它主要是用于创建一个复杂的对象，它主要有两个作用，一是：隔离了客户与对象的生产过程，二是：负责控制产品对象的生产过程。
         Product：产品角色。一个具体的产品对象

d. 原型模式：在我们应用程序可能有某些对象的结构比较复杂，但是我们又需要频繁的使用它们，如果这个时候我们来不断的新建这个对象势必会大大损耗系统内存的，这个时候我们需要使用原型模式来对这个结构复杂又要频繁使用的对象进行克隆。在C++里，可以理解为类的拷贝构造函数就是下面的clone() 。

UML结构图：

参与者：

          Prototype：抽象原型类。声明克隆自身的接口。
          ConcretePrototype：具体原型类。实现克隆的具体操作。
          Client：客户类。让一个原型克隆自身，从而获得一个新的对象。

e. 单例模式：确保某一个类只有一个实例，并且提供一个全局访问点。

3. 构造型模式

结构型模式主要是用于处理类或者对象的组合，它描述了如何来类或者对象更好的组合起来，是从程序的结构上来解决模块之间的耦合问题。它主要包括适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式、代理模式这个七个模式。

a. 所谓适配器模式就是将一个类的接口，转换成客户期望的另一个接口。它可以让原本两个不兼容的接口能够无缝完成对接。

UML:

参与者：

Target：目标抽象类。

Adapter：适配器类。通过在内部包装一个Adaptee，将源接口转成目标接口。

Adaptee：适配者类。需要适配的类。

Client：客户类。

b. 桥接模式：

如果说某个系统能够从多个角度来进行分类，且每一种分类都可能会变化，那么我们需要做的就是讲这多个角度分离出来，使得他们能独立变化，减少他们之间的耦合，这个分离过程就使用了桥接模式。所谓桥接模式就是讲抽象部分和实现部分隔离开来，使得他们能够独立变化。

桥接模式将继承关系转化成关联关系，封装了变化，完成了解耦，减少了系统中类的数量，也减少了代码量。

4444

UML结构图：

桥接模式主要包含如下几个角色：

      Abstraction：抽象类。
      RefinedAbstraction：扩充抽象类。
      Implementor：实现类接口。
      ConcreteImplementor：具体实现类。

http://www.cnblogs.com/chenssy/p/3317866.html

c. 组合模式：组合模式组合多个对象形成树形结构以表示“整体-部分”的结构层次。它定义了如何将容器对象和叶子对象进行递归组合，使得客户在使用的过程中无须进行区分，可以对他们进行一致的处理。

参与者：

         Component ：组合中的对象声明接口，在适当的情况下，实现所有类共有接口的默认行为。声明一个接口用于访问和管理Component子部件。
         Leaf：叶子对象。叶子结点没有子结点。
         Composite：容器对象，定义有枝节点行为，用来存储子部件，在Component接口中实现与子部件有关操作，如增加(add)和删除(remove)等。

d.装饰者模式：装饰者模式，动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更加有弹性的替代方案。

参与者：

Component: 抽象构件。是定义一个对象接口，可以给这些对象动态地添加职责。

ConcreteComponent:具体构件。是定义了一个具体的对象，也可以给这个对象添加一些职责。

Decorator: 抽象装饰类。是装饰抽象类，继承了Component,从外类来扩展Component类的功能，但对于Component来说，是无需知道Decorator存在的。

ConcreteDecorator:具体装饰类，起到给Component添加职责的功能。

e. 外观模式：外观模式提供了一个统一的接口，用来访问子系统中的一群接口。

参与者：

Facade: 外观角色。知道哪些子系统类负责处理请求，将客户的请求代理给适合的子系统处理。

SubSystem:子系统角色。实现子系统功能，处理Facade对象发来的请求。

f. 享元模式：在一个系统中对象会使得内存占用过多，特别是那些大量重复的对象，这就是对系统资源的极大浪费。享元模式对对象的重用提供了一种解决方案，它使用共享技术对相同或者相似对象实现重用。

享元模式就是运行共享技术有效地支持大量细粒度对象的复用。系统使用少量对象,而且这些都比较相似，状态变化小，可以实现对象的多次复用。这里有一点要注意：享元模式要求能够共享的对象必须是细粒度对象。

享元模式通过共享技术使得系统中的对象个数大大减少了，同时享元模式使用了内部状态和外部状态，同时外部状态相对独立，不会影响到内部状态，所以享元模式能够使得享元对象在不同的环境下被共享。同时正是分为了内部状态和外部状态，享元模式会使得系统变得更加复杂，同时也会导致读取外部状态所消耗的时间过长。

参与者：

         Flyweight: 抽象享元类。所有具体享元类的超类或者接口，通过这个接口，Flyweight可以接受并作用于外部专题。
         ConcreteFlyweight: 具体享元类。指定内部状态，为内部状态增加存储空间。
         UnsharedConcreteFlyweight: 非共享具体享元类。指出那些不需要共享的Flyweight子类。
         FlyweightFactory: 享元工厂类。用来创建并管理Flyweight对象，它主要用来确保合理地共享Flyweight，当用户请求一个Flyweight时，FlyweightFactory就会提供一个已经创建的Flyweight对象或者新建一个（如果不存在）。

g. 代理模式：

代理模式就是给一个对象提供一个代理，并由代理对象控制对原对象的引用。它使得客户不能直接与真正的目标对象通信。代理对象是目标对象的代表，其他需要与这个目标对象打交道的操作都是和这个代理对象在交涉。

代理对象可以在客户端和目标对象之间起到中介的作用，这样起到了的作用和保护了目标对象的，同时也在一定程度上面减少了系统的耦合度。

参与者：

Subject: 抽象角色。声明真实对象和代理对象的共同接口。

Proxy: 代理角色。代理对象与真实对象实现相同的接口，所以它能够在任何时刻都能够代理真实对象。代理角色内部包含有对真实对象的引用，所以她可以操作真实对象，同时也可以附加其他的操作，相当于对真实对象进行封装。

RealSubject: 真实角色。它代表着真实对象，是我们最终要引用的对象。

3. 行为型模式

行为型模式主要是用于描述类或者对象是怎样交互和怎样分配职责的。它涉及到算法和对象间的职责分配，不仅描述对象或者类的模式，还描述了他们之间的通信方式，它将你的注意力从控制流转移到了对象间的关系上来。行为型类模式采用继承机制在类间分派行为，而行为型对象模式使用对象复合而不是继承。它主要包括如何11中设计模式：职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式。

a. 责任链模式：将对象组成一条链，发送者将请求发给链的第一个接收者，并且沿着这条链传递，直到有一个对象来处理它或者直到最后也没有对象处理而留在链末尾端

b. 命令模式：

有些时候我们想某个对象发送一个请求，但是我们并不知道该请求的具体接收者是谁，具体的处理过程是如何的，们只知道在程序运行中指定具体的请求接收者即可，对于这样将请求封装成对象的我们称之为命令模式。所以命令模式将请求封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。同时命令模式支持可撤销的操作。

命令模式可以将请求的发送者和接收者之间实现完全的解耦，发送者和接收者之间没有直接的联系，发送者只需要知道如何发送请求命令即可，其余的可以一概不管，甚至命令是否成功都无需关心。同时我们可以非常方便的增加新的命令，但是可能就是因为方便和对请求的封装就会导致系统中会存在过多的具体命令类。

参与者：

Command: 抽象命令类。用来声明执行操作的接口。

ConcreteCommand: 具体命令类。将一个接收者对象绑定于一个动作，调用接收者相应的操作，以实现Excute。

Invoker: 调用者。要求该命令执行这个请求。

Receiver: 接收者。知道如何实施与执行一个请求相关的操作，任何类都有可能成为一个接收者。

Client:客户类。

c. 解释器模式：所谓解释器模式就是定义语言的文法，并且建立一个解释器来解释该语言中的句子。解释器模式描述了如何构成一个简单的语言解释器，主要应用在使用面向对象语言开发的编译器中。应用场景比较少。

参与者：

AbstractExpression: 抽象表达式。声明一个抽象的解释操作，该接口为抽象语法树中所有的节点共享。

TerminalExpression: 终结符表达式。实现与文法中的终结符相关的解释操作。实现抽象表达式中所要求的方法。文法中每一个终结符都有一个具体的终结表达式与之相对应。

NonterminalExpression: 非终结符表达式。为文法中的非终结符相关的解释操作。

Context: 环境类。包含解释器之外的一些全局信息。

Client: 客户类。

d. 迭代器模式：所谓迭代器模式就是提供一种方法顺序访问一个聚合对象中的各个元素，而不是暴露其内部的表示。

参与者：

Iterator: 抽象迭代器：所有迭代器都需要实现的接口，提供了游走聚合对象元素之间的方法。

ConcreteIterator: 具体迭代器。利用这个具体的迭代器能够对具体的聚合对象进行遍历。每一个聚合对象都应该对应一个具体的迭代器。

Aggregate: 抽象聚合类。

ConcreteAggregate: 具体聚合类。实现creatorIterator()方法，返回该聚合对象的迭代器

e. 中介者模式：所谓中介者模式就是用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

1111

参与者：

Mediator: 抽象中介者。定义了同事对象到中介者对象之间的接口。

ConcreteMediator: 具体中介者。实现抽象中介者的方法，它需要知道所有的具体同事类，同时需要从具体的同事类那里接收信息，并且向具体的同事类发送信息。

Colleague: 抽象同事类。

ConcreteColleague: 具体同事类。每个具体同事类都只需要知道自己的行为即可，但是他们都需要认识中介者。

f. 备忘录模式就是在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。

参与者：

Originator: 原发器。负责创建一个备忘录，用以记录当前对象的内部状态，通过也可以使用它来利用备忘录恢复内部状态。同时原发器还可以根据需要决定Memento存储Originator的那些内部状态。

Memento: 备忘录。用于存储Originator的内部状态，并且可以防止Originator以外的对象访问Memento。在备忘录Memento中有两个接口，其中Caretaker只能看到备忘录中的窄接口，它只能将备忘录传递给其他对象。Originator可以看到宽接口，允许它访问返回到先前状态的所有数据。

Caretaker: 负责人。负责保存好备忘录，不能对备忘录的内容进行操作和访问，只能够将备忘录传递给其他对象。

g. 观察者模式：观察者模式定义了对象之间的一对多依赖关系，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并且自动更新。

参与者：

Subject：目标。他把所有对观察者对戏的引用保存在一个聚集里，每一个主题都可以有多个观察者。

Observer：观察者。为所有的具体观察者定义一个接口，在得到主题的通知时能够及时的更新自己。

ConcreteSubject：具体主题。将有关状态存入具体观察者对象。在具体主题发生改变时，给所有的观察者发出通知。

ConcreteObserver：具体观察者。实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题状态相协调。

h. 状态机模式：所以状态模式就是允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。

参与者：

         Context：环境类。可以包括一些内部状态。
         State：抽象状态类。State定义了一个所有具体状态的共同接口，任何状态都实现这个相同的接口，这样一来，状态之间就可以互相转换了。
         ConcreteState：具体状态类。具体状态类，用于处理来自Context的请求，每一个ConcreteState都提供了它对自己请求的实现，所以，当Context改变状态时行为也会跟着改变。

i. 策略模式：所以策略模式就是定义了算法族，分别封装起来，让他们之前可以互相转换，此模式然该算法的变化独立于使用算法的客户。

参与者：

         Context: 环境类。维护一个Strategy对象的引用，用一个ConcreteStrategy来配置，可定义一个接口来让Strategy访问它的数据。
         Strategy: 抽象策略类。定义所有支持算法的公共接口。Context使用这个接口来调用某个Concretestrategy定义的算法。
         ConcreteStrategy: 具体策略类。封装了具体的算法实现。

j. 模板方法模式：它本质上就是基于继承的代码复用技术。在模板方法模式中，我们可以将相同部分的代码放在父类中，而将不同的代码放入不同的子类中。也就是说我们需要声明一个抽象的父类，将部分逻辑以具体方法以及具体构造函数的形式实现，然后声明一些抽象方法让子类来实现剩余的逻辑，不同的子类可以以不同的方式来实现这些逻辑。所以模板方法的模板其实就是一个普通的方法，只不过这个方法是将算法实现的步骤封装起来的。

参与者：

AbstractClass: 抽象类。实现了一个模板，实现算法的基本骨架，具体子类将重定义primitiveOperation()方法以实现一个算法步骤。

ConcreteClass: 具体子类。实现primitiveOperation()方法以完成算法中与特定子类相关的步骤。

k. 访问者模式：访问者模式的目的是封装一些施加于某种数据结构元素之上的操作，一旦这些操作需要修改的话，接受这个操作的数据结构可以保持不变。为不同类型的元素提供多种访问操作方式，且可以在不修改原有系统的情况下增加新的操作方式，这就是访问者模式的模式动机。参照下面UML将就是可以添加一个新的Visitor子类，而不改变UML架构。

UML结构图：

访问者模式主要包含如下几个角色：

     Vistor: 抽象访问者。为该对象结构中的ConcreteElement的每一个类声明的一个操作。
      ConcreteVisitor: 具体访问者。实现Visitor申明的每一个操作，每一个操作实现算法的一部分。
     Element: 抽象元素。定义一个Accept操作，它以一个访问者为参数。
      ConcreteElement: 具体元素。实现Accept操作。
     ObjectStructure: 对象结构。能够枚举它的元素，可以提供一个高层的接口来允许访问者访问它的元素。

实例：在医院付费、取药为实例。在这个实例中划价员和药房工作者作为访问者，药品作为访问元素、处方单作为对象结构，所以整个UML结构图如下：