合肥市建设信息中心网站wordpress无法安装
https://en.wikipedia.org/wiki/Composite_pattern
组合模式是一种结构型设计模式。组合模式描述了一组对象，这些对象被视为同一类型对象的单个实例。组合的目的是将对象“组合「compose」”成树结构，以表示部分-整体层次结构。实现组合模式可以让客户端统一处理单个对象和组合。
解决的问题
表示 part-whole 层次结构，以便客户端可以统一处理部分和整体对象。
将 part-whole 层次表示为树结构。
在定义（1）Part对象和（2）充当Part对象容器的Whole对象时，客户端必须单独处理它们，这会使客户端代码复杂化。
解决方案
为 part（Leaf）对象和 whole（Composite）对象定义统一的Component接口。
单个Leaf对象直接实现Component接口，Composite对象将请求转发到其子组件。
这使客户端能够通过Component接口统一处理Leaf和Composite对象：Leaf对象直接执行请求，Composite对象沿树结构向下递归地将请求转发给其子组件。这使得客户端类更容易实现、更改、测试和重用。
另请参见下面的UML类和对象图「object diagram」。
UML class and object diagram
在上面的UML类图中，Client类没有直接（separately）引用Leaf和Composite类。相反，客户端引用公共 Component 接口，可以统一处理Leaf和Composite。
Leaf类没有子类，直接实现Component接口。
Composite类维护一个Component子对象（children）的容器，并将请求转发给这些子对象（对于children中的每个子对象：child.operation（））。
对象协作图「object collaboration diagram」显示了运行时交互：在这个例子中，Client对象向树结构中的顶级Composite对象（Component类型）发送请求。请求被转发到树结构下方的所有子组件对象（Leaf 和 Composite对象）。
Defining Child-Related Operations
有两种设计变体「variants」用于定义和实现与子组件相关的操作「child-related operations」，例如向容器中添加/从容器中删除子组件(add（child)/remove(child)）和访问子组件（getChild()）：
1，一致性设计「Design for uniformity」：在Component接口中定义与child相关的操作。这使得客户端可以统一地处理Leaf和Composite对象。但是类型安全性丢失了，因为客户端可以对Leaf对象执行与child对象相关的操作。
2，为类型安全而设计「Design for type safety:」：与child相关的操作仅在Composite类中定义。客户端必须区别对待Leaf和Composite对象。但是类型安全是可以获得的，因为客户端不能在Leaf对象上执行与子对象相关的操作。
组合设计模式强调一致性而不是类型安全性。
UML class diagram
Component
是所有组件的抽象，包括Composite 组件
声明组合中「composition」对象的接口
（可选）定义了一个用于访问递归结构中组件父级的接口，并在适当的情况下实现它
Leaf
表示组合中「composition」的叶子对象
实现所有Component方法
Composite
表示组合组件（具有子组件的组件）
实现操纵children的方法
实现所有Component方法，通常是通过将它们委托给其 children
Variation
该模式还涉及在主 Component 接口中包含 child-manipulation 方法，而不仅仅是Composite子类。最近的描述有时会省略这些方法。
举个例子
假设我们要设计一个文件系统，文件系统中有文件和文件夹：
-
文件是叶子节点，没有子节点。
-
文件夹是容器节点，可以包含文件或其他文件夹。
使用组合模式：
-
Component：定义一个抽象类
FileSystemComponent，包含一个方法display()。 -
Leaf：
File类继承FileSystemComponent，实现display()方法。 -
Composite：
Folder类继承FileSystemComponent，包含一个子节点列表，并实现display()方法（递归显示所有子节点）。
客户端可以统一调用 display() 方法，无论是文件还是文件夹。
优点
-
简化客户端代码：客户端无需区分叶子节点和容器节点，统一处理。
-
扩展性强：可以轻松添加新的组件类型。
-
符合开闭原则：对扩展开放，对修改关闭。
缺点
-
设计复杂：需要定义统一的接口，可能增加系统的复杂性。
-
类型检查问题：在某些情况下，客户端可能需要检查对象的具体类型。
适用场景
-
需要表示“部分-整体”的层次结构。
-
希望客户端以统一的方式处理单个对象和组合对象。
-
需要动态地添加或删除组件。
from abc import ABC, abstractmethod# Component
class FileSystemComponent(ABC):@abstractmethoddef display(self):pass# Leaf
class File(FileSystemComponent):def __init__(self, name):self.name = namedef display(self):print(f"File: {self.name}")# Composite
class Folder(FileSystemComponent):def __init__(self, name):self.name = nameself.children = []def add(self, component):self.children.append(component)def remove(self, component):self.children.remove(component)def display(self):print(f"Folder: {self.name}")for child in self.children:child.display()# Client
if __name__ == "__main__":file1 = File("file1.txt")file2 = File("file2.txt")folder1 = Folder("Folder1")folder1.add(file1)folder1.add(file2)folder2 = Folder("Folder2")folder2.add(File("file3.txt"))folder2.add(folder1)folder2.display()