The Javascript object model is quite different and interesting, definitely worth a look if only to see what an alternative to traditional OO looks like. Check out prototypal and parasitic inheritance.
Daniel Haransays:
Amen! Duck Typing is awesome. It took me a while to figure out that objects don’t all have to inherit from a class or implement some interface.
I think part of the reason inheritance gets overused is that too much emphasis is placed on it when OO programming is taught. The ubiquitous Shape inheritance diagram springs to mind.
Java’s analogue to C++’s templates is generics. That’s a whole different can o’ worms but, used sparingly, can also help avoid large, smelly inheritance diagrams.
I’ve heard Daniel’s advice phrased slightly differently: “Prefer has-a over is-a”. The main advantage of composition over inheritance is that you are more free to modify the implementation of a class that uses another class. Delegation methods and adaptors are easy to write and make your code modular and maintainable.
If you extend from a class you’re pretty much stuck with the parent’s class implementation unless you start overriding everything which defeats the purpose of inheritance anyway.
My rule of thumb when considering `B extends A` is to pause and ask, “is B really an A under all possible interpretations or am I just trying to be ‘clever’ and avoid writing a few extra lines of code?”.
Manuel Simonisays:
I consider myself a cool programmer and well, I sometimes do use inheritance, even though I agree that it is a somewhat problematic language feature.
As an example, I recently wrote a web app that produced, among other things, a lot of different Atom feeds.
There, it made sense to create a Feed superclass, that provides some Atom-specific functionality and then derive Feed subclasses that implement the meat of the functionality.
In this case, inheritance is nothing more than a mechanism for code reuse, and I think its use is warranted.
OTOH, if I had used a language with generic procedures (methods outside classes), I probably wouldn’t have used inheritance, but rather simple, duck-typed generic procedures.
Kevembuanggasays:
In some cases I still favor “cowboy programming” on bare metal 🙂
Depends on what kind of job of course but anyway I think functional programming (Haskell) has more potential than OO though I am not really used to it.
I always found that OO was a half baked idea.
I think i only half agree with you on this one. I think most professional programmers discover that it’s too hard to create and maintain deep type hierarchies, but i also think there are certain cases where classic OO polymorphism is pretty “cool”.
I agree that inheritance isn’t cool, but sometimes it’s necessary. This is especially true when you want to override some behaviour and the language you are using doesn’t have a meta-object protocol.
The Javascript object model is quite different and interesting, definitely worth a look if only to see what an alternative to traditional OO looks like. Check out prototypal and parasitic inheritance.
Amen! Duck Typing is awesome. It took me a while to figure out that objects don’t all have to inherit from a class or implement some interface.
[Duck.new, Dog.new, Visitor.new].each {|e| puts e.some_method_they_all_declare }
Some related advice is “Favor composition over inheritance”. Deep inheritance graphs are a code smell.
I think part of the reason inheritance gets overused is that too much emphasis is placed on it when OO programming is taught. The ubiquitous Shape inheritance diagram springs to mind.
Java’s analogue to C++’s templates is generics. That’s a whole different can o’ worms but, used sparingly, can also help avoid large, smelly inheritance diagrams.
I’ve heard Daniel’s advice phrased slightly differently: “Prefer has-a over is-a”. The main advantage of composition over inheritance is that you are more free to modify the implementation of a class that uses another class. Delegation methods and adaptors are easy to write and make your code modular and maintainable.
If you extend from a class you’re pretty much stuck with the parent’s class implementation unless you start overriding everything which defeats the purpose of inheritance anyway.
My rule of thumb when considering `B extends A` is to pause and ask, “is B really an A under all possible interpretations or am I just trying to be ‘clever’ and avoid writing a few extra lines of code?”.
I consider myself a cool programmer and well, I sometimes do use inheritance, even though I agree that it is a somewhat problematic language feature.
As an example, I recently wrote a web app that produced, among other things, a lot of different Atom feeds.
There, it made sense to create a Feed superclass, that provides some Atom-specific functionality and then derive Feed subclasses that implement the meat of the functionality.
In this case, inheritance is nothing more than a mechanism for code reuse, and I think its use is warranted.
OTOH, if I had used a language with generic procedures (methods outside classes), I probably wouldn’t have used inheritance, but rather simple, duck-typed generic procedures.
In some cases I still favor “cowboy programming” on bare metal 🙂
Depends on what kind of job of course but anyway I think functional programming (Haskell) has more potential than OO though I am not really used to it.
I always found that OO was a half baked idea.
I think i only half agree with you on this one. I think most professional programmers discover that it’s too hard to create and maintain deep type hierarchies, but i also think there are certain cases where classic OO polymorphism is pretty “cool”.
Java’s analogue to C++’s templates is generics
Java generics may look like C++ templates, but they are very different maintenance and performance-wise.
I agree that inheritance isn’t cool, but sometimes it’s necessary. This is especially true when you want to override some behaviour and the language you are using doesn’t have a meta-object protocol.