How does the Composite design pattern work in theory?

Question

How does this pattern work in theory? What kind of problem does it solve and what utilities does it bring or something?

Answer 1

It is one of these patterns for very specific problems and that if used where it should not only creates complexity without giving real benefit. Most of the time it is possible to do something simpler. One of the difficulties of understanding is because it is always shown with a model of objects that in practice should not be formed like that in good code. All the examples I’ve seen are bad and inherit where they shouldn’t, so I even question its validity, not because I guarantee it’s invalid, but because it’s poorly defined in the easy-to-find material (one copy of the other just to generate content without concern to explain more adequately), it may be that all are wrong because one misunderstood and all were in the wave. This is one of the reasons I don’t care Patterns design, I have a problem and look for a good solution to solve, many of them are obvious when the person knows how to program.

His goal is to create a hierarchy of objects with similar characteristics. What gives this similarity is an interface that happens to be considered as a component of the object. Think of it as a specialized data list where all elements have the implementation needed to do something determined by a type (an interface). It would be something like a List<Printable>, but it’s not just a list, you can create an object tree like this, and this list has the resources (methods) to handle this capability (in the example is able to print something) directly by it and does not need to call the hierarchy element directly, and there is still a way to add or remove objects in this hierarchy as in any data collection.

Some people even criticize why it would be incomplete and does not provide parts that would be interesting throughout the data collection in this way. Some say that the mechanisms that manage the entry and removal of a new object in the hierarchy must be in this interface defined to group the objects. I think this violates the I’s SOLID (not that I think violating any principle is forbidden, but the people who create these things don’t like violating).

It’s a good abstraction, but there’s nothing very special about it, and maybe because it’s a little flawed, it’s used a little, at least clearly. I even believe that people do similar things where they need to and don’t even realize it, which in a way may be the best design standard, the one you use without realizing it. Seems to be (not that it is) more for a data structure than a DP.

Note that with the evolution of some languages I don’t even know if this should be done this way.