October 2005 - Posts
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
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
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
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
I am quite pleased at the number of people that have visited the .NET Multiple Inheritance blog. Very few have commented but all those that have left comments have left fantastic points and/or fantastic questions and/or fantastic links. While I hadn't planned to expand on my previous post, a comment by a bright fellow, known to us only as "Steve", has caused me to respond.
Steve's Point 1
Given:
misealed class Foo{};
class Bar : Foo {};
class Quux{};
Is the following permissable? Why or why not?
class Baz : Bar, Quux {}
Does your answer change if you're not allowed to pretend Foo == MarshalByRefObject? Can you argue one way or the other in the general case?
Shaun's Response 1
We should be consistent with sealing members. When inheriting from a class that has a virtual or template member, we can override it. In doing so, we can also mark the member as sealed - meaning that further subclasses cannot override it.
For example, class Mojo has a virtual method called DoSomething. Class Fragalistic inherits from Mojo and overrides DoSomething. It also marks DoSomething as sealed. Class Poppins inherits from Fragalistic and doesn't do anything with DoSomething. Finally, class Pinko inherits from Poppins and tries to override DoSomething. Alas, it fails because DoSomething was sealed by Fragalistic. Even though the method was not resealed by Poppins, the sealing by a class further up the hierarchy prevales. So:
Mojo (declares virtual member DoSomething)
|
|
Fragalistic (overrides and seals DoSomething)
|
|
Poppins (doesn't do anything with DoSomething)
|
|
Pinko (tries to override DoSomething but fails because Fragalistic sealed it)
Since we can't ignore sealed for both classes and members, we shouldn't be able to ignore misealed. Therefore, class Baz : Bar, Quux {} should not be allowed to compile. The misealed of any class in the hierarchy should be honoured. After all, the programmer would have misealed it for a good reason... or at least one would hope.
Steve's Point 2
Given:
class Bar{};
[CannotInheritWith( typeof( Bar ) )]
class Foo{};
class Baz : Bar {};
Is the following permissable? Why or why not?
class Quux : Foo, Baz {}...
Shaun's Response 2
In the same way that we should honour misealed in any parent in the hierarchy, we should also honour the ConnotInheritWith attribute. This continues to be consistent with both the currently-fictional misealed as well as the non-fictional sealed. Therefore, class Quux : Foo, Baz {} should not compile.
Steve's Point 3
Since [CannotInheritWith] requires a class to declare is exclusivity set at the time the class is defined, how do you deal with the inherent versioning problems? What happens when someone comes along after Foo is shipped and declares a new type that cannot be inherited with Foo? Does Foo have to be revved as well? What if the authors of Foo don't know about this new type because it's written by some third party they've never met?
Shaun's Response 3
Just when I think that I've everything licked with a good answer, Steve brings up a point that makes things a little trickier.
The first part of the response is that the compiler should check all classes being jointly inherited to see if any of them disagree with each other. For example:
class Bar{};
[CannotInheritWith( typeof( Bar ) )]
class Foo{};
class FooBar : Bar, Foo {}
Bar could be in a different library and completely unaware of the existence of Foo. The compiler would look at Bar first for any mention of Foo in [CannotInheritWith] and when it doesn't find it, it moves onto Foo. In Foo, it does find that it cannot be jointly inherited with Bar and so the compilation fails.
In short, only one class would have to "opt out" of joint inheritance with specific other classes for the compile to fail.
Versioning, however, is where it gets really tricky. Suppose that a couple of classes do not use [CannotInheritWith] and are part of a commercial framework for a few years. Lots of 3rd party vendors have merged the two classes into one via Multiple Inheritance. Suddenly, a new version of the framework comes out and both of the classes have been expanded to the point that they have conflicting functionality. Thanks to the [CannotInheritWith] attribute, the framework no longer allows the two classes to be merged.
This will cause all of the 3rd party code to fail at compile time if it uses Multiple Inheritance to join the two classes. While most unfortunate, a similar reality exists anytime there is a major change to a framework. Perhaps a framework class was not marked as sealed but in version 5.0, it is marked as sealed. Any 3rd party code that inherits from the class will fail when they attempt to compile against the new version.
Summary
Thanks, Steve, for your excellent points and your kind words. I hope I have addressed the three points to your satisfaction. If not, I would definitely love to have you comment further. While I'm sure that the following sounds ever so cliché, open discussion is how we learn and grow as developers and as people in general.
Happy Coding
- Shaun
PS: Steve, I hope you didn't mind me turning the response to your comments into a post of its own but you raised such relevant points that I wanted to address them front and center.
Another argument against Multiple Inheritance involves conflicting parent classes. Essentially, this is when you inherit from two classes that should be mutually exclusive to each other. One example is inheriting from one class that handles all marshalling by value and inheriting from another that handles all marshalling by reference. How, then, will the child object be marshaled?
In your own code, you can probably see dozens of examples. Why would you create a child class that inherits from both an Employee class and from a BankAccount class? Surely no class should be 'a kind of' Employee and 'a kind of' Bank Account. That would be absurd!
At the core of powerful frameworks created by senior developers, there will surely be some mutually exclusive classes that should not be merged together in a child class. If Multiple Inheritance was allowed in .NET, how do we prevent developers that are consuming the framework from inheriting from conflicting classes?
Solution 1: Mark Classes as Not Allowed for Multiple Inheritance
A new keyword should prevent classes from being inherited as part of a multiple inheritance scheme, just as we mark classes as sealed (NotInheritable in VB) to prevent them from being inherited at all. A keyword such as misealed (NotMIInheritable) might work. The keyword is rather irrelevant; it is the concept that is important.
Regardless of whether or not there are other mechanisms in place to prevent conflicting parent classes, this type of keyword should be made available. Of course, having something like sisealed (NotSIInheritable) would be silly. How could we say that a class can be inherited as a part of MI but not as a part of SI?
Solution 2: Specify Which Classes Cannot Be Inherited Together
Probably the most effective solution is to specify which classes cannot be jointly inherited by a child class. Often, the framework developers are aware of which classes are opposites and mutually exclusive to each other.
The easiest way to prevent these classes from being inherited together is through the use of attributes. The attribute could be called something like ‘CannotInheritWith’ and could take as little as a class name, although it could include namespace and assembly information. Naturally, the attribute should have its Allow Multiple usage set to true as a class may have more than one mutually exclusive neighbor.
This solution is somewhat similar to the way that C# 2.0 (and VB 8.0?) uses the InternalsVisibleTo attribute to define "Friend Assemblies".
Summary
These are both simple solutions and I think they do a nice job of cleaning up parental conflicts so that the child classes don't end confused as a result. A few of the MI problems get bogged down in a mire of complexity when trying to find a solution. Fortunately, this problem isn’t one of them.
Happy Coding
- Shaun
Before we get into discussing some good ways to implement Multiple Inheritance in .NET, I think that it is important that we look at the many pitfalls of MI. This helps to determine "what not to do" when looking for ways to cause .NET, the CLR, and MI to agree with each other. Let’s start with the Diamond of Death.
Diamond of Death. Wow... what a cool name for a heavy metal band. Although, I've always been partial to Satanic Bacon. My wife jokes that this is the first recorded recipe for deviled ham. But enough about demonic pork...
The "Diamond of Death" is a term often used to describe on of the main pitfalls in multiple inheritance: Inheriting directly or indirectly from the same base class two or more times.
Y Y
\ /
\ /
Z
Of course, that example is a little absurd. Plus it doesn't form a diamond. Would it best be called "The V of Death"?
Okay, let's say that you have class A. Class B inherits class A. Class C also inherits from class A. Now, class D wants to inherit from classes B and C. Class D would then contain class A twice.
A
/ \
/ \
B C
\ /
\ /
D
Thus, the Diamond of Death. This example is still a little simplistic but works for illustration purposes.
So, what's the big deal? There are a few big deals with this.
When class B is instantiated, it will create an instance of its base class - class A. This allows it to use the base class' functionality and state. Likewise, when class C is instantiated, it will also create an instance of class A. So far, so good.
When we create an instance of class D, it will create an instance of both class B and class C. Then classes B and C each create an instance of class A, which is where the problems lie.
Issue 1: Protected Member Resolution
Suppose class A has a protected member called Foo. When D attempts to access the member Foo, which Foo does it use? The Foo from class B's class A or the one from class C's class A?
This problem shouldn't <I>too</I> hard to solve in a simple example. My solution would be to parameterize the "base" keyword in C# when a call is ambiguous. Thus:
base(B).Foo();
Of course, this only works well for simple diamond issues, like the one mentioned above. Things can get a whole lot more complicated. This would quickly turn into horrible statements like:
base(SomeClass)(SomeOtherClass)(ClassInQuestion)(ParentWeReallyWant).Foo()
That is just unacceptable.
Issue 2: Public Members
Classes are wonderful in that they hide their uglies from the world. All you need to know is the parameters and return type of a member. You don't care about the internal workings of the class at all.
So what happens when class A has a public member called Bar and we want to call that method on an instance of class D? Which Bar do we call? Using the same parameterized solution from Issue 1 (which we already concluded won't work in a complex situation) yields the following:
D myD = new D();
D.Bar(B)(Any of the regular parameters);
Now the programmer has to know details about the internal workings of class D. This is also unacceptable. The simple solution is to force D to override the Bar member and implement whichever one makes sense.
That is not the end of our problems, however. What if Bar is marked as sealed and we cannot override it? What if we cannot properly choose between which version of Bar to use? There really doesn't seem to be an effective way to handle ambiguous public members.
Issue 3: Casting
One of the great things about inheritance is that you can cast an instance of a child class to work like its parent class. Class B inherits from class A. If a piece of code requires an instance of class A, you can substitute an instance class B and the code will be none the wiser.
That is because you can easily and automatically cast to a base class with no questions asked. But what happens if you try to use an instance of class D in place of class A? Will it cast to class A of class B or class A of class C? I'm getting dizzy just writing about it.
Again, casting would require some ugly syntax and we would be riddled with problems. Some might argue that you could attach meta data to say which instance of class A is preferred in those situations but this is just as ugly.
Once again, there is no elegant solution for the ambiguity left in the wake of the Diamond of Death.
Avoiding the Diamond of Death
So how do you get around the Diamond of Death in Multiple Inheritance? The simplest way is to disallow it at compile time. Do not allow a class to compile if it inherits from two or more parent classes (directly or indirectly) that have a common base class.
Of course, one allowance has to be made because every class inherits from System.Object. Fortunately, there are no protected members to resolve and it only has a couple of public members. As a result, any class that inherits from more than one base class must be forced to override ToString and GetHashCode.
The only issue that I can see comes when casting to System.Object. After all, which System.Object instance does it point to? Some changes would have to be made to the CLR to accommodate this and we could end up with some problems. I can't see Microsoft making any changes this major to the core of .NET for several years.
It seems to me, however, that much of the MI direction that Microsoft is taking involves giving us the power of MI without actually giving us true MI. It certainly avoids this pitfall and many other pitfalls
Happy Coding
- Shaun
Discussing MI with many people is like talking about religion or politics - you're smart if you're talking to people that agree and a fool if you're talking to people that disagree. Those that disagree may cite some anecdotal evidence about something that happened to someone their brother heard about years ago. Or maybe they'll butcher someone else's valid argument and stand by it as proof of their point even though they completely missed the author’s intentions.
Arguments against MI, which can seldom be substantiated, include:
- It's bad practice
- Programmers will abuse it
- Programs will get too complicated
- There are other ways to accomplish the same thing
- There’s no real need for it
- MI allows for the Diamond of Death
- Naming conflicts prove that MI is bad
- You can inherit from two conflicting base classes, such as MarshalByVal and MarshalByRef
I've participated a little bit in the MSDN Product Feedback Center for VS2005. In response to my desire for Mixins, one smart fellow from Microsoft had the following to say:
“It generally turns out that there are a lot of pitfalls in there, when you get to the details, and frankly we haven't seen a mature solution yet.”
Now there's an honest perspective devoid of bias. They're not saying that a mature solution will never exist; they are saying that they have not yet seen a mature solution. I interpret this to mean, "a mature solution that they agree with."
And so Microsoft seems to be taking baby steps towards Multiple Inheritance. To be honest, I'm disappointed that we probably won't see MI in Orcas or Hawaii but I understand why. .NET has to support a variety of languages and they don't all agree on what MI is, let alone how to use it. Furthermore, neither C# nor VB.NET have any frame of reference on how to support MI. Microsoft shouldn't jump the gun on this one and implement something that they must later undo, much to the dismay of programmers that have written millions of lines of code.
.NET MI started with the first release back in 2002 with multiple Interface implementation. This takes a page from the Java book and the Java book took the very same page from the C++ book. An Interface is merely a bunch of public members with no implementation. Interfaces can serve two purposes: to give us "common contracts" for consistency as well as to give us specific views of the data in a class.
Visual Studio 2005 gives us another piece of the inheritance puzzle with Generics. While generics do not help us with Multiple Inheritance, they do help us with another inheritance problem. We often had to shadow and/or overload members to allow for strong typing. Generics have delivered us from this and generic classes inherit very nicely.
C# 3.0 (Orcas timeframe) introduces Extension Methods. This essentially allows us to create static methods that can be "mixed in" with various objects. This is similar to Ruby-style mix-ins and brings us another step closer to Multiple Inheritance.
With every major release, Microsoft seems to add one more piece to the Multiple Inheritance puzzle. Perhaps C# 4.0 will also introduce Extension Properties, Extension Events, and Extension Fields. If and when this happens, C# programmers will be able to "fake" a weird form of MI.
Once they add in Default Interface Implementation complete with a parameterized constructor and private/protected members then we will have almost all of the benefits of MI without actually having MI. While I'm hopeful for this in the Orcas or Hawaii timeframe, I'm sure that this will be at least one major version beyond that.
Two versions after Hawaii, I'm sure that we'll see the first true Multiple Inheritance, albeit with some great restrictions on its use. Restrictions or no restrictions, I certainly welcome that day.
Happy Coding
- Shaun
Coming to grips with Object Oriented programming can be tough. It's not that OOP is complex - in fact, I now find it far simpler than procedural programming. What I found the hardest was the lack of a good explanation of why one would want to use it, let alone how one would use it, let alone when one would use it. My college C++ instructor didn't know C++ nor could she even remotely explain object oriented theory.
Most people end up with nonsense explanations like, "Well, you have the Animal class and both Dog and Cat inherit from the Animal class. Now, the Animal class has a MakeSound method, which is marked as abstract and you must override. That method may be called from the GetHurt event of the Animal class, which is fully implemented. Overriding the MakeSound method is a good example of how polymorphism comes into play, as the Animal class GetHurt method will call the abstract method but it will yield a different result for both the Cat and Dog classes. Then we get into the Poodle and LabradorRetriever classes that inherit from the Dog class."
I don't know about you, but when OOP was explained like that I just quit listening. For one, what on earth are they talking about? Two, when will I ever need to program a Poodle class? And so, I didn't understand OOP and kept on happily working in my world of VB4 through 6. When I started into VB.NET and later C#, I finally found the good explanation that I needed.
Please consider reading The C# Class Design Handbook or The VB.NET Class Design Handbook. Both are excellent reads and explain inheritance using a BankAccount class - something we are far more liable to program than an Animal. I especially recommend this to VB.NET programmers without a Java/C++ background because the VB community went without true OOP for such a long time and so OOP is still fairly new (< 4 Years) to the VB community as a whole.
These books are also brief and to-the-point. You can gain a lot of understanding with just a short read. They are from the old Wrox .NET Handbook series - the finest series of programming books ever released, IMHO. It's too bad that Wrox went belly-up; these books would have been fantastic applied to Java and other topics.
While the aforementioned animal explanation now makes perfect sense, it certainly wasn't in any way due to the explanation itself.
Happy reading
- Shaun
Greetings
Welcome to the new Dot Net Multiple Inheritance blog. Since working with VB.NET and later C# beginning in 2002, I have been strongly in favor of supporting multiple inheritance.