We know that some design patterns are found so useful that they become features of the language itself.

For instance, the interface IEnumerator which is implemented by Array object. This helps in separating the iterator from the collection object. The internal representation of the object is encapsulated.

The pattern: Iterator Pattern

I have just come across another interface IStructuralComparable(msdn). This is used to compare the structure of two collection types using StructuralComparisons(msdn) class.

The intent of this interface seems to be thus:

My understanding is that it's used for collection like types, and encapsulates the structural part of the comparison, but leaves the comparison of the elements to a comparer passed in by the user. (link) (Got from the comments section of the question)

Is this an implementation of any familiar design pattern? If yes, which pattern is it?

2 Answers 2


I don't believe there is a commonly used pattern to describe this. I would think of it as "broken composite pattern", because it seems to me that they nearly use the composite pattern and if they actually used it then it would work better.

As it was implemented, you compare collections using IStructuralComparable, which requires you to pass in an IComparer to use in comparing individual elements from the two structures. Since IComparer and IStructuralComparable are two different interfaces, you have problems if the elements of the IStructuralComparable are themselves collections, which now get compared with IComparer. But if you prefered IStructuralComparable to IComparer at the top level, why don't you prefer it now?

If the composite pattern had been used the interior nodes (collections) would have the same interface as the leaf nodes (non-collections) and would handle recursive substructures more cleanly. (I've actually implemented structural comparisons exactly this way).

So, to me at least the problem looks like a composite pattern, but the solution looks like "near the composite pattern but really not as good". This must have been done for historical reasons, since lots the IComparer interface has been implemented many times in and out of the .NET framework, and a composite interface wouldn't match it.

  • Thanks to your explanation, I read up on composite pattern and it does seem like a right fit. The usage of two interfaces seemed to be an overhead to me. Almost like an unnecessary complexity... Hence this question. I did not understand historical reasons you have mentioned here, which led them to use near composite solution... Commented Mar 18, 2013 at 3:18
  • The bounty would get awarded to the other q since it has more votes. Hence I am giving this one the bounty. Would like to discuss on this one though... Commented Mar 18, 2013 at 3:19

I'd say this would be a strategy pattern. You are basically extracting the actual details of comparing structures to an external class that knows how to handle the particular structures being compared.

For example, An implementation of IStructureComparable for a list would only need to scan a flat list whereas an implementation for a binary tree would also need to take into account the branching of the tree (e.g. it would perhaps use the depth of the trees as a way to order them.)

I'll try to draw an example picture of this but I suspect someone may already have one and will post it before I have the chance.

  • Thanks for the answer. Can you show an illustration? And, what does "go on a limb" mean? I am sorry I am not familiar with that usage. Commented Mar 11, 2013 at 12:15
  • It means to say something other people might not agree with. It's "risky" to say it like going out on a limb of a tree is risky. At least, that's how I use it. Commented Mar 11, 2013 at 16:16
  • A picture would be awesome! I hope you find the time to draw it and post it. As you can see, no one other than you has even attempted an answer and you have got two up votes. :) Commented Mar 13, 2013 at 10:20
  • 1
    Wouldn't any interface whatsoever be an example of the strategy pattern, in this sense? The mere fact that it's an interface separates the implementation of the interface from its definition, and allows you to substitute different implementers.
    – psr
    Commented Mar 15, 2013 at 18:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.