I have had this theory for quite a while that the Microsoft community – both inside and outside of the company — doesn’t quite get objects. I think they mostly get it — .Net wouldn’t be what it is if they didn’t — but there are just so many places where things just aren’t quite right that I think that overall, they just don’t quite get it. Now, I’m quite aware of the arrogance implicit in that statement, and I am quite aware that the comments that will follow this article will no doubt question my intellectual capacity, but I’m going to plow ahead anyway. What the heck.
I guess I can’t say for sure why I have this theory; it’s just something that sticks in the back of my mind every time I talk to a Microsoft-type person. I’ve been asked “What do you need an object for?”. They’ve said things like “VB6 is object-oriented” and “Oh, we can do that just as fast without objects”. I’ve heard “You don’t need polymorphism to be object-oriented.” (huh?) My theory is further bolstered as I work with .Net’s Framework Class Library (FCL). (Maybe someday someone can explain to me why so many classes in the FCL are marked sealed. Shoot, why is it even possible to “seal” a class. What the heck is that all about? Who are you to say I can’t improve or enhance your class? If your class somehow needs to be sealed, then I say you have a design problem. Now, despite the fact that most of your OOP languages include the ability to “seal” a class — C#, C++, Smalltalk — I am undaunted in my view. I was hoping that the FCL designers would be the ones to see the light and let me descend from the
string class. Shoot, you can’t swing a dead cat in the FCL without hitting a
sealed class that desperately needs enhancing. Oh well.)
But don’t get me wrong, I’m quite happy to say that, despite some irritating anomalies, the FCL and the rest of the .NET framework have been a big jump forward for MS in terms of their embrace of OOP — but it sure took them long enough.(For the sake of my sanity, I pretend that MFC isn’t really an OOP framework.) They are only about eight years behind Delphi and the VCL. That’s eight years of maturity that isn’t present in the framework. Nevertheless, despite it’s depth and scope, the FCL has a lot of quirks that indicate the folks in Redmond still don’t quite get it.
For instance, why is there a separate
Connection class for each database type in ADO.NET?
OLEDBConnection – one for each database! And you can only connect a
SQLDataAdapter to a
SQLConnection. If ADO.NET were properly designed, like, say, oh, I don’t know, the Borland Data Provider architecture is, then the concept of a “Connection” would be properly abstracted out as a single object that could be interchanged or replaced based on the back-end database. If ADO.NET is supposed to abstract out data access, why aren’t the base classes database independent? Why do I have to use Oracle-specific enumerations with
OracleConnection and SQL Server specific enumerations with SQLServer? I’ll tell you – because ADO.NET isn’t designed properly, that is why. Someone somewhere along the line didn’t quite get it. The interfaces are there for ADO.NET to be programmed against, but the connection classes in ADO.NET fail to take advantage of them properly.
IDBConnection has a
ChangeDatabase method – why can’t I change from an Oracle database to a SQL Server one?
One of the purported great things about the FCL is the extensive use of interfaces, but I keep running into places where an interface sure would be nice, but isn’t there. The example that brought this to mind recently for me was the
System.Web.UI.WebControls.Style class. The
Style class allows you to set properties —
Bold, Underline, Font, etc. — and have those values rendered as part of an ASP.NET control. Well, I was building a control that needed a very specific type of
Style, but the problem I quickly ran into was that I didn’t want all of the properties of the Style class to be part of my new
Style – in this case it was the various Border related properties. The problem, of course, is that the whole ASP.NET component architecture assumes that any and all styles for a control will descend from the
Style class, and if the
Style class has stuff attached to it that you don’t want, then too bad for you.
Wouldn’t it have been better if instead of a
ControlStyle property, which must take a
Style class or one of its descendants, there were an
IStyle interface that knew how to extract a style string, and which let component developers implement it however they like? It might look as simple as this:
type IStyle = interfaces function GetStyleString: string; end;
I’m designing off of the top of my head here, but such an interface would allow me to design any class I like to provide the styles for my components. When it comes time to apply the style, the control could just call the
GetStyleString method and add it to the
style=”whatever” tag of my control and there you have it. It would be up to me to ensure that the string was properly formatted, and I could have any style settings that I please. Instead, in order to get the styles that I want, I have to hack on my own style classes, foregoing the alleged advantages of the FCL.
I’m not saying that the FCL sucks – far from it. But I am saying that I run into situations like this one more than I should. How about this – try reading in a text file, altering the third line of text in the file, and then writing it back out again. In the VCL, that is about four lines of code. In the FCL, it’s a bit tougher. You have to create Readers and Writers and Lord knows what else. What a hassle. Why not a neat object to do that?
More ADO.NET complaints: Why is it so tough to get a data value out of a table? I have to write:
CustomerID := Convert.ToInt32(MyDataset.Tables.Rows['CUSTID']);
when the above code is crying out to be
CustomerID := MyDataset.Tables.Rows
Or, in other words, clearly a field value in a row of a
DataTable should be an object, with methods attached to it to convert it to whatever it needs to be. Like the VCL has been doing since, oh, 1995. OOP code is supposed to reduce the amount of code that you have to write by encapsulating common functionality. That isn’t happening in the above code, that’s for sure. Heck in general, it always seems like I have to write way too much code in my ADO.NET applications.
(And while I’m at it, surely I am not the only one that finds the complete lack of the concept of a current record in ADO.NET a glaring omission. I’m not, am I? Oh, sure, you can get a (unfortunately named)
CurrencyManager from a visual control, but then of course your cursor is coupled with the user interface. That’s plain wrong.)
Now look, I know that the FCL is huge, and it’s a conglomeration of the work of hundreds if not thousands of programmers, and no doubt some of them have a better grasp of OOP principles than others. But there just seems to be enough of these little quirks in it to make me wonder if Microsoft doesn’t quite get it. It’s the little things that always add up. But hey, I suppose that when the FCL is as mature and refined as the VCL, it will probably have worked out this kind of thing. Only about eight more years to go.