Design patterns in the test of timeComposite
The composite pattern describes that a group of objects are to be treated in the same way as a single instance of an 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.
This post is supposed to come on the 1st of Nov or there about, which means that I’m going to do a small divergence into politics now. Here is an example of how the upcoming presidential elections in the states.
1: public interface IVotingUnit2: {
3: int Weight { get;set; }4: int CandidateId { get;set; }5: }
6:
7: public class Voter : IVotingUnit8: {
9: [Obsolete("Racist")]10: string Id { get;set; }11:
12: int Weight { get;set; }13:
14: int CandidateId { get;set; }15: }
16:
17: public class WinnerTakesAllState : IVotingUnit18: {
19: string StateCode { get;set; }20:
21: int Weight { get;set; }22: int CandidateId { get;set; }23:
24: public void AddVote(Voter vote){25: // calculate26: }
27: }
Yes, this is probably a bad example of this, but I find it hilarious. The basic idea is that you can have an object that represent many other objects, but show the same external interface.
Composites are usually used for the more CS style of programming. Composites are very common in tree structures such as compiler AST or DOM. But beyond that, I can’t easily recall any real world usage of them in my applications. There are usually better alternatives, and you have to remember that when you speak about enterprise applications, loading / storing the data is just as important. And trying to implement the composite pattern under those circumstances will lead to a world of hurt.
Recommendation: If your entire dataset can easily fit in memory, and it make sense, go ahead. Most of the time, you probably should stay away.
More posts in "Design patterns in the test of time" series:
- (21 Jan 2013) Mediator
- (18 Jan 2013) Iterator
- (17 Jan 2013) Interpreter
- (21 Nov 2012) Command, Redux
- (19 Nov 2012) Command
- (16 Nov 2012) Chain of responsibility
- (15 Nov 2012) Proxy
- (14 Nov 2012) Flyweight
- (09 Nov 2012) Façade
- (07 Nov 2012) Decorator
- (05 Nov 2012) Composite
- (02 Nov 2012) Bridge
- (01 Nov 2012) Adapter
- (31 Oct 2012) Singleton
- (29 Oct 2012) Prototype
- (26 Oct 2012) Factory Method
- (25 Oct 2012) Builder
- (24 Oct 2012) A modern alternative to Abstract Factory–filtered dependencies
- (23 Oct 2012) Abstract Factory
Comments
I don't think that properties-only interface are a good example for composite pattern.
I used this pattern when I had an interface "ISaver" with "Save(object item)" and I want to save in many place, so I created a composite that contains many "ISaver".
Hi, abstracting a level I think any kind of recursive data structure is a good composite candidate. Not only trees but tail recursive structures (lists, list comprehension implementations). It's quite lucky that
class Pretty<T>:T{ ... }
is not allowed. [ Though: class Base<T>:{ ...} with Node:Base<Node> is a workaround ]
Cheers
I see this one in Rules engines quite a bit. Something like interface IRule { void Validate(); }. A composite rule is both a collection of rules and a rule itself.
The infamous specification pattern for expression trees is a good example of that.
[Obsolete("Racist")] string Id { get;set; }
you got a wicked sense of humor there :)
Loving this series, but I'm lost on this post. I love the composite pattern and use it to implement business rules all over the place. The idea of clients having a single dependency on an IBusinessRule as opposed to an array of IBusinessRules makes the object model cleaner in my opinion. Would you / anyone disagree? Again loving this series, keep it going!
I use this pattern (or its spirit) for web service request/response objects
I use this all the time in UI programming. E.g. a renderable's render() method calls all of its children's render() methods before returning, in UI hierarchies. The lowest-level renderables are the basic widgets (buttons etc.); middle-level ones are aggregations thereof (toolbars, sections of the page, etc.); and the highest-level renderable is the app itself.
Comment preview