The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Imagine this: classes B and C inherit class a; class D inherits classes B and C. Or, simpler: classes A and B both have a method called X; class C inherits them both, but provides no implementation for X -- which implementation should it inherit? For more on the subject, read http://en.wikipedia.org/wiki/Diamond_problem.

In effect, there is not much difference between interfaces and parent classes, except that interfaces have no implementations -- all their methods are abstract. Therefore it is possible to inherit several interfaces at once without fear of diamond of death, because you must make your own implementations anyway.

The behavior is the key word here, because it defines a class' methods -- not their implementations, but signatures, i.e. what parameters do they receive, what types do they return etc. A collection of such signatures make a type of an object, and basically this is what an interface is.

What are advantages of using interface instead of Multiple inheritance?

Beyond the conceptual simplicity of interfaces, I can't think of any advantages.

Multiple inheritance lets you include functionality in otherwise hetrogenious classes. Mixins (mixing functionality into a class) and duck typing (if it walks like a duck, and walks like a duck.. it might as well be a Duck) provide the advantages of multiple inheritance without the conceptual overhead.

PHP supports duck typing for user objects, but does not support mixins. I believe there are people working on mixin support for PHP.

That was the answer

Hello

Imagine this: classes B and C inherit class a; class D inherits classes B and C. Or, simpler: classes A and B both have a method called X; class C inherits them both, but provides no implementation for X -- which implementation should it inherit? For more on the subject, read http://en.wikipedia.org/wiki/Diamond_problem. In effect, there is not much difference between interfaces and parent classes, except that interfaces have no implementations -- all their methods are abstract. Therefore it is possible to inherit several interfaces at once without fear of diamond of death, because you must make your own implementations anyway. The behavior is the key word here, because it defines a class' methods -- not their implementations, but signatures, i.e. what parameters do they receive, what types do they return etc. A collection of such signatures make a type of an object, and basically this is what an interface is.

An abstact class implies you are using inheritance. You can only inherit from one class. You can support many interfaces.

Perhaps instead of asking about a language feature, you might try to ask about the problem you are trying to solve. I find that using composition with a design pattern like the Strategy pattern is able to solve most issues where a naieve look might have you wishing for multiple inheritance.

Basically, there is no difference between an interface and an abstract class with *all* the methods abstract. However, a class by definition *can* have implementation, at least in some methods; interfaces were introduced to prevent *any* methods from being implemented.

When you design a class, on an abstract level you don't need the implementations, only the signatures of methods -- those signatures collectively define behavior, and an object with a certain behavior is said to be of a certain type. With interfaces, you say: my class will belong to all of these types. Interfaces are more abstract than classes, even abstract classes.

May you tell me advantages of using interface instead of abstract class?

I'm just reiterating what has been said but interfaces give the flexibility of multiple inheritance without the restrictions. In the abstract class/concrete class model changes in the abstract class would have to be made in all concrete classes whereas with interfaces 'fine-tuning' changes can be made on a class by class basis.

Also since PHP knows the object is_a() type of the interface this can be used to enforce the contractual relationship between class and interface.

This article

Claiming inheritance is fundamental to OO (as is demonstratably incorrect - there are OO techniques and languages without inheritance), when its used in different ways for several different things

May someone explain more about that?

What different things are done with inheritance (and how)?

various means of polymorphism and encapsulation:
delegating state, behavior, or interface definition to a super-class, see InterfaceInheritance and ImplementationInheritance
delegating behavior to a derived class (virtual method calls)

various means of encapsulation?
delegating state, behavior, or interface definition to a super-class, see InterfaceInheritance and ImplementationInheritance

Depending on what the background of the person is, you will get different explanations and definitions of the term "Object-Oriented".
At some point this was so bad, that this paper made it into acm:http://portal.acm.org/citation.cfm?id=66469 ("My cat is object-oriented")
Though that was '89. Given the commercial success of certain OO languages in the 90's, for a lot of people their attributes are what defines OO and you'll hear less debate over it (again, depending on who you talk with).

Simplicity. If you have multiple inheritance, and you inherit from two or more classes which define the same method, which one do you use?

Java got out of that particular nightmare by providing support for interfaces, a model which PHP5 has adopted as well.

Interfaces don't really save you anything, especially considering the loosely typed nature of PHP. They ultimately add up to nothing more than syntactic sugar. Multiple inheritence wouldn't be an issue in PHP if you called parent methods by the class name rather than with parent::

Of course, you can just use composition, and avoid these nasty things altogether.

In most cases, though, the overlapping issues with MI are caused by overdoing it more than anything.

Documentation, perhaps. They don't actually do anything except in type hinting. And I'm not convinced it's a good idea to use type hints, at least until (if) we get namespace support.

As I said earlier, interfaces make no sense without type hinting, and type hinting has only a limited use without interfaces. So they need each other, but PHP could do very well without either and just go on with duck typing.

The main benefit of interfaces and type hinting in PHP is that they enforce compliance. If something is not compliant, it is known sooner rather than later. For example, if a engine is passed in to a Car (via its constructor), and it doesn't implement IEngine, then we know there is an error. If we didn't use interfaces, then the error would occur when we try to call a method we expected to be implement in the Engine, but isn't. This stops things going wrong before they do, and ensures everything is how it should be.

This helps in projects with a large amount of developers (and 3rd party code) and, as somebody already mentioned, in documentation. Also, there are other uses that seem to be more advanced options that prop up from time to time (like Dependancy Injection). Still, PHP being a weakly typed language, the uses of interfaces and Type Hinting are not as obvious as in a strongly typed langauge (like Java), where they are a neccessity.

And if it doesn't? Calling unknown method is a Fatal, i.e. there is no chance to catch it... With interfaces we can check contract assertions relatively smart (at least it's smarter than prepending each method call with "if method_exists").

And if it doesn't? Calling unknown method is a Fatal, i.e. there is no chance to catch it...

Isn't that what type hinting does at the moment? (If not, I'll have to take another look at it )

I'd rather have it throw an exception than fatal on me.

Originally Posted by stereofrog

Right, but there must be a reason why they introduced intefaces... I'm just searching for it.

It might be a bit cynical, but here's my theory: Java is statically typed, and you want to get polymorphism from more than just subclasses via inheritance, so you add interfaces (nothing wrong with that, it is just one step closer to dynamic typing). Java got "enterprise" acceptance. PHP3/4 had a poor object model (arrays), and Zend saw the $$$ so wanted to move out of small developers and into "the enterprise". They thought they'd fix their object model by making it more like an "enterprise" Java one, and so we got interfaces and type hinting.

Interfaces are great in statically typed languages, I'm not sold on them for dynamically typed languages. They feel like cruft, I might be wrong. Proove me wrong please

Using them for dependancy injection is an interesting hack, but I'd rather have real metadata. Currently I'm trying to fake that by using init methods called by ancestor classes, but I'm not loving it. Got any ideas on that? PHPDoc uses formated comments to get documentation out of the code, which is really just another type of meta-data. I wonder if there is a way to write a preprocessor for PHP, not sure it's worth the work though.

And if it doesn't? Calling unknown method is a Fatal, i.e. there is no chance to catch it... With interfaces we can check contract assertions relatively smart (at least it's smarter than prepending each method call with "if method_exists").

So this is fixing a platform issue by adding an unnecessary language issue...

Well, I guess this is what we get when we mix a platform and a language into an common lump.

I've recently discovered CherryPy, which has quite similar concepts to PHP, although based on Python. Which got me thinking about a platform which would take the concepts straight from PHP (such as $_REQUEST, $_SERVER and other suberglobals, default error reporting etc.), but use Python as the language of choice instead of PHP. I even got a name for it -- Phaeton.

Which in todays languages I would have expected at the very least as well. I would have liked to handle the error myself, surely that isn't too much to ask for huh? Huh?

What are you saying?

Originally Posted by BerislavLopac

Which got me thinking about a platform which would take the concepts straight from PHP (such as $_REQUEST, $_SERVER and other suberglobals, default error reporting etc.), but use Python as the language of choice instead of PHP.

That's one of the things Rails does for Ruby, taking a dynamic scripting language and adding web-aware features. I've not used it, but I assume Django does for Python, you should probably give it a try if you already like Python, though personally I wouldn't want to use a framework that I don't know how to pronounce! I'll have to find a Python podcast and find out