Anyone that has worked with me knows that I am anti-datasets and pro-creating
custom business object/entities. Microsoft has spent some time making their
controls, like the _DataGrid_, work very cohesively with the _System.Data_
classes (primarily _DataTables_ and _DataSets_). To take advantage of the same
functionality with my custom collections I have to implement the
_IBindingList_. The _IBindingList_ is the interface that is at the root of the
_DataTable_ and is what the _DataGrid_ and other controls use to effectively
bind data to the UI.
list. I had created a class called _ObjectComparer_ and it implements the
interface _IComparer._ This is the interface the sort method on the
_ArrayList_ accepts as an argument. I created this along time ago but recently
a co-worker brought to my attention another fellow Milwaukee developer that
[implemented something very similar ][1] on his blog. He did a decent job except that in his example the comparer only compares on
properties of objects that are of type _int, double, string, and DateTime_ and
has a method to handle each specific type. The advantage of using the comparer
I provide below is that it doesn't care or need to know about the type of the
property on the object you are comparing against, as long as the type
implements _ICompareable_ interface (The _IComparer_ counterpart). Many types
in the .Net framework already implement this interface (including the _int,
double, string, and DateTime_). Plus if you create a custom class, you can
also extend your class with it's own implementation of how to compare itself
against another object of the same type by implementing the _IComparable_
interface. This really demonstrates the power of interfaces because my
_ObjectComparer_ code never needs to change to handle any specific types
because it only deals with the _IComparable_ interface. Where as with the
other developers sample, everytime you wish to be able to compare on another
type, you have to edit his object comparer. Below is my implementation of a
_ObjectComparer._ **MultiKey Comparison Sorting** I first saw the other developer's custom object IComparer last week when he
[posted ][2] on how he changed his original implementation to now handle
multiple properties to do the comparisons on to sort. My co-worker suggested
that we may want to implement the same functionality. When I saw what the
author had changed the inner workings of his class by modifying it, alarms
went off. This is a big violation of the [open-closed ][3]object oriented
principle. Basically the open-closed principle means the "Objects should be
open for extension and closed to modification." By extension, the principle
means either by preferably using inheritance or composition. Modification
means going into "already working" classes and changing implementation -
potentially making your class unstable. So instead of modifying my
_ObjectComparer_ I decided to create a new class called the
_MultiKeyObjectComparer_ which internally (composition) uses several instances
of the _ObjectComparer_ and its already stable working functionality. In the
defense of the original author, some may argue that his API (public interface)
would be friendlier in the sense that you could continue to use his object
comparer and another developer would see the new functionality using
intellisense because of the additional constructors and methods, where as with
my design the developer would have to be aware of the new
_MultiKeyObjectComparer_ that I created to benefit from it. (On a side point, after implementing this, the next morning another altogether
separate co-worker requested the functionality for a UI he was doing,
completely unaware that I had already been looking into this…weird
coincidence). [1]: http://www.damonpayne.com/BlogFull.aspx?Guid=b8405b9d-8f6d-
4d53-8e83-8764b2027fb6 [2]: http://www.damonpayne.com/Blog.aspx#0e692666-10f9-4ecc-87df-
bc14ed5784d1 [3]: http://c2.com/cgi/wiki?OpenClosedPrinciple
Leave a comment...