软件体系架构课下作业06

题目：对上学期学习的软件设计模式进行复习，对所有设计模式进行分析，用自己的话来阐述对他们的理解。（不少于2000字）

 

　　正如本学期所学习的软件体系架构，还有很多其他的软件工程技术一样，设计模式同样起源于建筑领域他是对前人经验的总结，为后人设计与开发基于面向对象的软件提供指导方针和成熟的解决方案。

　　从模式的目的而言，设计模式可以分为创建型、结构型和行为型三种。创建型模式主要用于创建对象，它包含5种模式，分别是：工厂方法模式、抽象工厂模式、建造者模式、原型模式和单例模式；结构型模式主要用于处理类和对象的组合，它包含7种模式：适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式和代理模式；行为型模式主要用于描述对类或对象怎样交互和怎样分配职责，总共有11种行为型模式，分别是：职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式和访问者模式。。

　　首先是创建型模式『创建型模式对类的实例化过程进行了抽象，能够将软件模块中对象的创建和对象的使用分离』：

简单工厂模式：

　　模式构成：由三种角色构成，分别是：工厂角色（Factory，判断用户的不同输入，返回给用户所需要的对应产品）、抽象产品角色（Product，定义产品的共有属性）和具体产品角色（ConcreteProduct，不同的具体产品类定义不同产品的各自独特属性）。

　　类间关系：具体产品类可有分为很多种（A、B、C…），它继承抽象产品类，工厂类继承所有的具体产品类。

　　具体使用：在使用时直接调用工厂类，给出想要的产品名称，工厂类会直接返回给对应产品，对于用户而言，无需知道产品的创建细节。

工厂方法模式：

　　模式构成：由四种角色构成，分别是：抽象产品（Product，定义产品的共有属性）、具体产品（ConcreteProduct，不同的具体产品类定义不同产品的各自独特属性）、抽象工厂（Factory，定义了工厂的方法）、具体工厂（ConcreteFactory，不同的具体工厂类定义不同工厂的各自方法）。

　　类间关系：具体产品类可以有很多种（A、B、C…），它们都继承抽象产品类，对应每一个具体产品也会有一个具体工厂类（FA、FB、FC…），它们都继承抽象工厂类，每一种具体工厂类都会继承对应的具体产品类。

　　具体使用：用户调用想要产品对应的具体工厂类，此工厂类会返回此工厂对应的产品。对用户而言，无需知道产品的创建细节，但是在增加新产品的时候，还需要增加新的工厂类，系统复杂度增加。

抽象工厂模式：

　　模式构成：由四种角色构成，分别是：抽象产品（Product，定义产品的共有属性）、具体产品（ConcreteProduct，不同的具体产品类定义不同产品的各自独特属性）、抽象工厂（Factory，定义一组方法，每个方法对应着不同产品等级结构的方法）、具体工厂（ConcreteFactory，不同的具体工厂类定义不同工厂的各自方法）。

　　类间关系：具体产品类有多种类型（A、B、C…），具体产品也有对应的等级结构（A：A1、A2…B：B1、B2…），对应着每一类具体产品都会有一个继承他的具体工厂类，不同具体工厂类继承同一个抽象工厂类。

      具体使用：用户在选择一种产品后，可以创建此具体产品类的多个对象，增加、替换产品族很方便，但是在增加新的产品等级结构时很复杂，需要修改工厂类和产品类，提高了管理难度。

建造者模式：

       模式构成：由四种角色构成，分别是：抽象建造者（Builder，提供为一个产品对象定义的建造方法）、具体建造者（ConcreteBuilder，继承抽象建造者类中定义的方法）、产品角色（Product，被构建的对象，包含多个组成部件）和指挥官（Director，安排复杂对象的建造次序）。

       类间关系：抽象建造者类提供了产品的构件实现方法接口，具体建造者类继承它并进行实现，实现后的结果为产品类。指挥者类调用抽象建造者中定义的方法，并加以汇总，得出结果。

       具体使用：用户无需关心产品内部组成细节，直接和指挥者沟通就能得到产品，但是这个模式对产品有限制，适用范围受到限制。

原型模式：

       模式构成：由三种角色构成，分别是：抽象原型类（Prototype，提供克隆自己的方法接口）、具体原型类（ConcretePrototype，实现具体的克隆方法，返回一个克隆对象）和客户类（Client，调用原型类来让原型克隆自身，创建一个克隆对象）。

       类间关系：具体原型类继承抽象原型类，对其中定义的方法给出具体实现，客户类调用抽象原型类，定义复制方法对原型进行克隆。

       具体使用：用户可以快速创建很多相似的对象，简化对象的创建过程，但是如果要对对象的属性进行修改，就十分复杂。

单例模式：

       模式构成：由一个角色构成：单例角色（Singleton，类内部对自己进行定义，并进行实例化）。

       类间关系：单例类在类内调用自身。

       具体使用：用户对唯一的物品进行实例化，节约系统资源，但是因为缺少抽象层而难以扩展，负担的职责过重。

其次是结构型模式『描述如何将类或者对象结合在一起形成更大的结构』：

适配器模式：

       模式构成：由四个角色构成，分别是：目标抽象类（Target，定义用户要用的特定领域的接口）、适配器类（Adapter，对Target和Adaptee进行适配）、适配者类（Adaptee，定义一个已存在的接口）和客户类（Client，针对目标抽象类进行编程）。

       类间关系：适配器类继承目标抽象类，实现其中的接口，这一方法中调用了适配者类中定义的方法，从而将两者关联起来。用户通过客户类来实现目标抽象类中定义的方法。

       具体使用：用户可以通过调用抽象类，并加以适配，实现另一个类的方法。目标类和适配器类接偶，灵活性和扩展性极大提高。但是很难置换适配者类的方法。

桥接模式：

       模式构成：由四种角色构成，分别是：抽象类（Abstraction，定义抽象类的接口）、扩充抽象类（RefinedAbstraction，扩充抽象类定义的接口，实现了方法）、实现类接口（Implementor，提供基本操作）和具体实现类（ConcreteImplementor，实现接口并具体实现它）。

       类间关系：扩充抽象类可有多种（A、B、C…），都继承自抽象类，具体实现类也有多种（a、b、c…），它们也继承自实现接口类，根据不同的需要，扩充抽象类和具体实现类进行组合

具体使用：分离了抽象接口与实现部分，提高了可扩展性，但是增加了理解难度，不容易识别独立变化的两种分量。

组合模式：

       模式构成：由四种角色构成：抽象构件（Component，为叶子和容器构件对象声明了接口）、叶子构件（Leaf，实现了其独特的方法）、容器构件（Composite，容器节点对象，包含自节点，可以是叶子节点或是容器节点）和客户类（通过抽象构件接口访问和控制组合构件中的对象）。

       类间关系：叶子构件和容器构件继承抽象构件，叶子节点提供自身方法，容器对象相当于另一个抽象构件，依然可以有继承它的叶子和容器。客户类调用抽象构件。

       具体实现：方便的对层次结构进行控制，调用简单，但是设计变得抽象

装饰模式：

       模式构成：由四种角色构成：抽象构件（Component，定义了对象的接口）、具体构件（ConcreteComponent，定义了具体的构件对象）、抽象装饰类（Decorator，给具体构件中增加职责）和具体装饰类（ConcreteDecorator，向构件添加新的职责）。

       类间关系：具体构件和抽象装饰类继承抽象构件类，具体构件类实现抽象构件中定义的方法，抽象装饰类调用抽象构件类的方法，多个具体装饰类继承抽象装饰类，为装饰类提供额外职责。

       具体实现：比继承更加灵活，通过动态的方法就可以扩展一个对象的功能，但是由于小对象过多，也更容易出现错误。

外观模式：

       模式构成：有两个角色构成：外观角色（Façade，客户端调用此方法显示相关子系统的功能和责任）和子系统角色（每个子系统完成各自的方法，实现功能）。

       类间关系：子系统可以有多个（A、B、C…），外观角色中定义各个子系统角色，并调用相应功能。

       具体实现：减少了用户处理的对象数目，只需要在一个外观角色上就可以了解到系统含有的所有子系统，使用起来更加容易，降低了耦合度，但是不能限制用户的行为，且增加新子系统会违背“开闭原则”。

享元模式：

       模式构成：由四种角色构成，分别是：抽象享元类（Flyweight，声明一个接口，定义了公共方法）、具体享元类（ConcreteFlyweight，实现了接口以及公共方法）、非共享具体享元类（UnsharedConcreteFlyweight，一些不需要共享的类）和享元工厂类（创建并管理享元对象）。

       类间关系：具体享元类和非共享具体享元类继承抽象享元类，实现其中接口定义的方法。在享元工厂中定义享元类变量，实现定义好的功能。

       具体实现：减少内存中对象的数量，但是增加了系统的复杂度。

代理模式：

       模式构成：包含三种角色：抽象主题角色（Subject，声明了真实主题和代理主题的共同接口）、代理主题角色（Proxy，对真实主题的引用）和真实主题角色（RealSubject，定义了代表角色所带标得真实对象）。

       类间关系：代理主题角色和真实主题角色继承自抽象主题角色，真实主题角色实现抽象主题中定义的方法，代理主题角色定义真实主题类的实例，同时定义一系列方法。

       具体实现：协调调用者和被调用者，降低了耦合度，但是增加代理对象会使得系统复杂，影响整体性能与速度。

第三种，是行为型模式『对在不同的对象之间划分责任和算法的抽象化』：

职责链模式：

       模式构成：包含三种角色：抽象处理者（Handler定义了处理请求的接口）、具体处理者（ConcreteHandler，处理用户请求，实现了抽象处理者中定义的接口方法）和客户类（Client，向链中对象提出请求）。

       类间关系：具体处理者有多个（A、B、C…），它们均继承抽象处理者类，其中定义了处理请求的方法，具体中实现方法客户类调用抽象处理者中方法。

       具体实现：降低了系统的耦合度，简化连接，提高了灵活性，但是不能保证请求一定被接收，对于过长的职责链，性能也会受到影响。

命令模式：

       模式构成：由五种角色构成，分别是：抽象命令类（Command，提供了接口，声明了方法，可以调用接受者的操作）、具体命令类（ConcreteCommand，实现抽象命令类中声明的方法）、调用者（Invoker，通过命令对象来执行请求）、接受者（Receiver，实现对请求的业务处理）和客户类（Client，创建发送者对象和具体命令类对象）。

       类间关系：具体命令类继承抽象命令类，实现其中定义的方法，调用者定义了抽象的方法和对象，接收者对具体类进行实例化，客户类调用调用者类来操作。

       具体实现：降低了系统的耦合度，便于增加新的命令，但是回导致系统有过多的具体命令类。

解释器模式：

       模式构成：包含五种角色：抽象表达式（AbstractExpression，声明了抽象的解释操作）、终结符表达式（TerminalExpression，实现了和终结符相关联的解释操作）、非终结符表达式（NonterminalExpression，实现非终结符的解释操作）、环境类（Context，存储解释器之外的全局信息）和客户类（Client，构造了表示该文法定义的语言中一个特定句子中的抽象语法树，完成对句子的解释）。

       类间关系：终结符表达式和非终结符表达式继承抽象表达式，实现其中定义的方法。客户类在使用时，会实例化环境类和抽象表达式类，从而完成对句子的解释。

       具体实现：使用该模式，使得文法易于改变和扩展，易于实现文法，但是文法如果过于复杂的话，操作难度增加，执行效率也会降低。

迭代器模式：

       模式构造：包含四种角色：抽象迭代器（Iterator，定义了接口和方法）、具体迭代器（ConcreteIterator，实现了接口定义的方法）、抽象聚合类（Aggregate，定义了相应迭代器对象的接口，声明方法）、和具体聚合类（ConcreteAggregate，实现接口和定义的方法来创建迭代器对象）。

       类间关系：具体迭代器类继承抽象迭代器类，实现了迭代的方法，具体聚合类继承抽象聚合类，对具体实现类实例化

       具体实现：简化了聚合类，但是若要增加新的聚合类，就还需要增加对应的迭代器类，增加了系统的复杂度。

中介者模式：

       模式构造：包含四种角色：抽象中介者（Mediator，定义了用于个同事对象之间通信的接口）、具体中介者（ConcreteMediator，实现接口定义的方法）、抽象同事类（Colleague，定义同事的共有方法）和具体同事类（ConcreteColleague，不同同事实现各自不同的方法）

       类间关系：具体同事类继承抽象同事类，并实现其中的方法，具体中介者继承抽象中介者，具体中介者中实例化具体同事类，并调用其中的方法。

       具体实现：简化了对象之间的交互，降低了系统的耦合性，但是具体中介者为了实现每个同事类的方法，可能会很复杂。

备忘录模式：

       模式构造：含有三种角色：原发器（Originator，用于创建备忘录，并储存当前状态）、备忘录（Memento，存储原发器的内部状态）和负责人（Caretaker，保存备忘录）。

       类间关系：原发器在方法中调用备忘录类，将类实例化并调用备忘录中的方法，而负责人只能负责保存备忘录。

       具体实现：提供了状态恢复的机制，利于用户的操作，但是资源消耗过大。

观察者模式：

       模式构成：包含四种角色：目标（Subject，提供接口和方法）、具体目标（ConcreteSubject，实现目标类中定义的方法）、观察者（Observer，声明了方法）、具体观察者（ConcreteObserver，实现了观察者类中的方法）。

       类间关系：具体目标继承目标类，实现其中定义的方法，同时，实例化观察者类，具体观察者类可以有多个，均继承观察者类。

       具体实现：实现了表示层和罗基层的分离，但是如果一个观察目标有多个观察者，通知所有的观察者会话费很多时间，影响系统的性能。

状态模式：

       模式构成：包含环境类（Context，拥有状态的对象，但在不同的状态行为不同）、抽象状态类（State，定义接口与不同状态的共有方法）和具体状态类（ConcreteState，实现对应的方法）三种。

       类间关系：具体状态类有多种，它们均继承抽象状态类，实现抽象类中定义的方法。环境类实例化状态类，通过对象调用类中定义的方法。

       具体实现：封装性好，方便的增加新状态，但是状态过多会导致系统过于复杂。

策略模式：

     模式构成：环境类（Context，使用算法的对象，对于不同的问题采用多种策略）、抽象策略类（Strategy，定义了方法）、具体策略类（ConcreteStrategy，实现了抽象方法）。

       类间关系：具体策略类有多种，它们均继承抽象策略类，不同的策略类拥有不同的方法。环境类实例化状态类，通过对象调用类中定义的方法。

       具体方法：很好的支持了“开闭原则”，提高了代码的复用性，但是系统的复杂程度也会因为类个数的增多而提高。

模板方法模式：

       模式构成：仅由两个角色构成，他们分别是：抽象类（AbstractClass，定义了一系列操作的方法）和具体子类（ConcreteClass，实现了抽象类中的方法）。

类间关系：具体子类继承抽象类，不同的子类实现各自不同的方法。

       具体方法：代码的复用性很高，但是系统的复杂程度也会因为类个数的增多而提高。

访问者模式：

       模式构成：由五种角色构成：抽象访问者（Visitor，声明了访问方法）、具体访问者（ConcreteVisitor，继承抽象访问者，实现其中的方法）、抽象元素（Element，定义了accept方法）、具体元素（ConcreteElement，实现了accept方法）和对象结构（ObjectStructure，数组的集合，存放元素对象且提供遍历方法）。

       具体方法：新增访问操作变得简单，遵守了开闭原则，但是新增元素很难，破坏封装性。

转载于:https://www.cnblogs.com/Daddy/p/6660076.html