结构型设计模式之组合模式、装饰者模式和门面模式

组合模式（Composite Pattern）

定义：Compose objects into tree structures to represent part-whole hierarchies.Composite lets clients treat individual objects and compositions of objects uniformly.（将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。）
组合模式类图：

• Component抽象构件角色

定义参加组合对象的共有方法和属性，可以定义一些默认的行为或属性，比如我们例子中的getInfo就封装到了抽象类中。

• Leaf叶子构件

叶子对象，其下再也没有其他的分支，也就是遍历的最小单位。

• Composite树枝构件

树枝对象，它的作用是组合树枝节点和叶子节点形成一个树形结构。
树枝构件的通用代码：

public class Composite extends Component {
    //构件容器
    private ArrayList<Component> componentArrayList = new ArrayList<Component>();
    //增加一个叶子构件或树枝构件
    public void add(Component component){
        this.componentArrayList.add(component);
    }
    //删除一个叶子构件或树枝构件
    public void remove(Component component){
        this.componentArrayList.remove(component);
    }
    //获得分支下的所有叶子构件和树枝构件
    public ArrayList<Component> getChildren(){
        return this.componentArrayList;
    }
}

使用场景：

• 维护和展示部分-整体关系的场景，如树形菜单、文件和文件夹管理。
• 从一个整体中能够独立出部分模块或功能的场景。

💡注意：
只要是树形结构，就考虑使用组合模式。

装饰者模式（Decorator Pattern）

定义：Attach additional responsibilities to an object dynamically keeping the same interface.Decorators provide a flexible alternative to subclassing for extending functionality.（动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更为灵活。）
装饰器模式类图：

• Component抽象构件

Component是一个接口或者是抽象类，就是定义我们最核心的对象，也就是最原始的对象，如上面的成绩单。
注意：在装饰模式中，必然有一个最基本、最核心、最原始的接口或抽象类充当Component抽象构件。

• ConcreteComponent 具体构件

ConcreteComponent是最核心、最原始、最基本的接口或抽象类的实现，你要装饰的就是它。

• Decorator装饰角色

一般是一个抽象类，做什么用呢？实现接口或者抽象方法，它里面可不一定有抽象的方法呀，在它的属性里必然有一个private变量指向Component抽象构件。

• 具体装饰角色

ConcreteDecoratorA和ConcreteDecoratorB是两个具体的装饰类，你要把你最核心的、最原始的、最基本的东西装饰成其他东西，上面的例子就是把一个比较平庸的成绩单装饰成家长认可的成绩单。
使用场景：

• 需要扩展一个类的功能，或给一个类增加附加功能。
• 需要动态地给一个对象增加功能，这些功能可以再动态地撤销。
• 需要为一批的兄弟类进行改装或加装功能，当然是首选装饰模式。

外观/门面模式（Facade Pattern）

定义：Provide a unified interface to a set of interfaces in a subsystem.Facade defines a higher-level interface that makes the subsystem easier to use.（要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。）
门面模式类图：

• Facade门面角色 客户端可以调用这个角色的方法。此角色知晓子系统的所有功能和责任。一般情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去，也就说该角色没有实际的业务逻辑，只是一个委托类。 -subsystem子系统角色 可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，而是一个类的集合。子系统并不知道门面的存在。对于子系统而言，门面仅仅是另外一个客户端而已。

使用场景：

• 为一个复杂的模块或子系统提供一个供外界访问的接口
• 子系统相对独立——外界对子系统的访问只要黑箱操作即可
• 预防低水平人员带来的风险扩散

💡注意：

• 一个子系统可以有多个门面
• 门面不参与子系统内的业务逻辑

本文内容到此结束了，
如有收获欢迎点赞👍收藏💖关注✔️，您的鼓励是我最大的动力。
如有错误❌疑问💬欢迎各位大佬指出。
保持热爱，奔赴下一场山海。🏃🏃🏃