I’m accustomed to making broad statements without qualification (hey, I was in Sales for a while). But the other day, I was reading the Web site of a somewhat popular Javascript library written by a PhD, and after nearly every article on the site, I had to shake my head and ask, “Is this what they’re teaching kids in Computer Science today?”
Just one of the things that made me shake my head: “The primary mechanism by which most modern OOP languages (such as Java and C#) implement this [Multiple Inheritance] is through the use of interfaces.”
Bzzzt! Wrong. And you’ve got a PhD? In What?
The danger of experts
Now I don’t really have a problem with some kid standing up on his virtual soap box and making a fool of himself before the ink is even dry on his precious PhD sheepskin. What I really have a problem with is the general calibre of developer using Javascript is such that this sort of mistake will be accepted as gospel.
How do I know? Well I didn’t stumble across this Web site out of thin air. I encountered it via links from several Web development sites and also coincidentally on del.icio.us. Those Web developers linking to this site were ecstatic that someone was mimicking the .Net library (questionable idea) and were terribly impressed with the doctor’s efforts.
What’s worse, is some of the code is quite good. I’d question the need for quite a lot of it, but that’s just because I’m very comfortable with Javascript and don’t need an extensive library like this.
I’m no expert
If you ever catch me claiming to be an expert at anything, call bullshit. I’ve written a lot of software over the years for numerous platforms with a variety of languages and libraries. That gives me perspective.
And I’m naturally opinionated. (Ask anyone who knows me well.)
Of course, I have a way of stating things that would enable you to think I’m an expert: I don’t go in for self doubt in the realm of software design. But I frequently change my mind when someone questions my ideas, because it’s just code.
Providing an alternative voice
I once worked for a guy who classified software developers into two groups: those that got it and those that didn’t. Of course, getting it was solely defined by him. But I like that description. Each of us finds somethings come naturally. For some of my colleagues, developing complex algorithms comes easily. For me, my brain overheats and melts down if I have to think up anything more complicated than a basic sort algorithm.
But I feel obliged to provide an alternative to “expert advice” which I consider plain wrong. Maybe I’ll succeed. Maybe I won’t.
But at least there’s a comment box on the bottom of each page where you can point out my (many) mistakes.
5 Comments
What exactly is wrong about the statement about interfaces? I’d say they certainly play a large role in multiple-inheritance structures in Java.
Simon, Java and C# don’t support Multiple Inheritance at all. Instead they support single inheritance and interfaces.
Inheritance in the Object Oriented world is a form of code re-use. Take a quick glance at Inheritance (object oriented programming), Wikipedia. On the other hand, Interfaces are a promise to support the same behaviour. Also see Interface (computer science), Wikipedia, without the baggage of a particular implementation.
C++ supports Multiple Inheritance but doesn’t really support Interfaces. We mimic them using a class having only pure-virtual functions and no member variables. In contrast, Java and C# support Interfaces but don’t support Multiple Inheritance.
Objective-C supports Interfaces but not Multiple Inheritance, but it also supports the ability to dynamically extend any class using Categories. You can also completely replace method implementations using Categories. It’s very cool.
Javascript actually supports a limited form of Multiple Inheritance. Inside a constructor, if you call another constructor function the new object will inherit any properties and methods defined in that constructor. However, the new object will not inherit methods defined in the second constructor’s prototype chain. For example:
Any instances of
TestMultipleInheritancewill possess properties fornameandsize. In addition, eachTestMultipleInheritanceobject will have a unique copy of theinflatemethod (because it was allocated in the constructor), and will inherit via the prototype chain thegetNamemethod ofFirstConstructor.You’ll only ever be able to tell that a
TestMultipleInheritanceobject is also aFirstConstructorobject using theinstanceofoperator. Without additional hackery, there’s no way to tell whether objects are alsoSecondConstructorobjects. And in fact,TestMultipleInheritanceobjects aren’t entirelySecondConstructorobjects because they are lacking thedeflatemethod.I know this is a contrived example, but I think it illustrates the point. I’ve never actually needed to use Multiple Inheritance in Javascript, and Javascript doesn’t support Interfaces.
ah, ok now I understand your point – The author of the article shoudn’t have said “most modern languages (c#, java) implement this” since they don’t implement it. I immediately read ‘implement’ as ‘mimic’ I think.
The author would have been correct in saying that the way c# and java mimic multiple inheritance is by using interfaces (and delegation of course), wouldn’t he?
Thanks for the javascript example – I doubt I’ll ever need it but it’s always good to learn something. :-)
I’m not certain you can actually mimic Multiple Inheritance, because the inheritance aspect is the key to the whole thing. With Interfaces you are promising to support the same methods (and something like the same behaviour), but you have to do all the work yourself.
With Multiple Inheritance there’s no need to promise, the object does support the same methods and you get the implementation for free.
I doubt if anyone has a really good reason to do even the slightly crippled Multiple Inheritance from my example. I know I’ve never needed it in almost a decade of writing Javascript.
um.. you CAN mimic multiple inheritance in Java.
interface Cat { void meow(); }
class CatImpl implements Cat { public void meow(){} }
interface Dog { void bark(); }
class DogImpl implements Dog { public void bark(){};
class DogCat extends CatImpl implements Dog { private Dog dog = new DogImpl();
public void meow() { super.meow(); //I know this isn’t necessary..for clarity
public void bark(){ dog.bark(); } }
In what way is this NOT multiple inheritance? And you can see with this example why MI can be a bad thing…Exactly what is a DogCat?