Message Passing, Duck Typing, Object Composition, and not Inheritance
fitzgeraldnick.com
Message Passing, Duck Typing, Object Composition, and not Inheritance
1–10 of 14 posts
Re: Message Passing, Duck Typing, Object Composition, and not Inheritance
#2I've been hearing some disdain for inheritance lately for some reason. This article is filled with it. For instance:
"The beauty here is that you can reuse code without dealing with inheritance, or any sort of class-based hierarchy."
... That's the beauty? The only beauty if that you managed to avoid a feature of the language? Ouch.
I get that really dumb things can be done with inheritance, but that's true for almost any language feature. It's certainly no reason to avoid it altogether.
Re: Message Passing, Duck Typing, Object Composition, and not Inheritance
#3Sometimes, inheritance is the right tool for the job.
Sometimes, composition is the right tool for the job.
Sometimes, duck typing is the right tool for the job.
The only valid absolute is that bloggers that insist otherwise are wrong.
Re: Message Passing, Duck Typing, Object Composition, and not Inheritance
#4Inheritance is two language features in one though—It's implicit delegation and type polymorphism. Those two features need not be coupled together like that, and in fact, shouldn't in my opinion. It's not that silly things can be done with inheritance, it's more that people often use inheritance for one of two things, but rarely both: implicit delegation and type polymorphism. Pick your poison, and use the appropriate construct. I'm no fan of implicit delegation when I can get away with not having to deal with it, but I wish more languages would have an orthogonal construct for type polymorphism separate from inheritance.
Re: Message Passing, Duck Typing, Object Composition, and not Inheritance
#5What I still don't get is why inheritance in OO-languages is always the heavyweight version, namely subclassing.
Imho every class definition in Java-like OO languages should create two types: A (by default) public interface and a (by default) private class.
When you want to inherit from something you should then be able to choose if you want to inherit only the interface or inherit from the full class. Every good design already separates interface from implementation, so why isn't it enforced at the object system layer?
Re: Message Passing, Duck Typing, Object Composition, and not Inheritance
#6Sometimes, inheritance is the right tool for the job. Sometimes, composition is the right tool for the job. Sometimes, duck typing is the right tool for the job. The only valid absolute is that bloggers that insist otherwise are wrong.
Indeed.
I recently replaced a containment relationship with an inheritance relationship.
Sometimes inheritance does make sense yet despite it being the least-bad "tool for the job", it seems awkward, fragile and ill-thought-out. You have some attributes hidden in the parent and attributes right there in the child. The idea that the ontological relationships "is-a", "has-a" etc should map cleanly to the class as buckets-of-functions-and-attributes isn't always correct and muddies the water IMHO.
I wish that there was something that worked like inheritance but was better. Perhaps a system of passing interfaces from objects to the object they contain would make things clearer and more flexible.
Re: Message Passing, Duck Typing, Object Composition, and not Inheritance
#7Inheritance is two language features in one though—It's implicit delegation and type polymorphism. Those two features need not be coupled together like that, and in fact, shouldn't in my opinion. It's not that silly things can be done with inheritance, it's more that people often use inheritance for one of two things, but rarely both: implicit delegation and type polymorphism. Pick your poison, and use the appropriat…
You express the situation quite well here.
Are there any languages that do separate implicit delegation and type polymorphism?
Re: Message Passing, Duck Typing, Object Composition, and not Inheritance
#8Seems a lot like Go (http://golang.org).
See http://golang.org/doc/effective_go.html#interfaces_and_types and http://golang.org/doc/effective_go.html#embedding.
Re: Message Passing, Duck Typing, Object Composition, and not Inheritance
#9Inheritance is two language features in one though—It's implicit delegation and type polymorphism. Those two features need not be coupled together like that, and in fact, shouldn't in my opinion. It's not that silly things can be done with inheritance, it's more that people often use inheritance for one of two things, but rarely both: implicit delegation and type polymorphism. Pick your poison, and use the appropriat…
You express the situation quite well here. Are there any languages that do separate implicit delegation and type polymorphism?
Go does. See my other comment in this thread: http://news.ycombinator.net/item?id=2058963.
Re: Message Passing, Duck Typing, Object Composition, and not Inheritance
#10Sometimes, inheritance is the right tool for the job. Sometimes, composition is the right tool for the job. Sometimes, duck typing is the right tool for the job. The only valid absolute is that bloggers that insist otherwise are wrong.
Indeed. I recently replaced a containment relationship with an inheritance relationship. Sometimes inheritance does make sense yet despite it being the least-bad "tool for the job", it seems awkward, fragile and ill-thought-out. You have some attributes hidden in the parent and attributes right there in the child. The idea that the ontological relationships "is-a", "has-a" etc should map cleanly to the class as bucke…
"a system of passing interfaces from objects to the object they contain"
How is this not inheritance? You still have some attributes "hidden" in the contained object and some "right there" in the child.