Talk:Composite pattern

message: This has to be one of the most unprofessional UML diagrams I've seen for one of the most common patterns. As per the user above's complaint about the PERL, Java would be a better language, but in interest of neutrality I'd suggest doing the whole thing in a UML sequence diagram to maintain language neutrality. And can't someone with the GoF CD just quote and paste portions outlining the GoF example -- it's much better.
I added two links to discussions on the pattern.
What is needed is a realistic example. For instance an example where the pattern is not used and then how refactoring it leads to the pattern. I have found several moderetaly convincing examples on the web but no really convincing one.
Concerning language neutrality: UML sequence language is no more neutral than C++ or Java.
MikalZiane 12:44, 26 June 2006 (UTC)
thread_title: comment

message: I changed the c++ example the old one was awful:  horribly indented, compiled with many warnings, segfaulted, obfuscated, etc.  This one I believe is much better and doesn't have any warnings under: g++ -o test test.cpp -Wall -pedantic -ansi.  Let me know what you think--Michael miceli (talk) 02:43, 30 March 2008 (UTC)
thread_title:  Composite c++ example 

message: Some may argue that the diagram above demonstrates a relationship of aggregation, not yet of composite, as the dependent relationship between leafs and composite is missing from the diagram. that is to say, Composite and Aggregation differ at that the leafs should have the same lifetime as its composite in a relationship of composite. In other words, the leaf lives and dies as the composite lives and dies. Especially when the composite got destroyed, everything in the composite should be destroyed as well.
When only the references (class, reference typed, objects themselves stored random on heap when references stored on stack, first in first out, requiring an overhead of memory manager of CLR and garbage collector to dispose the orphaned objects without a valid reference, out of our reach, totally depends on CLR who only concerns memory, not resources) are added to the composite, the pointing objects will not be destroyed when the composite is destroyed;
however, if the objects themselves (structs, value typed, stored in order on stack, first in last out) are added to the composite, they will be destroyed as the composited is destroyed
 — Preceding unsigned comment added by Firetinder (talk • contribs) 14:01, 30 September 2011 (UTC)
thread_title: Open Discussion: Composite Vs. Aggregation

message: Hello fellow Wikipedians,
I have just modified one external link on Composite pattern. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20090531030742/http://www.theresearchkitchen.com/blog/archives/57 to http://www.theresearchkitchen.com/blog/archives/57
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 19:31, 11 August 2017 (UTC)
thread_title:  External links modified 

message: I have shared the following UML diagrams I have published on Design Patterns Open Online Learning. Your comments are welcomed.
In the above UML class diagram, the Client class doesn't refer to the Leaf and Composite classes directly (separately).
Instead, the Client refers to the common Component interface for performing an operation (operation()).
The Leaf class has no children and implements an operation directly.
The Composite class maintains a container of child
components (children) and implements an operation by forwarding
it to these children (for each child in children: child.operation()).
Additionally, Composite implements the child-management operations
(add(child)).
The object collaboration diagram 
shows the run-time interactions: In this sample scenario,
a Client object sends a request to the top-level 
Composite object (of type Component) in the  hierarchy (tree structure).
The request is forwarded to all child components 
(Leaf and Composite objects of type Component) recursively, that is,
the request is performed on all objects downwards the tree structure.
Vanderjoe (talk) 23:36, 31 August 2017 (UTC)
thread_title:  UML class and object diagram for the Composite design pattern. 

message: In the Structure section, two variants are described with the implication that neither is more prominent or desirable. But later it says "The Composite design pattern emphasizes uniformity over type safety," giving another diagram very similar to the "design for type safety variant." How can we clean this up?
One more possibility for improvement, it's not clear what the context is for the code under "Simple example". It seems to be a continuation of the C# example, maybe in the same source file.
Faught (talk) 14:31, 26 November 2018 (UTC)
thread_title:  Describing the variants