We know that some design patterns are found so useful that they become features

Question

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?

Explanation / Answer

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.

Related Questions

Navigate

• Browse (All)
• Browse W
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.