.NET Multiple Inheritance

Toronto Code Camp 2007 an Overwhelming Success

shayward — Tue, 03 Apr 2007 17:25:00 GMT

It was Toronto Code Camp time once again and this year was a wonderful follow-up to the first Toronto Code Camp held last year. Special thanks to MVP Chris Dufour for organizing this fantastic event as well as giving the best talk of the day, which was on Windows Communication Foundation.

It’s always a good combination between well-dressed nerds and those of us that continue to perpetuate various geek-culture stereotypes. I, for one, go with the glasses, plaid shirt, tan pants, and suspenders. I love the code camps because they are one of the rare times that I realize that I am not alone in my sense of fashion and my love of Doctor Who.

This year I spoke on Reflection – one of my favorite aspects of .NET (and aptly stolen from Java). Reflection allows you to discover an object’s type at runtime if you don’t already know it and query the structure of the classes. You can also invoke methods, change properties, and play with events all dynamically at runtime.

It’s great for creating a plug-in architecture as well as creating a generic business object validator or a generic data access layer. It’s also handy for hacking a DLL if you don’t have the source code.

Reflection is a fairly advanced topic and assumes good foundational knowledge of object oriented programming. My big concern was being able to communicate this topic effectively so as to open up everyone’s understanding in the course of an hour. Based on the comments I received, the mission was accomplished.

One thing is for certain: it is both humbling and encouraging that I have managed to travel this far in the geek’s journey to be able to impart knowledge and understanding to others. But I’m still young in the journey and have a lot of recursions to go before I either return 0 or hit a stack overflow exception.

Happy Coding
- Shaun

MVP: Object/Relational Hybrid Database provides More Power, Higher Data Integrity

shayward — Fri, 04 Aug 2006 15:25:00 GMT

In this month’s Architectural Journal there was a fantastic article by SQL Server MVP Paul Nielsen entitled The Nordic Object/Relational Database Design. This design basically adds OODBMS features on top of a RDBMS, creating a hybrid with the advantages of both while simultaneously removing (most of) the disadvantages of both.

It's a brilliant piece, incredibly simple, and a worth-while read for anyone that loves object-oriented and finds O/R Mappers overly-cumbersome. I have to wonder if, by day, Mr. Nielsen is really mild-mannered reporter Clark Kent. I can hardly wait for the book, due out this December. I've already asked my wife to get it for me for Christmas. (Yes, I do realize that I'm a total geek with no sense of real fun)

I also find Mr. Nielsen's views a refreshing contrast to the last SQL Server MVP with whom I spoke.

Multiple Inheritance: Microsoft Should Introduce Better Interface Implementation

shayward — Fri, 14 Jul 2006 14:35:00 GMT

A couple of days ago I posted on Implementation Classes as a viable solution for most Multiple Inheritance benefits without actually having Multiple Inheritance. I feel very strongly that Microsoft should make Implementation Classes or something equivalent a direct part of the C# 4.0 and VB 10 languages (given that it won’t happen in Orcas).

I think this would be one of the most important language developments that could ever happen in .NET.

It would eliminate all of the annoying copy-and-paste code involved in implementing multiple interfaces and pointing them back to true objects to gain most of the benefits of Multiple Inheritance. Plus it would settle most of the calls for true MI and still satisfies the anti-multiple-inheritance camp.

Best of all, Microsoft can easily (and I stress easily) do this with compiler wizardry given that it really isn’t a huge amount of work (just very tedious) to do it manually. If Microsoft can come up with compiler solutions for Generics, LINQ, Extension Methods, and Dynamic Typing then there is no reason to make major changes to the CLR for Implementation Classes.

So what could it look like syntactically? There are a few different thoughts on this and Anders Hejlsberg would certainly have something to say about this... at least for the C# camp. Let's take a look:

Implementation Classes
This is my take on it, although most of it has been liberally borrowed from other sources, to the authors of which I am eternally grateful.

The trick is to create one or more special “Implementation Classes” that each provides strong implementation for one or more of the desired interfaces. Suppose we had the following interface:

    public interface IEditableObject
    {
        void BeginEdit();
        void CancelEdit();
        void EndEdit();
    }

That’s not so hard to imagine because it does exist in the .NET Framework. If we want to use this interface in the exact same way with the exact same code for multiple classes then we would start by creating an “Implementation Class called EditableObject:

public implementation class EditableObject : IEditableObject
{

      public EditableObject ()
      {
         // ... Constructor Could Contain Parameters
      }

      // ... Some Private Member Variables
      //     (Probably a Key/Object Pair)
      //     To Hold The Values Of Different Properties and Fields
      //     Captured During BeginEdit()

      void System.ComponentModel.IEditableObject.BeginEdit()
      {
         // ... Use Reflection To Store Current Values
      }

      void System.ComponentModel.IEditableObject.CancelEdit()
      {
         // ... Use Reflection To Write Back Values
         //     Captured in BeginEdit()
      }

      void System.ComponentModel.IEditableObject.EndEdit()
      {
         // ... Clear Values Captured in BeginEdit()
      }

}

Notice the implementation keyword. First of all, it would prevent the class from being instantiated directly, similar to the way that abstract does:

// The following line would not compile
EditableObject e = new EditableObject();

More importantly, this would tell the compiler that this is an implementation class. When another class “inherits” it, the inheritance wouldn’t be your standard, garden-variety of inheritance. Consider the Product class:

   public class Product : EditableObject
   {

   }

When this compiles, it would not compile to a standard inheritance relationship. Instead, the MSIL produced would be equivalent to if we had written the following:

   public class Product : System.ComponentModel.IEditableObject
   {

      EditableObject _EditableObjectImplementation;

      void System.ComponentModel.IEditableObject.BeginEdit()
      {
         _EditableObjectImplementation.BeginEdit();
      }

      void System.ComponentModel.IEditableObject.CancelEdit()
      {
         _EditableObjectImplementation.CancelEdit();
      }

      void System.ComponentModel.IEditableObject.EndEdit()
      {
         _EditableObjectImplementation.EndEdit();
      }

}

Here I have chosen to use explicit interface implementation. That makes a great deal of sense because typically we would pass a Product object to a method expecting a reference to an IEditableObject interface. We wouldn’t usually want to directly call BeginEdit() from a Project object. For implicit interface implementation, I would simply add an implicit keyword:

   public class Product : EditableObject implicit
   {

   }

This would produce MSIL equivalent to:

   public class Product : System.ComponentModel.IEditableObject
   {

      EditableObject _EditableObjectImplementation;

      public void BeginEdit()
      {
         _EditableObjectImplementation.BeginEdit();
      }

      public void CancelEdit()
      {
         _EditableObjectImplementation.CancelEdit();
      }

      public void EndEdit()
      {
         _EditableObjectImplementation.EndEdit();
      }

}

Obviously _ EditableObjectImplementation needs to be instantiated in the constructor so that some poor consumer of a Product object doesn’t get the dreaded null reference exception. It could be handed in a similar way to the call to base() in C# and done by using the Implementation Class’ name:

   public Product()
      : base(), EditableObject()
   {

}

This would compile to MSIL as if we had written:

EditableObject e = new EditableObject();

As previously stated, we wouldn’t be able to actually make the above call ourselves. If more than one implementation classes where consumed by the Product class then they should appear in the order of instantiation:

   public Product()
      : base(), EditableObject(), Clonable()
   {

}

Parameters could be passed to each Implementation Class’ constructor if needed. Another approach would be to require the instantiation to be done within the body of the Product class’ constructor. The most flexible would be to allow the instantiation to occur anywhere in constructor body:

   public Product()
      : base()
   {
      // ... Code Here ... //
      EditableObject();
      Clonable();
      // ... Code Here ... //
   }

This gives maximum flexibility to accomplish everything that you can already do but without having to write tedious and identical plumbing over and over and over again. If an instantiation call is not invoked in the constructor body then it should be done automatically by the compiler at the beginning of the constructor.

Remember, this type of thing is already possible if you do it manually; all I’m doing here is proposing my version of the syntactic sugar that IntelliSense and the compiler could give us to make it easier and less typo-prone.

Now let’s look at someone else’s idea:

Implicit Interface Implementation through Aggregation
While searching through Microsoft’s product feedback center for other Multiple Inheritance and Default Interface Implementation sympathizers, I came across a great idea posted by Dmitry Kolchev.

See (and vote on) this wonderful idea at:
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=94304

We will keep the same example as above as far as creating the EditableObject class (with the removal of the factious “implementation” keyword in the class definition). Dmitry’s Product class would look like this:

   public class Product : System.ComponentModel.IEditableObject
   {
      EditableObject _EditableObjectImplementation provides IEditableObject;
   }

Here he is proposing a new keyword called “provides” to tell the compiler to create a member definition within Product for each of IEditableObject’s members and to point them straight back at the _EditableObjectImplementation object’s corresponding member. In essence, the compiler would be adding MSIL equivalent to if we had typed in:

   public class Product : System.ComponentModel.IEditableObject
   {

      EditableObject _EditableObjectImplementation;

      public void BeginEdit()
      {
         _EditableObjectImplementation.BeginEdit();
      }

      public void CancelEdit()
      {
         _EditableObjectImplementation.CancelEdit();
      }

      public void EndEdit()
      {
         _EditableObjectImplementation.EndEdit();
      }

}

That is the same equivalent code as my Implementation Classes idea but Dmitry has gone about the definition syntax a differently. To change between implicit and explicit implementation Dmitry has also proposed the keywords “implicit” and “explicit”, although it isn’t stated where they would be placed. My guess would be after “provides”.

Also, the developer gets full control over how and when the _EditableObjectImplementation field is instantiated, which is the most flexible. Of course, if the developer doesn’t do that then they end of up with a null reference exception. The existing compiler warning will probably be enough to help most programmers and this isn’t really an issue.

Default Interface Implementation
Some folks are after Default Interface Implementation, in which interface definitions members have code in them and if you don’t “override” that member when you implement the interface then the code in the interface is used by default.

Several years ago I thought this was a good idea but I have come to realize that it would be completely useless in the vast majority of cases. Each solution has very different needs and the chances of a 1-size-fits-all solution for an interface implementation are incredibly slim.

We must have the ability to create different “default” behaviours for the same interface because your needs are different from my need and my needs in Project ABC are different than my needs in Project XYZ. Default Interface Implementation in which the code is together with the interface just doesn’t offer this.

Summary
I’m always been one to look for the best solution and I must say that I really like Dmitry’s solution. For one thing, it really clarifies that there is a big difference between inheritance and interface implementation.

That’s something that I really like about VB – it uses the Inherits keyword for inheriting and the Implements keyword for interface implementation whereas C# makes it all look like inheritance. Granted, C# is my language of choice in part because of its slim syntax but I think that every Introduction to OOP course should be taught with VB.NET because of its clear syntax.

So, Microsoft, if you’re listening: Dmitry’s idea here is fantastic and you should probably implement Default Interface Implementation this way if you don’t want the anti-Multiple-Inheritance camp up in arms. Plus it just makes a huge amount of sense. If you want to half-fake MI, go with my idea. If you want to fully-fake MI, go with what Eiffel# does. The MSIL that would be generated is the same no matter what the syntax.

Regardless of how it is done, I feel very strongly that this would benefits developers everywhere – especially those of us that are writing large frameworks. For now, we can still do it manually, albeit with a lot of tedium and copy-and-paste code. Here’s hoping Hawaii makes pseudo-MI a walk on the beach.

Happy Coding
- Shaun

Multiple Inheritance Solutions: Implementation Classes

shayward — Wed, 12 Jul 2006 15:16:00 GMT

Getting into discussions about Multiple Inheritance can be sticky things. Single-Inheritance-purists want the perfect object pyramid starting with object as the apex. They claim that it is cleaner - and they're right. How many “is a kind of” relationships can a class have?

But we must ask ourselves, "What problems are supposed to be solved by inheritance?" and then we must ask ourselves if our current or near-future system (let's say C# 3.0) solves them.

The solutions given by inheritance, as I see them and in no particular order, are:

Easy code reuse
Fix it in one place
Removal of code redundancy (no more copy-and-paste code)
Modeling real-world objects
Breaking large problems into small, manageable pieces
Pass a reference to the base class and use the same members, even though they are implemented totally differently (polymorphism)
Not knowing or caring how the code was implemented or being able to talk to it directly (encapsulation)

So does our current system in C# 3.0 (and VB 9.0) live up to these expectations? To some extent yes and to some extent no.

When We Need Multiple-Inheritance
Let's say that I want to create a layer filled with business classes like Employee, EmployeeCollection, Vendor, VendorCollection, and a couple of hundred others. Some of these should be clonable and some should not. Some of these should be editable with rollback capabilities and some should not. Some of these should be bindable and some should not. Some of these should be bindable collections and some should not.

For each of clonable, editable, bindable, and bindable collection we have the exact same code that we wish to apply everywhere. Plus we want to treat these objects the same in a clonable, editable, and bindable context regardless of what type of object they really are. Ideally, we could create 4 classes and inherit as many of which ever ones are needed for each situation.

But that would require Multiple Inheritance, which we can't have. We can just create a single, common base class because each business class needs a different combination of these functionalities. We are back to re-inventing the wheel for each one of these and using error-prone "copy-and-paste inheritance". There goes more than half of our inheritance benefits. So what good is inheritance if we can't actually use it?

The interesting thing here about these is that they are not examples of "is a kind of" relationships, as is commonly thought of with inheritance. After all, Employee isn’t a “kind of” Clonable or Editable or Bindable. All of these examples require "contracts for functionality", thus denoting interfaces.

Indeed, we have the interfaces IClonable, IEditableObject, annd IBindingList. Some, myself included, have created the IBindable interface for extending IEditableObject. But even if we use Interfaces we only gain semi-polymorphic benefits and we are still doomed to copy-and-paste code.

The Solution: Implementation Classes
The solution that I've been using is to create strong implementations of these interfaces and place them as private members in the class that I want to inherit them. The target class also implements the interface and exposes the various members of the private instances through it. For example:

   public class Clonable : ICloneable
   {
      public object Clone()
      {
         // ... Use reflection to determine
         //     which class owns this instance
         // ... Use reflection and attributes
         //     to produce the clone of the owner instance
      }
   }

   public class Employee : ICloneable
   {

      // Constructor that includes instanciating _Clonable

      private Clonable _Clonable;

      public object Clone()
      {
         return _Clonable.Clone();
      }
   }

While this is a simple example, the principal works with a whole host of interfaces. I've been using it very successfully to gain 99% of the benefits of MI without actually using MI.

I call these types of strong implementations, such as the Clonable class in this example, Implementation Classes. It's not a full class because it has no value on its own and it is just one possible, yet common, implementation of an interface.

Calling the Constructor
With inheritance, the base class’ constructor is called as the first command in the inheriting class’ constructor. With an Employee class, the constructor would look something like this:

   public Employee()
      : base()
      {
         // Constructor logic
      }

In VB.NET the call to the base class’ constrictor is the first line of code inside of the constructor body instead of a part of the constructor definition. In any event, the base class constructor is the first thing called when creating a new instance of the inheriting class.

With Implementation Classes, you must create the private instance that holds the functionality before you can use it. This should be done anywhere in the constructor body provided that nothing tries to use it before it is instantiated.

   public Employee()
   {
      // ... some statements ... //
      _Cloneable = new Cloneable();
      // ... some more statements ... //
   }

Parameterized constructors can be used as well, assuming the Implementation Class has one:

   public Employee(bool CloneDeep)
   {
      // ... some statements ... //
      _Cloneable = new Cloneable(CloneDeep);
      // ... some more statements ... //
   }

One could even delay the instantiation of the _Cloanble object until some point after the constructor has been called but this can be very dangerous because an outside object could call the Employee object’s Clone() method and generate a null reference exception.

Abstract (MustOverride) Members
Of course, Implementation classes can't really be like MI without the ability to create abstract members. The answer is in delegates.

The implementation class should create a delegate that matches the desired signature of the member. It should then create a field to hold a reference to the delegate. Finally, the "abstract member" should just invoke the referenced delegate.

public delegate bool SomeAbstractMethodDelegate(string SomeParameter);

private SomeAbstractMethodDelegate _SomeAbstractMethodInstance;

   public bool SomeAbstractMethod(string SomeParameter)
   {
      return _SomeAbstractMethodInstance.Invoke(SomeParameter);
   }

Since this is an abstract method and should be "overridden" before any functionality takes place, the best place to pass the delegate would be in the constructor.

If you were looking for a dynamically-overridable method that could change at any moment you could just wrap the _SomeAbstractMethodInstance field into a read/write property and throw an exception if someone tried to set it to null. This does, however, give the programmer enough rope to hang themselves and every member of their IT department.

Virtual (Overridable) members can be handled in a similar way but would require some extra plumbing to be able to call the original vs. the overridden version, as can be done with true inheritance.

The Benefit
What benefits do we really gain by using the concept of Implementation Classes? Now, instead of copying and pasting the full implementation of an interface over and over and over again, you only have to:

Build the implementation class once based on an interface
Create a private member instance of the Implementation class
Add ": [InterfaceName]" to the end of your "inheriting" class
Paste a block of code that simply implements the interface members by calling the private implementation object's member of the same name

I have a very large project with classes that each implements some of a dozen different interfaces in the exact same way. Since each class implements a different number and variety of these interfaces, creating a base class for all of them is not an option. Implementation Classes have largely given me back the benefits of Multiple Inheritance and they have given me back my sanity. Best of all, they don’t really violate any rules of inheritance.

There still is some copy-and-paste code, which causes me grief, but it is greatly reduced and it is much easier to debug the entire solution.

Where does this leave us?
At the end of the day, this still doesn't give us Multiple Inheritance and it still doesn't eliminate all of the redundant copy-and-paste inheritance that must be done with interfaces. But it does give the benefits of easy code reuse, fix it in one place, far less copy-and-paste code, elimination of copy-and-paste of critical code, and it allows us to further break the problem into smaller, manageable pieces.

It also underscores the fact that there are two types of inheritance: "Is a kind of" and "constrict for functionality". MI often boils down to wanting multiple contracts for functionality with the actual functionality in tact. Implementation Classes deliver just that.

Happy Coding
- Shaun

Microsoft Releases Visual A++ (Object Oriented Assembler)

shayward — Sat, 01 Apr 2006 05:00:00 GMT

Today, the Redmond giant revealed the fruits of its hush-hush labours. Visual A++, or Object Oriented Assembler, is available as a free language add-on for Visual Studio 2005 and targets the .NET Framework.

It supports the full 80x86 set of opcodes, up to an including the new opcodes introduced in Intel's Prescott chip. A subsequent version, due out mid-summer, will include opcode support for some specialized AMD opcodes.

There are many obvious benefits of having things like a static register class, structured JUMP blocks, and writing device drivers in a class-based assembly language. Windows Vista will support device drivers written entirely in managed C# or VB code so Visual A++ is no doubt part of this strategy.

The version of Visual A++ that ships with Orcas is expected to add the ability to define custom processors and mix the unique opcodes from various processors through DLLs in much the same way that VB and C# work together.

This allows assembler programmers from any background to instantly write not just libraries and device drivers but also Windows Forms and Web Forms applications. The seasoned programmer can immediately see the benefit of switching from VB to Motorola 6800 Assembler for ASP.NET 2.0 development.

The most dynamite feature, however, is the full compatibility with classic MASM and TASM, meaning that any old piece of 80x86 code will compile and target the .NET Framework. Thexder, Deskmate, and Bedford Accounting are among the old DOS applications due to be re-released as full Windows applications in managed code early in 2007. No more than a mere recompile is required.

In fact, any EXE, DLL, or set of executable components can be decompiled into Assembly language, used in Visual Studio, and compiled to IL. Combine this with the Mono project and we may just see Microsoft Word or any Windows software suddenly become available for Linux.

Just think of what this will do to open up the markets for your software projects. Rumor has it that there is one team currently working on a fully-managed Windows XP port and a version of .NET that will run on Motorola and PowerPC processors.

This means that OSX may not be the only choice for your pre-Intel G4. It's about time that someone broke Apple's unfair OS monopoly on its own hardware.

Also exciting is a rumor that Microsoft developers are presently hard at work on A#, which is pure CIL integrated into Visual Studio. Developers may soon be able to use a cil{} block in C# to drop to Common Intermediate Language, just like C developers can drop to Assembler.

I would leave you to ponder the future of computing if it were not for my closing:

Happy Coding and Happy April Fools Day
- Shaun

When Object Oriented Doesn't Wax Relational - Part 3

shayward — Thu, 02 Feb 2006 20:10:00 GMT

In a previous post entitled MVP: Object Oriented is Academic, Religion I discussed a classic example of persisting OO classes to RDBMS tables. I have now given two possible solutions in the posts When Objects Don't Wax Relational - Part 1 and When Objects Don't Wax Relational - Part 2.

Now onto Part 3, which outlines my preferred solution.

Solution 3 - One to One of Different Types
Really, what we want to say is that each ContactInformation record relates to one other record but that record is one of many different possible types. This kind of relationship doesn't exist natively in SQL Server but can be produced manually.

As with the previous solution, there is only one instance of the ContactInformation, Address, Telephone, and Email tables. Address, Telephone, and Email records are each owned by a single ContactInformation record. Nothing radical so far.

The difference is the way in which each ContactInformation record relates to its parent record.

In this solution, ContactInformation contains two columns: ParentID and ParentType. ParentID is like a foreign key field but can contain a primary key value from a Vendor, Employee, or Customer record. The ParentType field is a text field that contains the possible strings "Vendor", "Employee", or "Customer", thus telling us the type of parent record.

Compared with the previous solution, the INNER JOIN statement is much clearer in terms of how the tables relate:

   SELECT * FROM ContactInformation
   INNER JOIN Vendor ON ContactInformation.ParentID = Vendor.ID
      AND ContactInformation.ParentType='Vendor'
   WHERE Vendor.ID=@IDValue

Likewise, we can go the other way:

   SELECT * FROM Vendor
   INNER JOIN Vendor ON ContactInformation.ParentID = Vendor.ID
      AND ContactInformation.ParentType='Vendor'
   WHERE ContactInformation.ID=@IDValue

These SQL statements are very clear about their intentions. The only difference between these relationships and a standard one-to-one relationship is the addition of "AND ContactInformation.ParentType='Vendor'", which isn't really a major inconvenience. Nevertheless, this solution also carries a few issues:

1. It would be possible to orphan ContactInformation records by putting nonsense data in the ParentID and ParentType fields
2. Forgetting to add "AND ContactInformation.ParentType='TableName'" may yield undesired results
3. This is a non-standard, albeit straight-forward, approach and would have to be well documented for the benefit of those maintaining the code
4. Performance would suffer due to the doubling in the number of comparisons in a JOIN and making one of the comparisons text-based

If you absolutely must wax OO in a relational database, something like this may work for you. The use of triggers can alleviate the lack of referential integrity; 7+ years ago all relationships were done with triggers. Performance becomes less and less of an issue every year with RAM, CPU-speeds, and Hard Drive speeds all increasing. Plus you could always use constants mapped to numeric values to represent the parent type.

This solution certainly wouldn't be the answer for a small-scale project where redundant work doesn't have the same impact. This solution could really shine in a large-scale system where programmers create code-based "Lego blocks" and fit them together in different ways, particularly in ERP systems.

Maybe I'm a little crazy, but given the current features in SQL Server and what I've seen so far with O/R Mappers, this really is my solution of choice. At the very least, it's some good food for thought.

Happy Coding
- Shaun

Toronto Code Camp 2006 an Overwhelming Success

shayward — Wed, 18 Jan 2006 19:14:00 GMT

The 2006 Toronto Code Camp was the first .NET code camp in Toronto and the largest .NET code camp in Canadian history. There were over 200 geeks present, all focused on programming for the .NET Framework. What a great experience. As it turns out, I'm one of the few that actually look like geeks. Most seem to be normal and a few are even metro-sexual.

There were 20 available 1 hour 15 minute talks spread out over 4 streams and attendees weren't locked into a particular stream. It was a buffet-style feast of current and future technical knowledge including Threading, LINQ, Visual Studio Team System, AJAX, Microsoft Enterprise Library, Mobile Development, .NET Futures, and Code Access Security.

One aspect of the code camp was the target of having 10 neophyte speakers. I had the privilege of being one of them and spoke on creating applications with a Professional Look-and-Feel using Infragistics NetAdvantage. It was the first time that I have ever spoken to a technical audience (aside from coworkers), given a Power Point presentation, and lectured for over an hour.

It's spooky and humbling to realize that I have actually accumulated enough experience to have something worth listening to. It is largely thanks to wealth of guidance given directly and indirectly by peers that I shall never be able to equal in knowledge and understanding.

It's also nice to learn that I rather enjoy public speaking. Of course, having a good and responsive crowd made the whole experience quite pleasant. I'm looking forward to speaking to the East of Toronto .NET User Group in February.

Winning the grand prize of an MSDN Premium Subscription with Team Suite was the thick, gooey, chocolaty icing on the cake.

The day will certainly be one of my best and most memorable ever. It may not beat out my absolute most memorable days, including my wedding day, the birth days of each of my children, or the day I accepted Jesus, but it sure rates up there as a solid second.

Here's to the 2007 Toronto Code Camp. I hope to see you there.

Happy Coding
- Shaun

When Object Oriented Doesn't Wax Relational - Part 2

shayward — Mon, 02 Jan 2006 21:15:00 GMT

In a previous post entitled MVP: Object Oriented is Academic, Religion I discussed a classic example of persisting OO classes to RDBMS tables. I gave one possible solution in the post When Object Oriented Doesn't Wax Relational - Part 1. In part two, I will examine another possible solution.

Hats off to Chris Falter for beating me to it. He added a comment at the end of the Part 1 post, suggesting the very solution that I planned to cover here in Part 2. We each have a slightly different angle on it but are talking about the same thing.

Solution 2 - Reversing the Relationships
When performing an inner join, SQL doesn't care which field is the primary key and which is the foreign key. In fact, it doesn't even care* if either field is a primary key or foreign key.

I have seen solutions that use this to their advantage. I've even authored one. When applied to our example, there would be single ContactInformation, Address, Telephone, and Email tables. Address, Telephone, and Email all have a foreign key field called ContactInformationID that relates back to its parent ContactInformation record.

In traditional relational database design, the ContactInformation table would a foreign key field that relates to its parent. Because of our unique scenario, each ContactInformation record could be "owned" by a record from different tables - in this case, Employee, Customer, or Vendor. Thus, ContactInformation cannot have a single foreign key field that references a parent record.

Instead, the parent tables each have a ContactInformationID field that is a foreign key and relates to the ContactInformation table's primary key. INNER JOIN statements become fairly simple:

SELECT * FROM ContactInformation
INNER JOIN Vendor ON Vendor.ContactInformationID = ContactInformation.ID
WHERE Vendor.ID=@IDValue

This certainly allows us to map one table to one class and it makes writing persistence code much easier. We are at least getting the 1-to-1-of-different-types correlations that we desire with far less work. This solution does, however, have some short-comings:

It would be possible to have a Vendor, Employee, and Customer all reference the same ContactInformation record, thus defeating referential integrity
The ContactInformation would have to be persisted first, which isn't really a big problem
The reality of the database structure is opposite the intention of the solution, which is confusing
The intention of a SQL Statement is easily misunderstood
This is a very non-standard approach and would have to be very well documented for those maintaining the code

It's not to say that a solution such as this couldn't work, but, like growing a Bonsai Tree, the conditions would have to be perfect. It would be best applied to a large-scale system where database performance is of the essence, all code is object oriented, the code is all maintained in-house, all developers are well versed in the art of OOP, all developers fully understand why relationship-reversal is being used, and the scenario warrants this type of relationship. This may be a pretty tall order.

Some Nay-Sayers may view this solution as invalid due to bad database design. It's not to say that they would be wrong in this view, but when convergence point between two very different theories, methodologies, or technologies is often quite messy. As architects, we have to choose whether we want that mess in the database (as with this scenario) or in the code.

Typically, the messy part ends up in the code. As a lover of OOP and lukewarm to relational databases, I somewhat begrudge this. But I appreciate why this is the case. Often, several different solutions from several different vendors will be written against the same database. The cleaner the database, the better all around.

So would I use this solution? It sure wouldn't be my first choice but if the conditions were fertile and nothing else would work then I would at least consider trying to grow a good crop of reversed-relationships just to keep my farming simple.

Happy Coding

- Shaun

* There will, of course, be mild-to-moderate performance issues if the fields utilized in the JOIN are not indexed

When Object Oriented Doesn't Wax Relational - Part 1

shayward — Fri, 16 Dec 2005 13:27:00 GMT

In a previous post entitled MVP: Object Oriented is Academic, Religion I discussed a classic example of persisting OO classes to RDBMS tables. Here’s a recap:

We have 4 classes that hold contact information. They are: ContactInformation, Address, Telephone, and Email. ContactInformation can hold zero-through-infinity each of Address, Telephone, and Email.

Normally, we would create 4 tables that correspond to the 4 classes. ContactInformation would have a primary key and Address, Telephone, and Email would each have a foreign key called ContactInformationID.

The problem is that in our class design, we have the classes Vendor, Employee, and Customer. Each of these has a ContactInformation member of the type ContactInformation. This simplifies our code because a single change or fix to any of the 4 contact-related classes is immediately reflected in the Vendor, Employee, and Customer classes.

The big question is this: how do we design the data storage for a relational database management system and how do we write our persistence code?

There are three possible solutions that I can see and I would like to cover the first one today.

Solution 1 - Separate Tables
It seems that the most "referentially integral" solution would be to create separate tables to house the contact information for each of Vendor, Customer, and Employee. Thus, we have the following tables:

VendorContactInformation
VendorAddress
VendorTelephone
VendorEmail
CustomerContactInformation
CustomerAddress
CustomerTelephone
CustomerEmail
EmployeeContactInformation
EmployeeAddress
EmployeeTelephone
EmployeeEmail.

While it does mean that the database maintains its own integrity (a good thing indeed), it certainly has some issues:

When we make a change to the structure of any of the ContactInformation and related classes, we must make the change 3 times in the database and possibly in several redundant persistor objects in our code
We must create a fairly heavy single persistor in our code or else Vendor, Customer, and Employee must each have their own ContactInformation persistor
To do a search for a piece of contact information (e.g. a telephone number) regardless of what type of entity to which it belongs, we must perform a union in a view or subquery
When adding additional entities (e.g. ShippingCompany, Manufacturer, Agency) that each include the ContactInformation class, we must reproduce everything over again and update several views

A portion of the inconvenience could be fixed with stored procedures by creating, say, sp_GetAddresses that takes the Vendor, Employee, or Customer ID and a string denoting whether we are after the addresses for a Vendor, Employee, or Customer. At least the use of stored procedures can make persistence and retrieval more generic.

I have no doubt that this is a common solution but it certainly is cumbersome. The OO code makes standardization and maintainability so easy but the database's limitations seem to undo this advantage quite quickly.

This classic solution just doesn’t seem to have the forward-thinking for where we are heading in the future. It is, however, safe. Please feel free to post your own ideas, no matter how conservative or how crazy. I've got a few more ideas coming up that are sure to get me a one-way-ticket to the looney bin.

Happy Coding
- Shaun

MVP: Object Oriented is Academic, Religion

shayward — Thu, 01 Dec 2005 14:36:00 GMT

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

Extension Methods: Still Not Multiple Inheritance

shayward — Tue, 01 Nov 2005 14:40:00 GMT

Extension Methods can be used as a piece of pseudo-multiple-inheritance for methods, but they really have a different purpose than Inheritance and Multiple Inheritance. In some cases, Extension Methods can be used as a substitute for Multiple Inheritance. That said, if C# 5.0 (presently fictitious) has both Extension Methods and Multiple Inheritance, both will continue to be used as solutions for different types of problems.

Inheritance gives us the 'is a kind of' relationship between classes. It also causes us to inherently gain functionality (methods & events), attributes (properties & fields), and state (values in properties & fields). It also allows us to cast back up the class hierarchy, tie together many related members in a tight manner, and override functionality thus giving us polymorphism. When desiring to make changes that impact all classes further down the hierarchy, we must have access and/or liberty to make changes to the base class - a luxury that is not always afforded us.

Extension Methods do not give us any kind of relationship ('is a kind of', 'contract for functionality', or otherwise). They do not give us attributes nor do they give us state. They do not give us casting, they do not tie together many related members, nor do they allow overriding & polymorphism. Extension Methods, however, do not require any modifications to the base classes and thus we can extend functionality of an existing class without restriction.

What Extension Methods do is give us the ability to add a simple, stand alone method to existing classes with no intrusion whatsoever. I've heard them described (quite accurately) as "syntactic sugar" implemented in the compiler. It merely changes:

MyStaticIListHelperClass.Merge(IList1, IList2);

into:

IList1.Merge(IList2);

My understanding of Extension Methods is that the latter statement in this example would actually compiles into the former.

While Extension Methods can serve a small part of the same function as Multiple Inheritance, they certainly don't eliminate the need for Multiple Inheritance and they are really intended for a different purpose. Nevertheless, they are a most welcome addition and will be of great use in many of our solutions. All we have to do now is wait for Visual Studio Next.

Happy Coding
- Shaun

Multiple Inheritance Solutions: Extension Methods

shayward — Mon, 31 Oct 2005 14:09:00 GMT

C# 3.0 will see the light of day sometime in 2007-2008 with an exciting new feature: Extension Methods. I was browsing a document authored by Anders Hejlsberg with all of the upcoming LINQ-related stuff when I stumbled on them. "My goodness! We've got Multiple Inheritance!" was my first reaction. Indeed, Extension Methods give us Multiple Inheritance... kind of.

It is an important feature that gives us a small piece of Multiple Inheritance functionality, even if it’s not the Redmond-sent fulfillment to Multiple Inheritance prophesy that I first thought. Essentially, an Extension Method let's you create a static (Shared in VB) method that will "look like" it is a method in one or more classes of a given type.

Let's suppose that you wish that IList, TextBox, or a 3rd-part ComboBox had certain methods to accomplish specific tasks. You could always make your own derived classes with the methods that you want. This is a good technique in some cases - especially when you need to add many methods, properties, and events as well as override some members. For simply adding a disjointed method or two, however, there are some drawbacks:

1: if you want all of your objects to have the new method then you must replace every declaration or modify the base class
2: if you expand an interface you will have to change all of the classes that use it
3: you will not be able to make changes to objects that are part of a framework, rendering your new method useless for them
4: you cannot add methods to the System.Object class, even though you may want to add a method to every class in your project
5: it requires an awful lot of work for the simple goal of adding a method or two
6: Sometimes you want to modify classes that form a composite but cannot do so without ugly (and error-prone) member hiding

When adding a simple method that is stateless and stand-alone, often programmers will create a static class with a static method. One might create a static method to merge together two IList objects by adding all of the second IList's items to the first.

public static void Merge(IList Destination, IList Source) { ... }

One can even go as far as to make a version for the generic IList.

public static void Merge(IList Destination, IList Source) { ... }

This is a very good way of "adding stand-alone functionality" to an existing class without actually making changes to it. I find myself doing this quite often with grids when I have a common way of setting up columns based on attributes in the data source.

Assuming that the aforementioned static Merge method belongs to a static class called IListHelper, calling the method would be done as follows:

IListHelper.Merge(FirstIListObject, SecondIListObject);

There is no shame in this syntax, but it may not be as clear as one would like. Perhaps you wish that IList itself had the merge method and that it worked exactly the same as your code in the static method. The net result should be the same but the syntax should look like:

FirstIListObject.Merge(SecondIListObject);

If you like this syntax better, congratulations! This is Extension Methods.

While calling the static class is not really confusing or unclear, calling the Merge method as if it is a member of IList is even clearer still. It's kind of like the difference between photocopier paper and the really bright laser paper - photocopier paper looks white until you hold it next to the good stuff.

All it takes it one small change to our static method declaration:

public static void Merge(this IList Destination, IList Source) { ... }

The "this" keyword added before the parameter list tells the compiler that Merge is an Extension Method. The first parameter in the list tells the compiler (and IntelliSense) which type of object can use the static method as an Extension Method.

Casting backwards does apply so any class that implements IList can also use the extension method. This is helpful in a variety of situations - especially if there is a method that we want to apply to all classes. One example might be to output the return of ToString to the console.

public static void WriteToConsole(this object o) { ... }

...

SomeEmployeeObject.WriteToControle();

There are no doubt thousands of ways to use this new feature. While it doesn't remove the need for Multiple Inheritance (or, at least, not much of it) it does give us another tool that is a kind of basic Multiple Inheritance. C# 3.0 is just a baby and I'm personally hoping that it will include Extension Properties and Extension Fields as well.

Happy Coding
- Shaun

Multiple Inheritance Solutions: We Must Use Interfaces

shayward — Fri, 28 Oct 2005 16:06:00 GMT

Wesner Moise added some very noteworthy comments to my Baby Steps Towards Multiple Inheritance in .NET post.

Some objections to MI surround multiple vtables and keeping them lined up. It is the most intelligent argument against true Multiple Inheritance by far. Granted, it is not an argument that Multiple Inheritance is bad but rather it is difficult for the CLR to implement. People that understand this far better than I do include Chris Brumme and Wesner Moise.

The bottom line is this: implementing true Multiple Inheritance is going to be a serious pain in the backside for the CLR team.

Yet we don't seem to have any trouble whatsoever with Multiple Interface inheritance. Therefore, we need to use interfaces as a starting point for any Multiple Inheritance endeavors. This won't lead to true MI but we may be able to get almost all of the functionality of true MI without true MI and the drawbacks that accompany it.

Furthermore, any model that is based on interfaces would be portable to Java, Delphi, and other languages. I am presently aware of a few different methods for Multiple Inheritance using Interfaces. These include Default Interface Implementation and Implementation Classes. If you are aware of others, let me know.

I will cover both of the solutions that I know in further detail in upcoming posts. For now, I want to lay it all down and be perfectly clear: true Multiple Inheritance is not likely to exist in .NET for many, many years - if ever.

However, an interface-based solution would be extremely easy for the .NET teams to implement with very minor changes. That is what I believe we should be encouraging for the Hawaii (or even Orcas, if we shout loud enough) timeframe.

Happy Coding
- Shaun

When is Multiple Inheritance a Good Thing?

shayward — Thu, 27 Oct 2005 12:57:00 GMT

Multiple Inheritance isn't right for every situation. Many solutions never need Multiple Inheritance. Many solutions that could use Multiple Inheritance shouldn't use it because it is the wrong place. Yet one project that I'm working on right now would use MI in about 70% of the classes if it were now available and the code would be simpler, more robust, and more reliable.

There are many nay-sayers that will argue, "How can you have a class with multiple 'is a kind of' relationships?" They would be right, except that we can have multiple interfaces on a single class. Of course, nay-sayers will further argue, "That's different. An interface defines a 'contract for functionality' rather than an 'is a kind of' relationship."

This is where it gets a little gray. If I have a class called EmployeeCollection that implements IList, doesn't EmployeeCollection become 'a kind of' IList? Indeed, it does! And what if I want the same IList implementation for both EmployeeCollection and VendorCollection?

So why not just inherit a regular class like ArrayList or the List<> class? That way, you get IList<> and the 100% identical implementation in both EmployeeCollection and VendorCollection. That's a great idea and is one of the main reasons for Inheritance. You code it once, inherit it many times, and fix bugs only once. This also eliminates the numerous "copy and paste" errors.

Now let’s suppose that we have come up with a sophisticated implementation of IComparable that uses reflection, can look through lists and use the IComparable interface on list items, etc. We roll this functionality into a class called Comparable<> and can inherit it if we want to use it in a class. Because .NET only supports Single Inheritance, we cannot have EmployeeCollection inherit both List<> and Comparable<>. We are back into the messy, error-prone copy and paste method of Interface Implementation.

The Single Inheritance answer may seem clear: create a class that inherits List<> and has all of the Comparable<> functionality. Call it ComparableList<>. The problem is that we want to inherit from Comparable<> on the Employee and Vendor classes and these classes don't need the List<> portion because they are not collections.

In effect, sometimes we want to inherit List<>, sometimes we want to inherit Comparable<>, and sometimes we want to inherit both. This is further complicated by the fact that we have also created a standard implementation of IClonable called Clonable as well as our own custom interface called IPersistable with a general Persistable class that implements it. We may even want to do the same for IEditableObject.

We may have identical implementations of a dozen interfaces that we wish to join in various combinations with 1000 or more classes within our solution. Suppose that 1000 classes want to inherit the Clonable class but cannot because they already inherit the Comparable<> class. Therefore, we have to copy and paste the Clonable class code into 1000 classes. When we make a change to the standard Clonable code, we have to change 1000 classes.

Not only does this waste a huge amount of time but it also greatly increases the chances of introducing new bugs. If this scenario seems unrealistic, rest assured that it is not – especially when working with 500+ table databases.

The one interesting thing about this example is that all of the desired Multiple Inheritance really seems to hover around common Interface Implementation. Even though Clonable<> is a class, inheriting it really says that you want the contract for functionality plus the standard functionality itself. It does not imply the desire for an 'is a kind of' relationship.

My personal opinion is that multiple inheritance is good when you really want to have multiple contracts for functionality with identical implementation on several (perhaps 1000s of) different classes.

We still only need a single 'is a kind of' relationship for each class. We inherit other classes to provide both the Contract for Functionality as well as to implement that contract in a common way.

This isn't indicative of the theory for true Multiple Inheritance but in my own experience it certainly is the most practical application for it. While it wouldn't satisfy all developers, I think that most of us would be more than happy with some form of Default Interface Implementation. In the truest sense of what DII would represent, I think that most of us would end up using that for most of our classes rather than inheriting from things such as List<>.

I've submitted an early vision of what I call Implementation Classes through the MSDN Product Feedback Center. Check it out at http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?FeedbackId=6b4749b0-42be-4e21-90fb-b2e57c9d1adf and see what you think. The idea is still early and I am continuing to work on it.

Happy Coding
- Shaun

A Geek's Perspective on the journey

shayward — Tue, 25 Oct 2005 19:58:00 GMT

We're all geeks. If you're not a geek then you're really reading the wrong blog. I thought that for something light-hearted I would give this geek's perspective on the journey towards what Dogbert referred to as "Nerdvana".

My name is Shaun Hayward and I grew up in the small town of Beaverton, Ontario, Canada, attending Brock High School and graduating far below honours*. We didn't do the "most likely to..." awards, but if we did I would have been voted "Most likely to achieve an Olympic gold medal in heavy-weight vagrancy before the age of 25."

While I never took a computer class in high school, I quickly discovered that handing the administrator his password on a piece of paper can be a great source of amusement. While I never had the testicular fortitude to do that myself, I lived vicariously through my braver contemporaries. I also enjoyed ripping apart PC's in my folks' basement. Yes, I lived in my folks' basement until after college (and I like Star Trek... but I don't see the connection that everyone else seems to see).

Before graduating high school, I couldn't resist the seductive sales pitch of Sally Struthers and William Shatner so I completed the PC Repair diploma from International Correspondence Schools. And that diploma is unlike anything else. No paper for ICS... no, my diploma came printed and urethaned on 100% particle board.

Ultimately, I found trouble shooting PC's unpleasant. Everyone and their brother wanted me to look at their PC for free and the phone never quit ringing. It made me feel like a box of Smarties at a Weigh Watcher's convention. (Please note that I am morbidly obese and thus have license to make fat jokes).

As a child, I always wanted to write programs. An acquaintance and programmer, with his keyboard completely gray from cigarette ashes, told me to check out VB - which was a good starting point. I read every book I could and learned how to write database apps. There were still many cracks (okay, canyons) in my knowledge, however.

It was off to CDI College for their buffet-style learning. At CDI, my programming instructor was extremely knowledgeable and their courseware was up-to-date and without error or omission. Any CDI alumni out there know that I’m being a little tongue-in-cheek.

But, I learned a lot of great stuff from the other students and from some of the other instructors. Plus, it ultimately landed me a job that has allowed me to continue developing as a developer. That is what I was after more than anything so I really can't complain. Mind you, I still have a few of the canyons.

As far as academia is concerned, I probably shouldn't be blogging on Multiple Inheritance let-alone programming let-alone procreating let-alone occupying space and consuming oxygen. Fortunately, technology is far more about the passion, the understanding, and the mindset than it is about the piece of paper.

Not that there's anything wrong with a good piece of paper... it's all just one step in the journey where the road extends recursively until we hit our final Stack Overflow Exception and the mighty CLR sends the gc to reclaim us back into the great beyond.

Happy Coding
- Shaun

* In Canada, we spell several words with a "u" such as honour, valour, colour