| SitePoint Sponsor |
Hello
We could use an abstract class here but we use an interface because it allows more flexibility.
May you tell me advantages of using interface instead of abstract class?
(By code ,Please)
Of course what you posted was interesting,But my discussion is:
What are advantages of using interface instead of Multiple inheritance?
Ok?
It seems what you posted is about multiple interfaces.
Thanks
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.
Because PHP does not support multiple inheritance:Originally Posted by abalfazl
But this does work:PHP Code:abstract class AbstractBaseOne {
abstract function do_this();
}
abstract class AbstractBaseTwo {
abstract function do_that();
}
class Concrete extends <no way to extend AbstractBaseOne and AbstractBaseTwo > {
function do_this() {
echo "this";
}
function do_that() {
echo "that";
}
}
PHP Code:interface AbstractBaseOne {
function do_this();
}
interface AbstractBaseTwo {
function do_that();
}
class Concrete implements AbstractBaseOne, AbstractBaseTwo {
function do_this() {
echo "this";
}
function do_that() {
echo "that";
}
}
Beyond the conceptual simplicity of interfaces, I can't think of any advantages.What are advantages of using interface instead of Multiple inheritance?
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.
Douglas
Hello World
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.
That was the answer,clear and nice,Thanks BerislavLopac
But please explain for me that :
What are advantages of using interface instead of abstract class?
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.
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.
Hello firends
I read this article and someparts of this article aren't clear to me:
http://c2.com/cgi/wiki?ConfusionAboutInheritance
May someone explain more about that?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
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
delegating behavior to a derived class ?
May someone give me example for these three statements?
Good Luck
I think this message sums it up pretty well: http://mumble.net/~jar/articles/oo.htmlMay someone explain more about that?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
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).
Hello
Interesing article:
http://www.artima.com/designtechniques/compoinh.html
Good luck
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.
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
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.
Interfaces in php are useful for reflection-related tasks, for example when creating service object without knowing class name:
PHP Code:$klass = find_class_that_implements("MailFunctions");
$mailer = new $klass;
Can you give an example of a find_class_that_implements implementation?
Douglas
Hello World
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.
It strikes me that statically checking interfaces in a dynamically typed language is misguided, a better solution than copying Java would have been to use dynamic interfaces.
You don't need to statically declare an interface, you can dynamically compare method signatures. Example:
You don't need "implements IEngine" if you compare interfaces instead of types.PHP Code:interface IEngine
{
function start();
}
class Engine
{
function start() { /* ... */ }
}
class Car
{
function Car ( IEngine $engine )
{
# works, as Engine::start() exists...
}
}
</rant off>
Douglas
Hello World
Interesting, I'm not sure I want the initialization of classes to be based on the order of my requires though
Douglas
Hello World
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").
PHP Code:
// extreme primitive
// Reflection-based improvements possible
function supports($klass, $interface) {
return !array_diff(
get_class_methods($interface),
get_class_methods($klass)
);
}
// usage
interface IEngine {
function start();
function rattle();
function stop();
}
// note there is no "implements" clauses
class GoodEngine {
function start(){}
function rattle() {}
function stop(){}
}
class FaultyEngine {
function start(){}
function stop(){}
}
function letsDrive($something) {
if(!supports($something, 'IEngine'))
return print "no valid engine";
print "here we go.........";
$something->start();
$something->rattle();
$something->stop();
}
letsDrive(new GoodEngine());
letsDrive(new FaultyEngine());
Right, but there must be a reason why they introduced intefaces... I'm just searching for it.Interesting, I'm not sure I want the initialization of classes to be based on the order of my requires though
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.
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.
Later,
Douglas
Hello World
That's exactly my point. If you don't want a fatal, you have to check contracts before engine does this for you.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.
I'd say it's pretty much common. It's really frustrating to see zends hunting corporate money instead of improving engine and language itself.It might be a bit cynical, but here's my theory:
Well, it seems that the whole typing/inheritance concept is just a bit obsolete.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
with builtin lexer this shouldn't be that hard...I wonder if there is a way to write a preprocessor for PHP,
nonot sure it's worth the work though.
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.
Yer, I made a note of that myself, and started a thread about it a while back. For example, with PHP you can't do this, as you can in JavaIf you don't want a fatal, you have to check contracts before engine does this for you.
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?PHP Code:class ClickMe {
public function __construct() {}
public function doesNotThrowAnException( IResponse $response ) throws IllegalParameterException {
// ... if not typeof IResponse, then throw an exception
// ... as apposed to dying with an error
}
// ... rest of class
}
What are you saying?
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
Douglas
Hello World
Posting Permissions
Bookmarks