Today I’m going to wax a little bit philosophical regarding the philosophy of object oriented programming. For those of us who work in more than just SQL, most of the languages popular today conform to some form of object oriented capabilities. Object oriented syntax has been designed to allow change to occur to programs over time, which most valuable software does. Life doesn’t remain static, and the requirements for how software behaves is constantly improving or changing.
What brings me to this topic are the comments from yesterday’s editorial on Extension Methods. The comments are based on two different strategies of object oriented design methods, that generally work together. When it comes to extension methods, I think, at least philosophically, they are at odds. Let me explain the principles first.
The SOLID acronym for Software Development Techniques, made popular by Robert C Martin in the early 2000’s, defines the Principle, “O”, meaning Open/Closed. This principle states that an object is Open for extension, and Closed for Modification. In short, a class may not be modified in its current version to have a new public interface. You can change the internal workings of a published class, but, in order to add new methods or properties, you have a new, different version of the class.
Object oriented techniques teach us the concept of encapsulation. Encapsulation, in my simple definition, means that all of the public behaviors and properties of a class are maintained within a class.
I demonstrated an extension to the string class yesterday, making it appear to have a ToBumpy() methods, note implemented by the string class. My extension code, not in the string class code, makes any string look as if it has a ToBumpy() method, just like other methods that ship with the class itself, such as ToUpper(), ToLower(), Contains(), etc. Not having looked at the DotNet source code, it may be that the string class itself doesn’t contain those methods either; they may be extension method in the source as well.
The philosophical argument is this. The Open/Closed principle is followed with the use of Extension Methods, at least from a source perspective. I have not modified the source code of the string class. However, I have modified the apparent public interface of the string class from a syntactical perspective because I can use my new .ToBumpy() method without creating a new version of the string class. If you looked at code in my program using Dot Net 4.5.1, you would be able to see me using an extension. However, if you tried to use the string class and called ToBumpy() without having my extension, then the compiler will throw an error. It’s magic! And there are no clues to you, without my source, to know how this magic was created.
If we followed the object oriented principle of encapsulation, then you would have a completely new class that extends the string class through composition or inheritance. If a developer wanted to use the string class that has the new method ToBumpy() they would use the new version of the string class. The public interface to the class is completely encapsulated, and consumers of this new capability know where it came from. We experience this constantly with new versions of Dot Net objects where they take on new behaviors from one version of the framework to the next.
In the Dot Net Library this concept of encapsulation is implemented through their packaging. Perhaps it really doesn’t matter if an objects methods are implemented through an extension or through implemention within the class itself. The Dot Net System.String class itself is also implemented through extension methods. What makes it appear as encapsulated and closed is the version of the Dot Net library itself. Over time, new extensions may be added to the string class via extensions, but they only appear in the version of the framework you are implementing. This results in a virtual encapsulation.
In short, an implementation, following both Encapsulation, and Open/Closed, would be to have a new string class for your application, based on the existing string class, with a new interface based on a series of Extension methods. Is this practical? It probably does not make sense in the code we write today, unless we are writing a lot of framework like libraries used by a lot of different systems.
This is probably an area where a lot of you, a lot smarter than me, have a better understanding, and can provide more clarity by leaving a comment or references to other sources. Or, if you prefer, you can still drop me an Email at btaylor@sswug.org.
Next time we’ll return to more things SQL
Cheers,
Ben