前言：
为什么之前写过Golang 版的设计模式，还在重新写Java 版？
答：因为对于我而言，当然也希望对正在学习的大伙有帮助。Java作为一门纯面向对象的语言，更适合用于学习设计模式。
为什么类图要附上uml
因为很多人学习有做笔记的习惯，如果单纯的只是放一张图片，那么学习者也只能复制一张图片，可复用性较低，附上uml，方便有新理解时，快速出新图。
树形结构的处理——组合模式
组合模式（Composite Pattern）：组合多个对象形成树形结构以表示具有“部分—整体”关系的层次结构。组合模式对单个对象（即叶子对象）和组合对象（即容器对象）的使用具有一致性，又可以称为“部分—整体”（Part-Whole）模式，它是一种对象结构型模式。
在组合模式中引入了抽象构件类Component，它是所有容器类和叶子类的公共父类，客户端针对Component进行编程。
@startuml abstract class Component { + operation() + add(Component c) + remove(Component c) + getChild(int i) } class Leaf extends Component { + operation() + add(Component c) + remove(Component c) + getChild(int i) } class Composite extends Component { - List<Component> child + operation() + add(Component c) + remove(Component c) + getChild(int i) } note left of Composite::operation for (Component c : child) { c.operation() } end note class Client{} Client ..> Component Composite *-up-> Component: 组合关系 @enduml
在组合模式结构图中包含以下3个角色。
（1）Component（抽象构件）：它可以是接口或抽象类，为叶子构件和容器构件对象声明接口，在该角色中可以包含所有子类共有行为的声明和实现。在抽象构件中定义了访问及管理它的子构件的方法，例如增加子构件、删除子构件、获取子构件等。
（2）Leaf（叶子构件）：它在组合模式结构中表示叶子节点对象。叶子节点没有子节点，它实现了在抽象构件中定义的行为。对于那些访问及管理子构件的方法，可以通过捕获异常等方式进行处理。
（3）Composite（容器构件)：它在组合模式结构中表示容器节点对象。容器节点包含子节点，其子节点可以是叶子节点，也可以是容器节点。它提供一个集合用于存储子节点，实现了在抽象构件中定义的行为，包括那些访问及管理子构件的方法，在其业务方法中可以递归调用其子节点的业务方法。
组合模式的关键是定义了一个抽象构件类，它既可以代表叶子，又可以代表容器。客户端针对该抽象构件类进行编程，无须知道它到底表示的是叶子还是容器，可以对其进行统一处理。同时容器对象与抽象构件类之间还建立一个聚合关联关系，在容器对象中既可以包含叶子，也可以包含容器，以此实现递归组合，形成一个树形结构。
代码实现
package struct; import java.util.ArrayList; import java.util.List; public class CompositionDemo { static abstract class Component { public abstract void operation(); public abstract void add(Component c); public abstract void remove(Component c); public abstract Component getChild(int i); } static class Leaf extends Component { private final String name; public Leaf(String name) { this.name = name; } @Override public void operation() { System.out.println(this.name + "Leaf operation"); } @Override public void add(Component c) { // Leaf 类没有实现 add 方法 } @Override public void remove(Component c) { // Leaf 类没有实现 remove 方法 } @Override public Component getChild(int i) { // Leaf 类没有实现 getChild 方法 return null; } } static class Composite extends Component { private final List<Component> child = new ArrayList<>(); private final String name; public Composite(String name) { this.name = name; } @Override public void operation() { System.out.println(this.name + "Composite operation"); for (Component c : child) { c.operation(); } } @Override public void add(Component c) { child.add(c); } @Override public void remove(Component c) { child.remove(c); } @Override public Component getChild(int i) { return child.get(i); } } public static void main(String[] args) { Component leaf1 = new Leaf("节点1"); Component leaf2 = new Leaf("节点2"); Component composite1 = new Composite("组件1"); composite1.add(leaf1); composite1.add(leaf2); Component leaf3 = new Leaf("节点3"); Component composite2 = new Composite("组件2"); composite2.add(leaf3); composite2.add(composite1); composite2.operation(); } }
组合模式分为透明组合模式和安全组合模式两种形式
透明组合模式
透明组合模式中，抽象构件 Component 中声明了所有用于管理成员对象的方法，包括 add（）、remove（） 以及 getChild（） 等方法，这样做的好处是确保所有的构件类都有相同的接口。在客户端看来，叶子对象与容器对象所提供的方法是一致的，客户端可以相同地对待所有的对象。透明组合模式也是组合模式的标准形式。
透明组合模式的缺点是不够安全，因为叶子对象和容器对象在本质上是有区别的。叶子对象不可能有下一个层次的对象，即不可能包含成员对象，因此为其提供 add（）、remove（） 以及 getChild（） 等方法是没有意义的，这在编译阶段不会出错，但在运行阶段如果调用这些方法可能会出错（如果没有提供相应的错误处理代码）。
@startuml abstract class Component { + operation() + add(Component c) + remove(Component c) + getChild(int i) } class Leaf extends Component { + operation() + add(Component c) + remove(Component c) + getChild(int i) } class Composite extends Component { - List<Component> child + operation() + add(Component c) + remove(Component c) + getChild(int i) } note left of Composite::operation for (Component c : child) { c.operation() } end note class Client{} Client ..> Component Composite *-up-> Component: 组合关系 @enduml
安全组合模式
安全组合模式中，在抽象构件 Component 中没有声明任何用于管理成员对象的方法，而是在 Composite 类中声明并实现这些方法。这种做法是安全的，因为根本不向叶子对象提供这些管理成员对象的方法，对于叶子对象，客户端不可能调用到这些方法。
安全组合模式的缺点是不够透明。因为叶子构件和容器构件具有不同的方法，且容器构件中那些用于管理成员对象的方法没有在抽象构件类中定义，因此客户端不能完全针对抽象编程，必须有区别地对待叶子构件和容器构件。
@startuml abstract class Component { + operation() } class Leaf extends Component { + operation() } class Composite extends Component { - List<Component> child + operation() + add(Component c) + remove(Component c) + getChild(int i) } note left of Composite::operation for (Component c : child) { c.operation() } end note class Client{} Client ..> Component Composite *-up-> Component: 组合关系 @enduml
组合模式总结
组合模式的主要优点如下：
（1）组合模式可以清楚地定义分层次的复杂对象，表示对象的全部或部分层次。它让客户端忽略了层次的差异，方便对整个层次结构进行控制。
（2）客户端可以一致地使用一个组合结构或其中单个对象，不必关心处理的是单个对象还是整个组合结构，简化了客户端代码。
（3）在组合模式中增加新的容器构件和叶子构件都很方便，无须对现有类库进行任何修改，符合开闭原则。
（4）组合模式为树形结构的面向对象实现提供了一种灵活的解决方案。通过叶子对象和容器对象的递归组合，可以形成复杂的树形结构，但对树形结构的控制却非常简单。
组合模式的主要缺点是：
在增加新构件时很难对容器中的构件类型进行限制。有时希望一个容器中只能有某些特定类型的对象，例如在某个文件夹中只能包含文本文件。
使用组合模式时，不能依赖类型系统来施加这些约束，因为它们都来自相同的抽象层。在这种情况下，必须通过在运行时进行类型检查来实现，这个实现过程较为复杂。
适用场景
在以下情况下可以考虑使用组合模式：
（1）在具有整体和部分的层次结构中，希望通过一种方式忽略整体与部分的差异，客户端可以一致性地对待它们。
（2）在一个使用面向对象语言开发的系统中需要处理一个树形结构。
（3）在一个系统中能够分离出叶子对象和容器对象，而且它们的类型不固定，将来需要增加一些新的类型。
🚀 作者简介：作为某云服务提供商的后端开发人员，我将在这里与大家简要分享一些实用的开发小技巧。在我的职业生涯中积累了丰富的经验，希望能通过这个博客与大家交流、学习和成长。技术栈：Java、Golang、PHP、Python、Vue、React
