Ayende @ Rahien

Refunds available at head office

Design patterns in the test of time: Composite

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.

Comments

bourgarel remi
11/05/2012 01:22 PM by
bourgarel remi

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".

mjanoska
11/05/2012 01:23 PM by
mjanoska

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{ ... }

is not allowed. [ Though: class Base:{ ...} with Node:Base is a workaround ]

Cheers

Jarrett
11/05/2012 02:07 PM by
Jarrett

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.

Dmitry
11/05/2012 02:09 PM by
Dmitry

The infamous specification pattern for expression trees is a good example of that.

João P. Bragança
11/05/2012 03:36 PM by
João P. Bragança

[Obsolete("Racist")] string Id { get;set; }

you got a wicked sense of humor there :)

Nick
11/05/2012 05:20 PM by
Nick

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!

Pete Weissbrod
11/05/2012 11:13 PM by
Pete Weissbrod

I use this pattern (or its spirit) for web service request/response objects

Domenic Denicola
11/06/2012 05:10 AM by
Domenic Denicola

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.

Comments have been closed on this topic.