.NET Multiple Inheritance

MVP: Object Oriented is Academic, Religion

Tuesday, November 8, 2005 was a day of wonders with the Toronto VS2005 Launch event. This was the first time that I have attended such an event. I burst into laughter when I saw the "rock concert" style complete with giant sparkle-filled balloons for the audience to bat around while AC/DC blasted over the loud speakers completely with accompanying multi-screen video.

There is something seemingly absurd about geeks trying to pretend to be cool. Granted, as I look all around me at various nerd events I notice that many of my programmer contemporaries are turning into metrosexuals. As for me, I will continue to wear electrical diagram print suspenders and glasses held together with scotch tape.

All in all, I was very impressed with the day's events. Microsoft is really good to their developers.

One great resource that they had available was an array of MVP's that were ready, willing, and able to answer all of your development questions. Adorned in matching tight-knit cotton shirts with the word "Expert" written down one sleeve, I was sure they could satisfy even my deepest burning curiosities. This time, I decided to ask about the age-old question of persisting class structures into a relational database.

The Example

Suppose we have a ContactInformation class. This class contains an Address collection, a Telephone collection, and an Email collection. Thus, each ContactInformation class can have 0-through-many addresses, telephone numbers, and email addresses. Each Address has an AddressType (such as Shipping, Billing, Mailing, etc.), each Telephone has a TelephoneType, and each Email has an EmailType.

Persisting this to a relational database makes sense. You create an Address table, a Telephone table, and an Email table. Plus you can either use enumerated values or create tables for AddressType, TelephoneType, and EmailType. The programmer may wish to create a ContactInformation class in case there are some extra details contained therein.

The problem comes when we wish to have a Vendor class, Customer class, and Employee class - each having ContactInformation as a member. Obviously, we must create Vendor, Customer, and Employee tables but how do we related them to the ContactInformation table?

The Microsoft Expert Answer

For an expert (and leader of a SQL Server user group), I certainly wasn't the least bit impressed. I started to ask my question about mapping objected oriented classes into SQL Server when he interrupted and gave me a 5-minute lecture on why "object oriented" is a religion.

Instead of letting me ask my question (which wasn't on the merits of OOP) and giving me an answer (I was hoping to learn more about O/R Mappers), he decided to go on a tirade about performance problems and why he doesn't use object oriented programming for anything. He said that the only benefit to object oriented programming is code maintainability and other than that, it is useless. There was something in there about it being solely an academic pursuit that unfortunately some people have tried to apply to the real world.

Too bad Microsoft disagrees with that assessment. VSTS includes a pretty sweet class designer, System.Drawing is a set of class wrappers over GDI, and WinFX takes away ugly API's and replaces them with class wrappers. Everything in the Microsoft world is heading OO – thank goodness.

Now, I've heard the Multiple Inheritance debate referred to as a religion but I thought that OOP in general was long past being an obscure prophesy of Bjarne Stroustrup and was now accepted as the de facto way to get most things done.

I guess when it comes to the word "Expert", the old adage holds true: X is the unknown quality and a spurt is the force behind a drip.

Happy Coding
- Shaun