Object-Oriented Design – Practical Differences Between Prototypal and Classical Inheritance

designinheritanceobject-oriented-design

Inheritance, Polymorphism, and Encapsulation are the three most distinct, important features of OOP, and from them, inheritance has a high usage statistics these days.
I'm learning JavaScript, and here, they all say that it has prototypal inheritance, and people everywhere say that it's something far different from classical inheritance.

However, I can't understand what's their difference from the point of practical usage? In other words, when you define a base class (prototype) and then derive some subclasses from it, you both have access to functionalites of your base class, and you can augment functions on the derived classes. If we consider what I said to be the intended result of inheritance, then why should we care if we're using prototypal or classic version?

To clear myself more, I see no difference in the usefulness and usage patterns of prototypal and classic inheritance. This results in me having no interest to learn why they are different, as they both result in the same thing, OOAD. How practically (not theoretically) prototypal inheritance is different from classical inheritance?

Best Answer

Recent blog post about JS OO

I believe what your comparing is classical OO emulation in JavaScript and classical OO and of course you can't see any difference.

Disclaimer: replace all references to "prototypal OO" with "prototypal OO in JavaScript". I don't know the specifics of Self or any other implementation.

However prototypal OO is different. With prototypes you only have objects and you can only inject objects into other objects prototype chain. Whenever you access a property on an object you search that object and any objects in the prototype chain.

For prototypal OO there is no notion of encapsulation. Encapsulation is a feature of scope, closures and first class functions but has nothing to do with prototypal OO. There is also no notion of inheritance, what people call "inheritance" is actually just polymorphism.

It does however have polymorphism.

For example

var Dog = {
  walk: function() { console.log("walks"); }
}

var d = Object.create(Dog);
d.walk();

Clearly d has access to the method Dog.walk and this exhibits polymorphism.

So actually there is a big difference. You only have polymorphism.

However as mentioned, if you desired to do so (I have no idea why you would) you can emulate classical OO in JavaScript and have access to (restricted) encapsulation and inheritance.

Related Solutions

JavaScript objects and Crockford’s The Good Parts

Encapsulation is really tricky, and probably not worth the effort in JavaScript. A method that works, and does everything you would wish (private fields, access to the superclass and private methods) would be this (probably very ugly and improvable) solution:

function SomeClass() {

    var parent = SomeSuperClass(),
        somePrivateVar;

    return Object.create(parent, {
        somePrivateVar: {
            get: function() {
                return somePrivateVar;
            },
            set: function(value) {
                somePrivateVar = value;
            }
        },
        doSomething: {
            value: function(data) {
                someHelperFunction.call(this, data);
            }
        }
    });
}

function someHelperFunction(data) {
    this.someMethod(data);
}

This sort of works, allows you to have private fields and methods and inheritance as one would expect it. However, I don't like it - but I like it the best of all possibilities you have in pure JavaScript.

If I had to start a new project with a lot of JavaScript, I probably would have a closer look at TypeScript. It improves JavaScript where necessary (IMHO), gives you static typing, inheritance, encapsulation and everything.. But is just JavaScript, after all.

Now, is it worth it? I think there are two important things to consider. Encapsulation probably helps you at development time, but certainly doesn't at runtime. I think you have to decide; Either no encapsulation and better performance, or encapsulation, not-so-beautiful code, probably a better design but some overhead at runtime.

C++ – Testing Abstract Class Behavior

As long as the functionality you'd like to test doesn't invoke any pure virtual methods and isn't overridden in subclasses, I'd stick with your bullet point number 1 - creating a test-specific subclass. You could name it Sub<ClassName> or any generic name reflecting that the subclass itself is not important.

Now if what you want to test can be altered in any way by the final concrete class, you might want to consider this :

I don't know if there's an equivalent in the C++ test framework you're using, but NUnit (and I believe JUnit) let you implement the Abstract Test pattern.

In short, you have

An abstract base test class. It contains a abstract factory method used to generate the object under test, and the test methods per se. These methods verify things that must stay true regardless of the concrete object underneath.
As many derived test classes as there are derivatives of the abstract class under test. You just have to implement the factory method here to return an instance of the derived class.

When the test runner sees a derived test class, it will automatically execute all test methods inherited from the base test class against the factory method-generated object.

Best Answer

Related Solutions

JavaScript objects and Crockford’s The Good Parts

C++ – Testing Abstract Class Behavior

Related Topic