设计模式之结构型模式

        结构型模式描述如何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式，前者采用继承机制来组织接口和类，后者釆用组合或聚合来组合对象。

代理模式

1、概述：

        代理模式的定义：由于某些原因需要给某对象提供一个代理以控制对该对象的访问。这时，访问对象不适合或者不能直接引用目标对象，代理对象作为访问对象和目标对象之间的中介。

2、主要角色：

        ①、 Subject（抽象主题角色）：它声明了真实主题和代理主题的共同接口，这样一来在任何使用真实主题的地方都可以使用代理主题，客户端通常需要针对抽象主题角色进行编程。

        ②、Proxy（代理主题角色）：它包含了对真实主题的引用，从而可以在任何时候操作真实主题对象；在代理主题角色中提供一个与真实主题角色相同的接口，以便在任何时候都可以替代真实主题；代理主题角色还可以控制对真实主题的使用，负责在需要的时候创建和删除真实主题对象，并对真实主题对象的使用加以约束。通常，在代理主题角色中，客户端在调用所引用的真实主题操作之前或之后还需要执行其他操作，而不仅仅是单纯调用真实主题对象中的操作。

        ③、 RealSubject（真实主题角色）：它定义了代理角色所代表的真实对象，在真实主题角色中实现了真实的业务操作，客户端可以通过代理主题角色间接调用真实主题角色中定义的操作。

3、应用场景：

        ①、当客户端对象需要访问远程主机中的对象时可以使用远程代理。

        ②、当需要用一个消耗资源较少的对象来代表一个消耗资源较多的对象，从而降低系统开销、缩短运行时间时可以使用虚拟代理，例如一个对象需要很长时间才能完成加载时。

        ③、当需要为某一个被频繁访问的操作结果提供一个临时存储空间，以供多个客户端共享访问这些结果时可以使用缓冲代理。通过使用缓冲代理，系统无须在客户端每一次访问时都重新执行操作，只需直接从临时缓冲区获取操作结果即可。

        ④、当需要控制对一个对象的访问，为不同用户提供不同级别的访问权限时可以使用保护代理。

        ⑤、当需要为一个对象的访问（引用）提供一些额外的操作时可以使用智能引用代理。

4、优点：

        ①、能够协调调用者和被调用者，在一定程度上降低了系统的耦合度。

        ②、客户端可以针对抽象主题角色进行编程，增加和更换代理类无须修改源代码，符合开闭原则，系统具有较好的灵活性和可扩展性。

5、缺点：

        ①、由于在客户端和真实主题之间增加了代理对象，因此有些类型的代理模式可能会造成请求的处理速度变慢，例如保护代理。

        ②、实现代理模式需要额外的工作，而且有些代理模式的实现过程较为复杂，例如远程代理。

适配器模式

1、概述：

        适配器模式（Adapter）的定义如下：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。适配器模式分为类结构型模式和对象结构型模式两种，前者类之间的耦合度比后者高，且要求程序员了解现有组件库中的相关组件的内部结构，所以应用相对较少些。

2、主要角色：

        ①、目标（Target）接口：当前系统业务所期待的接口，它可以是抽象类或接口。

        ②、适配者（Adaptee）类：它是被访问和适配的现存组件库中的组件接口。

        ③、适配器（Adapter）类：它是一个转换器，通过继承或引用适配者的对象，把适配者接口转换成目标接口，让客户按目标接口的格式访问适配者。

3、应用场景：

        ①、系统需要使用一些现有的类，而这些类的接口（如方法名）不符合系统的需要，甚至没有这些类的源代码。

        ②、想创建一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作。

4、优点：

        ①、客户端通过适配器可以透明地调用目标接口。

        ②、复用了现存的类，程序员不需要修改原有代码而重用现有的适配者类。

        ③、将目标类和适配者类解耦，解决了目标类和适配者类接口不一致的问题。

        ④、在很多业务场景中符合开闭原则。

5、缺点：

        ①、适配器编写过程需要结合业务场景全面考虑，可能会增加系统的复杂性。

        ②、增加代码阅读难度，降低代码可读性，过多使用适配器会使系统代码变得凌乱。

桥接模式

1、概述：

        桥接（Bridge）模式的定义如下：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。

2、主要角色：

        ①、抽象化（Abstraction）角色：定义抽象类，并包含一个对实现化对象的引用。

        ②、扩展抽象化（Refined Abstraction）角色：是抽象化角色的子类，实现父类中的业务方法，并通过组合关系调用实现化角色中的业务方法。

        ③、实现化（Implementor）角色：定义实现化角色的接口，供扩展抽象化角色调用。

        ④、具体实现化（Concrete Implementor）角色：给出实现化角色接口的具体实现。

3、应用场景：

        ①、当一个类存在两个独立变化的维度，且这两个维度都需要进行扩展时。

        ②、当一个系统不希望使用继承或因为多层次继承导致系统类的个数急剧增加时。

        ③、当一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性时。

4、优点：

        ①、抽象与实现分离，扩展能力强

        ②、符合开闭原则

        ③、符合合成复用原则

        ④、其实现细节对客户透明

5、缺点：

        由于聚合关系建立在抽象层，要求开发者针对抽象化进行设计与编程，能正确地识别出系统中两个独立变化的维度，这增加了系统的理解与设计难度。

装饰模式

1、概述：

        装饰器（Decorator）模式的定义：指在不改变现有对象结构的情况下，动态地给该对象增加一些职责（即增加其额外功能）的模式，它属于对象结构型模式。

2、主要角色：

        ①、抽象构件（Component）角色：定义一个抽象接口以规范准备接收附加责任的对象。

        ②、具体构件（ConcreteComponent）角色：实现抽象构件，通过装饰角色为其添加一些职责。

        ③、抽象装饰（Decorator）角色：继承抽象构件，并包含具体构件的实例，可以通过其子类扩展具体构件的功能。

        ④、具体装饰（ConcreteDecorator）角色：实现抽象装饰的相关方法，并给具体构件对象添加附加的责任。

3、应用场景：

        ①、当需要给一个现有类添加附加职责，而又不能采用生成子类的方法进行扩充时。例如，该类被隐藏或者该类是终极类或者采用继承方式会产生大量的子类。

        ②、当需要通过对现有的一组基本功能进行排列组合而产生非常多的功能时，采用继承关系很难实现，而采用装饰器模式却很好实现。

        ③、当对象的功能要求可以动态地添加，也可以再动态地撤销时。

4、优点：

        ①、装饰器是继承的有力补充，比继承灵活，在不改变原有对象的情况下，动态的给一个对象扩展功能，即插即用

        ②、通过使用不用装饰类及这些装饰类的排列组合，可以实现不同效果

        装饰器模式完全遵守开闭原则

5、缺点：

        装饰器模式会增加许多子类，过度使用会增加程序得复杂性。

外观模式

1、概述：

        外观（Facade）模式又叫作门面模式，是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。

2、主要角色：

        ①、外观（Facade）角色：为多个子系统对外提供一个共同的接口。

        ②、子系统（Sub System）角色：实现系统的部分功能，客户可以通过外观角色访问它。

        ③、客户（Client）角色：通过一个外观角色访问各个子系统的功能。

3、应用场景：

        ①、对分层结构系统构建时，使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系。

        ②、当一个复杂系统的子系统很多时，外观模式可以为系统设计一个简单的接口供外界访问。

        ③、当客户端与多个子系统之间存在很大的联系时，引入外观模式可将它们分离，从而提高子系统的独立性和可移植性。

4、优点：

        ①、降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类。

        ②、对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易。

        ③、降低了大型软件系统中的编译依赖性，简化了系统在不同平台之间的移植过程，因为编译一个子系统不会影响其他的子系统，也不会影响外观对象。

5、缺点：

        ①、不能很好地限制客户使用子系统类，很容易带来未知风险。

        ②、增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。

享元模式

1、概述：

        享元（Flyweight）模式的定义：运用共享技术来有效地支持大量细粒度对象的复用。它通过共享已经存在的对象来大幅度减少需要创建的对象数量、避免大量相似类的开销，从而提高系统资源的利用率。

2、主要角色：

        ①、抽象享元角色（Flyweight）：是所有的具体享元类的基类，为具体享元规范需要实现的公共接口，非享元的外部状态以参数的形式通过方法传入。

        ②、具体享元（Concrete Flyweight）角色：实现抽象享元角色中所规定的接口。

非享元（Unsharable Flyweight)角色：是不可以共享的外部状态，它以参数的形式注入具体享元的相关方法中。

        ③、享元工厂（Flyweight Factory）角色：负责创建和管理享元角色。当客户对象请求一个享元对象时，享元工厂检査系统中是否存在符合要求的享元对象，如果存在则提供给客户；如果不存在的话，则创建一个新的享元对象。

3、应用场景：

        ①、系统中存在大量相同或相似的对象，这些对象耗费大量的内存资源。

        ②、大部分的对象可以按照内部状态进行分组，且可将不同部分外部化，这样每一个组只需保存一个内部状态。

        ③、由于享元模式需要额外维护一个保存享元的数据结构，所以应当在有足够多的享元实例时才值得使用享元模式。

4、优点：

        相同对象只要保存一份，这降低了系统中对象的数量，从而降低了系统中细粒度对象给内存带来的压力。

5、缺点：

        ①、为了使对象可以共享，需要将一些不能共享的状态外部化，这将增加程序的复杂性。

②、读取享元模式的外部状态会使得运行时间稍微变长。

组合模式

1、概述：

        组合（Composite Pattern）模式的定义：有时又叫作整体-部分（Part-Whole）模式，它是一种将对象组合成树状的层次结构的模式，用来表示“整体-部分”的关系，使用户对单个对象和组合对象具有一致的访问性。

2、主要角色：

        ①、抽象构件（Component）角色：它的主要作用是为树叶构件和树枝构件声明公共接口，并实现它们的默认行为。在透明式的组合模式中抽象构件还声明访问和管理子类的接口；在安全式的组合模式中不声明访问和管理子类的接口，管理工作由树枝构件完成。（总的抽象类或接口，定义一些通用的方法，比如新增、删除）

        ②、树叶构件（Leaf）角色：是组合中的叶节点对象，它没有子节点，用于继承或实现抽象构件。

        ③、树枝构件（Composite）角色 / 中间构件：是组合中的分支节点对象，它有子节点，用于继承和实现抽象构件。它的主要作用是存储和管理子部件，通常包含 Add()、Remove()、GetChild() 等方法。

3、应用场景：

        ①、在需要表示一个对象整体与部分的层次结构的场合。

        ②、要求对用户隐藏组合对象与单个对象的不同，用户可以用统一的接口使用组合结构中的所有对象的场合。

4、优点：

        ①、组合模式使得客户端代码可以一致地处理单个对象和组合对象，无须关心自己处理的是单个对象，还是组合对象，这简化了客户端代码；

        ②、更容易在组合体内加入新的对象，客户端不会因为加入了新的对象而更改源代码，满足“开闭原则”；

5、缺点：

        ①、设计较复杂，客户端需要花更多时间理清类之间的层次关系；

不容易限制容器中的构件；

        ②、不容易用继承的方法来增加构件的新功能。

设计模式之设计原则

设计模式之创建型模式

设计模式之行为型模式

文章来源: shuaici.blog.csdn.net，作者：帅次，版权归原作者所有，如需转载，请联系作者。

原文链接：shuaici.blog.csdn.net/article/details/116799072