Insoftware engineering, thecomposite pattern is a partitioningdesign pattern. The composite pattern describes a group of objects that are treated the same way as a single instance of the same type of object. The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies. Implementing the composite pattern lets clients treat individual objects and compositions uniformly.[1]
 | This section mayrequirecleanup to meet Wikipedia'squality standards. The specific problem is:The subsection headersshould not redundantly refer back to the article title and should not be phrased as questions. But do these headers even accurately describe the subsection content? If yes, changing them to "Problems solved" and "Solution described" may be appropriate. Please helpimprove this section if you can.(May 2024) (Learn how and when to remove this message) |
The Composite[2]design pattern is one of the twenty-three well-knownGoF design patterns that describe how to solve recurring design problems to design flexible and reusable object-oriented software, that is, objects that are easier to implement, change, test, and reuse.
The Composite pattern solves these problems:
When defining (1)Part objects and (2)Whole objects that act as containers forPart objects, clients must treat them separately, which complicates client code.[3]
Component interface for part (Leaf) objects and whole (Composite) objects.Leaf objects implement theComponent interface directly, andComposite objects forward requests to their child components.This enables clients to work through theComponent interface to treatLeaf andComposite objects uniformly:Leaf objects perform a request directly,andComposite objects forward the request to their child components recursively downwards the tree structure.This makes client classes easier to implement, change, test, and reuse.
See also the UML class and object diagram below.
When dealing with Tree-structured data, programmers often have to discriminate between a leaf-node and a branch. This makes code more complex, and therefore, more error prone. The solution is an interface that allows treating complex and primitive objects uniformly. Inobject-oriented programming, a composite is an object designed as a composition of one-or-more similar objects, all exhibiting similar functionality. This is known as a "has-a" relationship between objects.[4] The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them. The operations you can perform on all the composite objects often have aleast common denominator relationship. For example, if defining a system to portray grouped shapes on a screen, it would be useful to define resizing a group of shapes to have the same effect (in some sense) as resizing a single shape.
Composite should be used when clients ignore the difference between compositions of objects and individual objects.[1] If programmers find that they are using multiple objects in the same way, and often have nearly identical code to handle each of them, then composite is a good choice; it is less complex in this situation to treat primitives and composites as homogeneous.
In the aboveUMLclass diagram, theClient class doesn't refer to theLeaf andComposite classes directly (separately).Instead, theClient refers to the commonComponent interface and can treatLeaf andComposite uniformly.
TheLeaf class has no children and implements theComponent interface directly.
TheComposite class maintains a container of childComponent objects (children) and forwards requeststo thesechildren (for each child in children: child.operation()).
The object collaboration diagram shows the run-time interactions: In this example, theClient object sends a request to the top-levelComposite object (of typeComponent) in the tree structure.The request is forwarded to (performed on) all childComponent objects (Leaf andComposite objects) downwards the tree structure.
There are two design variants for defining and implementing child-related operationslike adding/removing a child component to/from the container (add(child)/remove(child)) and accessing a child component (getChild()):
Component interface. This enables clients to treatLeaf andComposite objects uniformly. Buttype safety is lost because clients can perform child-related operations onLeaf objects.Composite class. Clients must treatLeaf andComposite objects differently. But type safety is gained because clientscannot perform child-related operations onLeaf objects.The GoF authors present a variant of the Composite design pattern that emphasizestransparency overtype safety and discuss the tradeoffs of the two approaches.[1]
The type-safe approach is particularly palatable if the composite structure is fixed post construction: the construction code does not require transparency because it needs to know the types involved in order to construct the composite. If downstream, the code does not need to modify the structure, then the child manipulation operations do not need to be present on theComponent interface.
.svg)
As it is described inDesign Patterns, the pattern also involves including the child-manipulation methods in the main Component interface, not just the Composite subclass. More recent descriptions sometimes omit these methods.[7]
This C++23 implementation is based on the pre C++98 implementation in the book.
importstd;usingstd::runtime_error;usingstd::shared_ptr;usingstd::string;usingstd::unique_ptr;usingstd::vector;// Component object// declares the interface for objects in the composition.classEquipment{private:stringname;doublenetPrice;protected:Equipment()=default;explicitEquipment(conststring&name):name{name},netPrice{0}{}public:// implements default behavior for the interface common to all classes, as appropriate.[[nodiscard]]virtualconststring&getName()constnoexcept{returnname;}virtualvoidsetName(conststring&name)noexcept{this->name=name;}[[nodiscard]]virtualdoublegetNetPrice()constnoexcept{returnnetPrice;}virtualvoidsetNetPrice(doublenetPrice)noexcept{this->netPrice=netPrice;}// declares an interface for accessing and managing its child components.virtualvoidadd(shared_ptr<Equipment>)=0;virtualvoidremove(shared_ptr<Equipment>)=0;virtual~Equipment()=default;};// Composite object// defines behavior for components having children.classCompositeEquipment:publicEquipment{private:// stores child components.usingEquipmentList=vector<shared_ptr<Equipment>>;EquipmentListequipments;protected:CompositeEquipment()=default;explicitCompositeEquipment(conststring&name):Equipment(name),equipments{EquipmentList()}{}public:// implements child-related operations in the Component interface.[[nodiscard]]virtualdoublegetNetPrice()constnoexceptoverride{doubletotal=Equipment::getNetPrice();for(constEquipment&i:equipments){total+=i->getNetPrice();}returntotal;}virtualvoidadd(shared_ptr<Equipment>equipment)override{equipments.push_back(equipment.get());}virtualvoidremove(shared_ptr<Equipment>equipment)override{equipments.remove(equipment.get());}};// Leaf object// represents leaf objects in the composition.classFloppyDisk:publicEquipment{public:explicitFloppyDisk(constString&name):Equipment(name){}// A leaf has no children.voidadd(shared_ptr<Equipment>)override{throwruntime_error("FloppyDisk::add() cannot be called!");}voidremove(shared_ptr<Equipment>)override{throwruntime_error("FloppyDisk::remove() cannot be called!");}};classChassis:publicCompositeEquipment{public:explicitChassis(conststring&name):CompositeEquipment(name){}};intmain(){shared_ptr<FloppyDisk>fd1=std::make_shared<FloppyDisk>("3.5in Floppy");fd1->setNetPrice(19.99);std::println("{}: netPrice = {}",fd1->getName(),fd1->getNetPrice);shared_ptr<FloppyDisk>fd2=std::make_shared<FloppyDisk>("5.25in Floppy");fd2->setNetPrice(29.99);std::println("{}: netPrice = {}",fd2->getName(),fd2->getNetPrice);unique_ptr<Chassis>ch=std::make_unique<Chassis>("PC Chassis");ch->setNetPrice(39.99);ch->add(fd1);ch->add(fd2);std::println("{}: netPrice = {}",ch->getName(),ch->getNetPrice);fd2->add(fd1);}
The program output is
3.5inFloppy:netPrice=19.995.25inFloppy:netPrice=29.99PCChassis:netPrice=89.97terminatecalledafterthrowinganinstanceof'std::runtime_error'what():FloppyDisk::add
{{cite book}}: CS1 maint: multiple names: authors list (link)