Design patterns in the test of timeComposite

time to read 9 min | 1642 words

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.

More on this pattern.

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 IVotingUnit
   2: {
   3:     int Weight { get;set; }
   4:     int CandidateId { get;set; }
   5: }
   6:  
   7: public class Voter : IVotingUnit
   8: {
   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 : IVotingUnit
  18: {
  19:     string StateCode { get;set; }    
  20:  
  21:     int Weight { get;set; }
  22:     int CandidateId { get;set; }
  23:  
  24:     public void AddVote(Voter vote){
  25:         // calculate
  26:     }
  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:

  1. (21 Jan 2013) Mediator
  2. (18 Jan 2013) Iterator
  3. (17 Jan 2013) Interpreter
  4. (21 Nov 2012) Command, Redux
  5. (19 Nov 2012) Command
  6. (16 Nov 2012) Chain of responsibility
  7. (15 Nov 2012) Proxy
  8. (14 Nov 2012) Flyweight
  9. (09 Nov 2012) Façade
  10. (07 Nov 2012) Decorator
  11. (05 Nov 2012) Composite
  12. (02 Nov 2012) Bridge
  13. (01 Nov 2012) Adapter
  14. (31 Oct 2012) Singleton
  15. (29 Oct 2012) Prototype
  16. (26 Oct 2012) Factory Method
  17. (25 Oct 2012) Builder
  18. (24 Oct 2012) A modern alternative to Abstract Factory–filtered dependencies
  19. (23 Oct 2012) Abstract Factory