(转)设计模式

 在UML类图中，常见的有以下几种关系: 泛化（Generalization）,  实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)

         1. 泛化（Generalization）

        【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。例如：老虎是动物的一种，即有老虎的特性也有动物的共性。

        【箭头指向】：带三角箭头的实线，箭头指向父类

 

 

 2. 实现（Realization）

        【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现.

        【箭头指向】：带三角箭头的虚线，箭头指向接口

 

 3. 关联（Association)

        【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。

        【代码体现】：成员变量

        【箭头及指向】：带普通箭头的实心线，指向被拥有者

 

 

 

上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。 

        下图为自身关联： 

 

 

    4. 聚合（Aggregation）——one of >>

        【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系，轮胎离开车仍然可以存在。

        聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。

        【代码体现】：成员变量

        【箭头及指向】：带空心菱形的实心线，菱形指向整体

 

 

 5. 组合(Composition)——part of

        【组合关系】：是整体与部分的关系，但部分不能离开整体而单独存在。如公司和部门是整体和部分的关系，没有公司就不存在部门。

       组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。

【代码体现】：成员变量

【箭头及指向】：带实心菱形的实线，菱形指向整体

 

 

6. 依赖(Dependency)

        【依赖关系】：是一种使用的关系，即一个类的实现需要另一个类的协助，所以要尽量不使用双向的互相依赖.

        【代码表现】：局部变量、方法的参数或者对静态方法的调用

        【箭头及指向】：带箭头的虚线，指向被使用者

创建型

1. Factory Method（工厂方法）

 

 

 

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

2. Abstract Factory（抽象工厂）

 定义：提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。

3. Builder（生成器模式）

定义：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。（Director类作为指挥者，指挥Builder生成器来组合生成对应的具体产品，是将Builder中无序的各种部件组合起来的方法）

类图：

 

4. Prototype（原型模式）

定义：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

类图：

 

 应用范围：关注的是大量相同或相似对象的创建问题，意图在于通过复制一个已经存在的实例来获得一个新的实例，以避免重复创建此类实例带来的开销。被复制的实例就是这个“原型”，这个原型是可定制的。相比于工厂模式，原型模式减少了子类的创建。

5.Singleton（单例模式）

定义：确保一个类只有一个实例，并提供全局访问点。

类图：

 6.适配器模式

定义：将一个类的接口转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。

类图：

 

 

 7.桥接模式

定义：将抽象部分与它的实现部分分离，使它们都可以独立地变化。

类图：

 

 

    在以下的情况下应当使用桥梁模式：
1．如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。 
2．设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。
3．一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。 
4．虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。

8.Composite（组合模式）

定义：将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性。

类图：

 

 

  1. 组合模式采用树形结构来实现普遍存在的对象容器， 从而将“一对多”的关系转化成“一对一”的关系， 使得客户代码可以一致地处理对象和对象容器，无需关系处理的是单个对象，还是组合对象。
  2. 将“客户代码与复杂的对象容器结构”解耦是组合模式的核心， 解耦之后，客户代码将与纯粹的抽象接口--而非对象容器的内部实现结构发生依赖， 从而更能应对变化。
  3. 组合模式在具体实现中，可以让父对象中的子对象反向追溯；如果父对象有频繁的遍历需求可使用缓存技巧来改善效率.

9.装饰模式

定义：动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更加灵活。

类图：

 

 特点：有效的把类的核心职责和装饰功能区分开，而且可以去除相关类中重复的装饰逻辑

10.Facade外观模式

定义：为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高级接口，这个接口使得这一子系统更加容易使用。

 

 Flyweight(享元模式)

定义：运用共享技术有效地支持大量细粒度的对象。

 

 享元模式是一种用于解决资源和性能压力时会使用到的设计模式，它的核心思想是通过引入数据共享来提升性能。重点在于将不可变（可共享）的属性和可变的属性区分开。相同类型的对象共享不可变的数据，而每个对象又有其独立的数据，这部分数据为：可变的属性

享元模式一个类对象只允许创建不同类型的对象，这样保证同一类型的对象共享不可变数据。

代理模式（Proxy）

定义：为其他对象提供一种代理以控制对这个对象的访问。

类图

 

 使用场景：

代理类主要负责为委托类预处理消息、过滤消息、把消息转发给委托类，以及事后对返回结果的处理等。代理类本身并不真正实现服务，而是通过调用委托类的相关方法，来提供特定的服务。真正的业务功能还是由委托类来实现，但是可以在业务功能执行的前后加入一些公共的服务。例如我们想给项目加入缓存、日志这些功能，我们就可以使用代理类来完成，而没必要打开已经封装好的委托类。

解释器模式

定义：给定一个语言，定义它的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。

类图：

 

用的很少。

模板方法

定义：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。TemplateMethod使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

类图：

 

 使用场景：1、有多个子类共有的方法，且逻辑相同。 2、重要的、复杂的方法，可以考虑作为模板方法。

 职责链模式

定义：使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

类图：

 

 责任链模式的本质是解耦请求与处理，让请求在处理链中能进行传递与被处理；理解责任链模式应当理解其模式，而不是其具体实现。责任链模式的独到之处是将其节点处理者组合成了链式结构，并允许节点自身决定是否进行请求处理或转发，相当于让请求流动起来。

命令模式

定义：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。

类图：

 

 

Command（抽象命令类）：抽象出命令对象，可以根据不同的命令类型。写出不同的实现类

ConcreteCommand（具体命令类）：实现了抽象命令对象的具体实现

Invoker（调用者/请求者）：请求的发送者，它通过命令对象来执行请求。一个调用者并不需要在设计时确定其接收者，因此它只与抽象命令来之间

存在关联。在程序运行时，将调用命令对象的execute() ，间接调用接收者的相关操作。

Receiver（接收者）：接收者执行与请求相关的操作，真正执行命令的对象。具体实现对请求的业务处理。未抽象前，实际执行操作内容的对象。

Client（客户端）：在客户类中需要创建调用者对象，具体命令类对象，在创建具体命令对象时指定对应的接收者。发送者和接收者之间没有之间关系。

都通过命令对象来调用。

迭代模式

定义：提供一种方法顺序访问一个聚合对象中各个元素，而又不需暴露该对象的内部表示。

类图：

 

 迭代器模式”，它在客户访问类与聚合类之间插入一个迭代器，这分离了聚合对象与其遍历行为，对客户也隐藏了其内部细节，且满足“单一职责原则”和“开闭原则”。

迭代器模式在生活中应用的比较广泛，比如：物流系统中的传送带，不管传送的是什么物品，都会被打包成一个个箱子，并且有一个统一的二维码。这样我们不需要关心箱子里是什么，在分发时只需要一个个检查发送的目的地即可。再比如，我们平时乘坐交通工具，都是统一刷卡或者刷脸进站，而不需要关心是男性还是女性、是残疾人还是正常人等信息。

Mediator（中介模式）

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

 

 使用场景：

  • 系统中对象之间存在比较复杂的引用关系
  • 想通过一个中间类来封装多个类的行为，而又不想生成太多的子类

实例：

  • 联合国/WTO作为中介者协调各个国家
  • 房屋中介/机场调度系统
  • MVC框架，其中C（Contorller控制器）是M（Model模型）和V（View视图）的中介者

备忘录模式

定义：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。

 使用场景

  • 给用户提供了一种可以恢复状态的机制，可以使用能够比较方便地回到某个历史的状态
  • 实现了信息的封装，使得用户不需要关心状态的保存细节

应用实例

  • 游戏存档
  • ctrl+z键、浏览器回退键等（撤销/还原）
  • 棋盘类游戏的悔棋
  • 数据库事务的回滚

观察者模式

定义：定义对象间的一种一对多的依赖关系，当一个对象的状态发生变化时，所有依赖于它的对象都得到通知并被自动更新。

 

 又被称作发布-订阅模式。

优点如下：

  1. 降低了目标与观察者之间的耦合关系，两者之间是抽象耦合关系。符合依赖倒置原则。
  2. 目标与观察者之间建立了一套触发机制。

缺点如下：

它的主要缺点如下。

  1. 目标与观察者之间的依赖关系并没有完全解除，而且有可能出现循环引用。
  2. 当观察者对象很多时，通知的发布会花费很多时间，影响程序的效率。

状态模式

定义：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。

类图：

 

 状态的变化，而状态模式主要解决的问题就是当控制一个对象状态转换的条件表达式过于复杂时的情况。即把状态的判断逻辑转移到标识不同状态的一系列类当中。

使用场景：

  • 代码中包含大量与对象状态有关的条件语句

优点：

  • 结构清晰，避免了过多的switch…case或if…else语句的使用
  • 很好的体现了开闭原则和单一职责原则，想要增加状态就增加子类，想要修改状态就修改子类即可
  • 封装性非常好，状态变化放置到了类的内部来实现，外部调用不需要知道类内部如何实现状态和行为的变换

对于环境角色，有几个不成文的约束：

    • 即把状态对象声明为静态常量，有几个状态对象就声明几个状态常量
    • 环境角色具有状态抽象角色定义的所有行为，具体执行使用委托方式

策略模式

定义：定义一系列的算法，把它们一个个封装起来，并且使它们可互相替换。本模式使得算法可独立于使用它的客户而变化。

类图：

 

 访问者模式

定义：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的前提下定义作用于这些元素的新操作。

 

使用场景

  1. 对象结构比较稳定，但经常需要在此对象结构上定义新的操作。
  2. 需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免这些操作“污染”这些对象的类，也不希望在增加新操作时修改这些类。

 

posted @ 2022-04-28 14:17  景木  阅读(61)  评论(0)    收藏  举报