Skip to content

Do not expose the implementation  

One of the things we are taught in object oriented design is that the outside world should not be exposed to the complexities of how our object achieves their goals. Other developers are busy, don’t care and really don’t need to know. It is a sound idea and goes hand-in-hand with ease of use.

Televisions used to expose the implementation with a single tuning knob that had to be adjusted every time you wanted to watch another broadcast. With time engineers replaced this with an interface that hid the implementation, specifically the concept of channels where each one could be individually tuned and switched between on a whim. Implementation no longer exposed.

Technology brings complexity but only good technology makes it look simple.

One thing that has always annoyed me here in the UK is an every day object that doesn’t hide the implementation.


That’s right taps. I don’t care that water is delivered to my sink through two pipes, hot and cold. I don’t ever want scolding hot water and just as rarely require it uncomfortably cold. Most of the time I want the same warm temperature as last time.

Sure, there are taps that do this and indeed in many other countries it seems to be the norm but here in the UK builders keep putting in separate hot and cold taps in. Until either the public wise up or I actually buy my own house and can replace this sort of annoyance I’m stuck with it.

While taps have annoyed me for a while it was .NET 2.0 that reminded me of the whole issue again and a brief discussion with GrinGod that caused a similarly titled post of his own. Specifically the Hashtable class is now called Dictionary when used with generics which once again prevents the implementation details leaking out into your code. Important in this case because most people wanted a fast dictionary and didn’t care too much how it was achieved and also because that algorithm changed in .NET 2.0 and they realised they shouldn’t have specified the implementation in the class name…

If you previously generated strongly-typed collections in .NET 1.1 using the many tools around such as CodeSmith then you might be interested in this little tip. If you have a strongly typed class such as:

public class MyObjectCollection : Hashtable {
  public MyObject this[object key] {
    get { return (MyObject) pHashtable[key]; }
    set { pHashtable[key] = value; }

Then instead of replacing every single instance of

MyObjectCollection theseObjects = new MyObjectCollection();


Dictionary<object, MyObject> theseObjects = new Dictionary<object, MyObject>;

you can in fact simple change MyObjectCollection and leave the rest of your code alone:

public class MyObjectCollection : Dictionary<object, MyObject> { }

Which will also mean that you can still have the additional properties and functions on MyObjectCollection if you had them previously. It’s rather obvious you can do this but many samples I’ve seen just create raw generic collections everywhere rather than inheriting from them.


Respond to this