|
|
Re: Interfaces vs Inheritance (or, watch out for Go!)
|
Posted: Jan 6, 2010 9:00 PM
|
|
> I'm not convinced that interfaces are always better than
> inheritance. Here is a typical example against that
> theory:
>
> I create an interface that has two methods, I implement
> one class that is based on the interface, someone else
> implements another one. Everything works as expected. I
> find out that the interface needs a third method. I add it
> to the interface and I add to my class. The other person
> does not - BANG, I broke third party code by just changing
> my interface. The program may not even start, a VM might
> see the missing interface method and refuses to even open
> the application.
> I create no interface, but I create a class other users
> can inherit of. It has two methods that I implement.
> Someone else inherits from my class, overrides both
> methods. I decide that my class needs another method, so I
> add. The other person has not overridden it, but the
> method is there. His code may or may not work as expected,
> because he has not overridden the third method, but at
> least it will start and do something and maybe it will
> even work correctly, because there was no need to even
> override this method.
There is no such problem. I can add a third method to my *implementation* of the interface without changing the
abstract interface and the situation is the same as in
the inheritance case.
> The inability to just change interfaces as desired,
> because any change can break anything else in the world,
> has lead to the fact that interfaces can never be changed,
> once released, but are usually extended by a V2 version
> (or similar stupidity). And this is not good code or
> design IMHO.
The whole purpose of interfaces is to communicate to other people the *minimal* requirements their objects must have
to be usable by other code. Sometimes people publishes bad interfaces, right, but there is no other way to communicate, unfortunately.
Notice that even a piece of paper with the list of public methods is an interface, no need to have them in the language. Without that piece of paper/interface documentation how would you communicate?
> Another sample where inheritance is better? Okay:
>
> I write an interface and implement it in my class. Some
> other coder is quite happy with my class, there is just
> one method (out of 50) he would like to change... still,
> he cannot use my class. He either must implement all 50
> methods itself (duplicating huge amounts of my efforts) or
> he needs to encapsulate my class internally, forwarding
> all calls to 49 methods to an object of my class, except
> for one method, that he implements himself. This causes a
> speed penalty for 49 method calls (as each method call is
> just a redirection to another method call).
>
> If he inherits from my class, he can just override this
> one method, which is much less work, and there will be no
> speed penalty, because each method call goes directly to
> my method, except for the one that was overridden.
You are thinking in an inheritance-oriented way. I suggest you to study idiomatic code in languages which do not rely on inheritance and you will see that this problem in practice do not arise, since people use different designs than the template pattern. Maybe I should write a post on that, it is a common complain.
|
|
Previous Topic
