Page 2 of 2

Re: Question about Interfaces

Posted: Wed Oct 28, 2009 10:36 am
by alex.barylski

Code: Select all

It is precisely the fact that interfaces don't have code that makes it possible for objects to inherit from multiple interfaces
Yes and no.
http://ca.php.net/interfaces wrote:A class cannot implement two interfaces that share function names, since it would cause ambiguity.
The difference is due to the way polymorphism works (which uses late call binding):

http://blogs.msdn.com/davidklinems/arch ... nding.aspx

Whereas interfaces are probably checked at compile-time, and therefore the ambiguity is detected. At least I think this is how it works in less dynamic languages, like C++.
C++ does it. I think that's what ~arborint was getting at. Multiple inheritance isn't at all necessary
C++ does MI but it also comes with the diamond of death problem:

http://www.codeproject.com/KB/architect ... bject.aspx

Which is what PHPHorizonswas getting at.
Useful for content URLs, user profile URLs, etc. However, you don't want it to be a global function. In order to include it in only a few classes, you would need an external "formatting" dummy class, or to re-implement the method in all of the classes that need it. That, or make it into a global function. Multiple inheritance lets you write the code once and give it to any class that needs it.
You can achieve the same effect using single inheritence. :P

MI is appealing to most developers for all the wrong reasons, in fact most of the time I have ever wanted to use it, what I really wanted was a mixin, because the MI class was essentially acting as an adapter for two or more classes, not actually needing to take advantage of multiple "inheritence" in and of it's self.

Cheers,
Alex

Re: Question about Interfaces

Posted: Wed Oct 28, 2009 12:35 pm
by superdezign
PCSpectra wrote:You can achieve the same effect using single inheritence. :P
Unrelated classes shouldn't have the same parent class. Multiple inheritance, in practice, is basically a faster way to implement a decorator design pattern.

Re: Question about Interfaces

Posted: Wed Oct 28, 2009 1:11 pm
by Jenk
Composite pattern is the better solution, in my humble opinion. Particularly with Traits (where Traits are implemented well within a language.)

Multiple inheritance is also not something that is always desired, but in most cases, something that is required. I've hit multiple inheritance many times through necessity, over design/desire. Simplest example I can think of, was when needing to Combine the behaviour of a Stream with that of a Collection, into one object. In the end a Decorator was used, but Decorator's are smelly, and in most cases, only temporary.

Re: Question about Interfaces

Posted: Wed Oct 28, 2009 1:45 pm
by Christopher
FYI - Traits are coming to PHP.

Re: Question about Interfaces

Posted: Wed Oct 28, 2009 2:22 pm
by PHPHorizons
PCSpectra wrote:
http://ca.php.net/interfaces wrote:A class cannot implement two interfaces that share function names, since it would cause ambiguity.
I missed that and never had a "gotcha moment" to clue me in. Thanks for the clarification PCSpectra. ;)

Re: Question about Interfaces

Posted: Wed Oct 28, 2009 4:01 pm
by alex.barylski
Unrelated classes shouldn't have the same parent class. Multiple inheritance, in practice, is basically a faster way to implement a decorator design pattern.
Which is exactly why MI is a bad idea as it`s often misused as an adapter. If your after common functionality, then a properly designed single parent class hierarchy along with IoC (or perhaps a composite) would result in much more flexible design. The distinction between a decorator and MI is an important one, IMHO:
http://en.wikipedia.org/wiki/Decorator_pattern wrote:The decorator pattern is an alternative to subclassing. Subclassing adds behaviour at compile time
Cheers,
Alex