I have been trying to learn OOP using PHP5 and I am having trouble wrapping my head around a couple of things.
First; I am understanding Inheritance in OOP, but what I am not understanding in PHP is why I can only use extends once to extend a parent class. I have been doing some reading online and a few times I have seen where it is not good practice to use extends more than once, that's why it's not available, is this true?
Second; Abstract vs. Interface, I read a way to Inherit one class many times is to use Interface and or Abstract. Is this correct?
Third; I am writing a very simple class using Inheritance and I am having a problem understanding how to properly contruct it. I have looked thru php.net and OS and have seen many classes and how they are written, but could anyone take the time to write a simple example in PHP using .... let's say a mammal class as the parent class and have dog, cat, and bear and the child classes.
I know I could find something online that has already been written, but this way I can converse with the person who wrote the class.
First; I am understanding Inheritance in OOP, but what I am not understanding in PHP is why I can only use extends once to extend a parent class. I have been doing some reading online and a few times I have seen where it is not good practice to use extends more than once, that's why it's not available, is this true?
In short: Its just a design decission from the PHP core developers. Multiple inheritance brings up many questions, for example what should happen, when two parent classes implements the same method? To avoid such conflicts some languages decide to not support it (e.g. Java too ;)). There is no real downside in it.
Second; Abstract vs. Interface, I read a way to Inherit one class many times is to use Interface and or Abstract. Is this correct?
You can extend every class as much as you like. There is no limitation neither for classes, abstract classes, nor interfaces. However, its possible to implement (implements keyword) more than one interface into one class.
Third; I am writing a very simple class using Inheritance and I am having a problem understanding how to properly contruct it. I have looked thru php.net and OS and have seen many classes and how they are written, but could anyone take the time to write a simple example in PHP using .... let's say a mammal class as the parent class and have dog, cat, and bear and the child classes.
abstract class Mammal {}
class Dog extends Mammal {}
class Cat extends Mammal {}
class Bear extends Mammal {}
Yes it's true PHP only officialy supports extending one class at a time, its a bug bear to all OOP because there's no good OOP reason not to be able to but there is for the language. It's also true you can circumvent it, not recommended however because it's not supported by the language for a reason (I forget now).
Not sure what you mean by versus, Abstract classes are classes that should be abstracted before using them. Think of them as 80% complete classes, there are a few functions missing for it to work which must be implemented on a per application level.
Interfaces are the kind of bones of a class, there's no functionality there but all functions are defined. They aren't to be extended or used they are to be referenced against.If a class implements and interface it commits to implement all the function stated in the interfaces (and possibly more) and PHP throws an error if that's not the case.
A very simple example
class Mammal{
function getBones(){}
}
class Dog extends Mammal{
function bark(){}
}
class Cat extends Mammal{
function meow(){}
}
$d = new Dog()
$d->bark()
//Works
$d->getBones()
//works
$d->meow()
//does not work, is a cat function
I think you are talking about Multiple Inheritance? Technically, it's a design decision of the PHP developers. There are other languages which allow it.
Multiple inheritance has some technical problems (Diamond Problem), but there is a good theoretical argument against it: A class should have one responsibility (Single Responsibility Principle, it talks of "object" because there are classless yet object-oriented languages). Two different classes usually have different responsibilities, so if a class inherits from both of them, it would have two responsibilities, violating the SRP.
See Search for "abstract class interface" – use interface to define the methods a class must implement to satisfy a contract, use abstract class if you want to partially implement something (usually an interface).
Impossible, because you did not say which aspects of the mammals should be modeled. Without knowing that, it would even be impossible to know if different mammal classes or a common base class are needed.
Related
I know this is very repetitive question i also read most of the post but not found the satisfactory answers. I know the bookish difference which i read from most of the posts.
Can any one please tell me
why we use abstract class and interface?
when we use this one?
i know that when we have some repeated task but implementing in a different way each time then we use abstract class.
i think we can implement this by a normal class and subclass using overriding then why we use abstract? also their is a difference of access specifier between abstract class and interface as well as the compulsion of implementation in interface.
Interface is quite acceptable that when we want to force to implement all method in that situation we use interface but why abstract class? Is compulsion of implementation is just a difference?
thanks in advance.
Beautifully explained here - https://www.codeproject.com/Articles/11155/Abstract-Class-versus-Interface
In a nutshell,
Interfaces are used to define the peripheral abilities of a class. In other words both Human and Vehicle can inherit from a IMovable interface.
An abstract class defines the core identity of a class and there it is used for objects of the same type.
Also take a look at https://msdn.microsoft.com/en-us/library/scsyfw1d(v=vs.71).aspx
Here are some recommendations to help you to decide whether to use an interface or an abstract class to provide polymorphism for your components.
If you anticipate creating multiple versions of your component, create an abstract class. Abstract classes provide a simple and easy way to version your components. By updating the base class, all inheriting classes are automatically updated with the change. Interfaces, on the other hand, cannot be changed once created. If a new version of an interface is required, you must create a whole new interface.
If the functionality you are creating will be useful across a wide range of disparate objects, use an interface. Abstract classes should be used primarily for objects that are closely related, whereas interfaces are best suited for providing common functionality to unrelated classes.
If you are designing small, concise bits of functionality, use interfaces. If you are designing large functional units, use an abstract class.
If you want to provide common, implemented functionality among all implementations of your component, use an abstract class. Abstract classes allow you to partially implement your class, whereas interfaces contain no implementation for any members.
Consider this.
An interface has no implementation. It forces prototypes onto a class but does not help implementing them.
An interface is not tied to a class hierarchy. You can apply the same interface to multiple, entirely different class trees. This is important and one of the things that an interface offers over an abstract class. An interface is implementation independent, you can "slap it onto" any class. This is the most powerful aspect of an interface.
So, I am starting to gasp the concept of abstract and interface in PHP.
But when is it really ever useful?
Sure I can with an interface make up the rules for my classes, so they all follow a specific pattern. But when is it really useful?
And why should I make an abstract class instead of just making a class that works by it own but is useful for other classes.
Abstract I perhaps can put my head around and see a good use, for example by making a general class. Like making a abstract Database class, then extending it onto a Mysql- and a MsAccess database class. Giving both similar functions to work with, allowing seamless experience in both cases.
But really, could anyone give me a better example of when abstract and interface are really useful?
And please note, I do know how it works, or how to write the code, just not how or when to use it.
Thanks!
Abstract means "here is a pattern for your class, and some code that can start you off". The designer of the abstract class can mark some methods as needing to be provided by the extending class (abstract), or as final, which means the class can't override them.
Interface means "here is a pattern for your class, but you have to write all the code yourself". Any methods and properties declared in the interface must be provided by the class that implements the interface.
So essentially a rule of thumb will be:
If you have code that can or must be used by the descendant classes, you need an abstract class. If you only have method and property declarations, you can use an interface.
Don't forget, using abstract classes limits you to some extent, because a descendant class can only extend one class, whereas it can implement any number of interfaces.
An interface is not a class, while an abstract class is already a class.
As every class has an interface (by definition), the interface allows you to specify an interface next to any class, be it abstract or not.
Programming against interfaces then allows you to replace one class with another one while keeping the same interface. So it makes your code less coupled. It's not programmed against concrete classes any longer but "only" against more lightweight interfaces. An interface then is useful if you don't want to program against concrete class names but against types. You can replace an object then with any other object that implements the same interface.
An abstract class on the other hand - even called abstract - is pretty concrete. However, it's not final, so it forms a pattern of a class, like a specification how a class that extends from it should be written for a certain functionality. As it's abstract, it can't come to live without extending from it. Abstract classes are used to create base classes with code that will be used more than once to reduce code duplication and not being able to instantiate directly.
An interface works like a contract. If a class implements an interface, other code that uses this class now knows it supports certain features.
The best example of an interface in PHP is the Iterator interface.
The benefit of interfaces is that classes can implement multiple. 'Extending' does not allow this. This means that a subclass can implement an interface, but it's parent doesn't have to.
Read up on design patterns. A lot of this you'll find covered, and you'll never have doubt again in which cases it makes sense. 'Head first design patterns' I thought to be a good book, very nicely written. Although they use Java in their examples, most stuff is very much applicable in PHP.
I have one more real-life scenario.
Our application always throws exceptions everywhere whenever an error occurs. Every type of exception gets its custom class. An example of this is a RecordNotFound exception.
If exceptions are not caught, there's a top-level exception block, which looks a bit like this:
try {
// Do everything in the app!
} catch (Exception $e) {
// draw a good error page
}
In some cases exceptions need to be mapped to certain HTTP status codes, such as 404 (not found). Therefore we have this interface:
interface HTTPException {
function getHTTPCode();
}
any exception, no matter how deep in the inheritance tree can now implement this interface and emit a specific HTTP status code.
I even created interfaces, without any methods. I'll leave it to you to try to think of a reason why that may makes sense.
Interface is nothing but the skeleton structure of a class and it is not class. we can just implement that class and add some extra feature to make more clear. The implements keyword can be used for interface .In general way implement is used in interface to implementing the features.
abstract is a class which hides some of features and only just shows the necessary features. Extend keyword can be used for abstract class. In general ways extends can be used to extends the features of abstract class.
I have a confusion in why we use abstract classes or interfaces to implement or extend. interfaces doesn't contain any code so does the abstract methods. then why we use them. why don't we directly create methods and define them in our class rather we use interfaces or abstract classes. they don't contain any sort of code, we need to define them after extending them in our class. why we don't define these methods in our own class rather extend interfaces and then define them. I found such type of question asked several times in stackoverflow but couldn't understand the answer. can anyone please explain it in some simple way
The power of abstraction and interfaces comes from the fact that you can separate responsibilities and write modular code: One part of your (or someone else's) code may only care that you have an Animal and provide facilities to deal with Animals, without needing to know how they move or feed. A different part of your code may only care about defining lots of concrete animals, like Dogs, Birds, etc., with all the details of how they actually implement all their features.
By making the concrete classes (Dog, Bird, ...) extend a common, abstract interface (Animal), you can use a any now and future concrete class in a library written for the abstract interface -- you don't need to ask the library author to change the library to accommodate new Animals, and the library author doesn't need to know how features are concretely implemented.
For example, if you had two single algorithm, FeedBreakfast and FeedDinner, that would require a member function Animal::gobble(), then without inheritance you would need to implement each algorithm for each animal - i.e. you'd end up with M * N amount of code! By using a common, abstract interface you reduce this to M + N -- M algorithms and N concrete classes, and neither side needs to know of the other -- they just both need to know the interface.
Statically typed languages need to use this method to enable polymorphism. That is, you can write your code in terms of your abstract base class. Then you can "plug" in any subclass as an extension. This is called Liskov Substitution principle, or Open/Closed principle. Technically, this is called dynamic binding. That is, the method to call is selected during runtime depending on the subclass.
With dynamically typed languages the situation is completely different. I don't know if PHP is dynamically typed (I suspect it is), but in Ruby or Javascript, for example, you can program in terms of any object that conforms to a specific interface. That is, if your code expects an object that has a method called Print you can substitute with any other object that also has a Print method, without deriving from a common base class. The method will be looked up during runtime, that is why these languages are called "dynamic".
Hope this helps!
You use abstract classes or interfaces when you want to establish a protocol.
It sounds simple, but it's a very powerful concept. If you are forced to adhere to rules, then you cannot break them. If you cannot break the rules, you adhere to the protocol. Therefore, all the classes that implement your interface should inherently be compatible with each other. Naturally, there are exceptions among human kind who are able to break these rules by creating code that even interpreters cry when they have to parse it but that's a bit of an offtopic :)
For an interface, imagine you have a Class called "Message". This implements the Interface called SendMessage, which has a method definition of Send.
If you then create two subclasses of "Message". One could be "Email" and one could be "InstantMessage".
Now these both have the method Send(), which is defined in the SendMessage interface, and are blank. This now allows you to define differently what the Send() method does. However, because we know the classes Email, and InstantMessage use the interface SendMessage, we know that they both have the method Send();
So you could call Email.Send(), and InstantMessage.Send(), but do two different things. An interface defines methods available to several objects, but with the same method name.
Abstract classes/interfaces are mostly design time considerations. By defining methods as abstract and therefore the classes as abstract too.. we are ensuring that these methods will definitely be implemented by deriving classes. If they do not implement them they also become abstract.
Interfaces provides the luxury of distributing the must implement methods into different categories, so the required number of interfaces can be implemented.
the abstract classes guarantee that can't be instantiate, this is because are a generalization. for example,
in a game, exist a class player, but also exist classes defender and forward. the class player is the parent class of both classes. not is practice create a object player, because a team need a especific player.
The interfaces are related with polymorphism. every class, use methods according to its behavior.
i hope this help you
The idea behind an abstract class is that you can define some common functionality of a set of similar classes, but leave other details up to the implementing (extending) classes. In a way they are similar to interfaces, except that you can actually implement some of the functions in the abstract class.
But what's the point, I hear you ask? Well, you only have to write the common code once, although you can do this in a concrete (non-abstract) base class too. But also you may not want other programmers to instantiate the base class, so this is where the real power of abstract classes come in.
Let me show an example to help illustrate my point. Imagine you are writing a program to classify all of the animals in a zoo. Animals can be classified into certain types, bird, reptile, mammal, insect, arachnid, fish, etc, and then down to their species such as dog, cat, parrot or kangaroo. The base class, Animal, can provide some of the common functionality to all of these. It might have a function called eat() which all animals do in a similar way and so the function is written out to describe the process of an animal eating. It might contain another function, walk(), but this one is abstract, since different animals will implement this in a different way. All subclasses of the Animal class will need to implement this method.
The major bonus of this is that somewhere in your code you can call a function that takes an Animal as a parameter. You know that you can call the eat() and walk() functions on this parameter because all Animals can eat and walk. This is called polymorphism and is an important trait of Object Oriented Programming.
I hope this has helped you. Please feel free to discuss or ask further questions if you still can't see the value of abstract classes.
I've faced a situation when I want to extend two parent classes, but php does not allow this.
Why I can't extend more than one class, but can implement more than one interface. What's wrong with extending many classes?
It seemed to me like a pretty obvious thing, until I got parse errors.
Is it a bad practice? If so, what are the alternatives?
Is it possible in other languages?
Why multiple inheritance is forbidden in some/most programming languages is argued with the diamond problem http://en.wikipedia.org/wiki/Diamond_problem.
Put simple if you have a car that can swim and drive because it inherits from vehicle and boat what happens on execution of the move function!?
Try using interfaces and follow the Strategy pattern or State pattern.
You're probably looking for: Multiple Inheritance in PHP.
It seems to be possible in Python.
Take a look at Can I extend a class using more than 1 class in PHP?
Is it a bad practice? If so, what are alternatives?
Unless the language is specifically designed for it, yes. Consider, you have two classes, A and B. Both classes provide a public method foo() which have identical signatures (not hard in PHP). Now, you make a class C which extends both A and B.
Now, you call C.foo(). Without explicit instructions, how does the interpreter know which version of foo() to call?
It's not supported by PHP. It can however be simulated using runkit, APD or by just overriding __call and __get to simulate inheritance from multiple classes. Symfony (and I seldomly recommand that) also provides "sfMixin" or "sfMixer" for multiple inheritance.
Separate classes implementing the same method is not a good argument against multiple inheritance, as currently multiple interfaces can be implemented. You just can't implement two interfaces with the same method. Quote from http://www.php.net/manual/en/language.oop5.interfaces.php: "A class cannot implement two interfaces that share function names, since it would cause ambiguity."
I know this question is 2 years old but I've only just had the same problem. My work-around is this: if you have one regular class and two abstracts and want to extend both, e.g abstract class AbstractOne and abstract class AbstractTwo, you can say:
abstract class AbstractOne extends AbstractTwo {
}
Then add to the main class like this:
class MyMainClass extends AbstractOne {
}
This way, it inherits both AbstractOne and AbstractTwo.
Interfaces allow you to create code which defines the methods of classes that implement it. You cannot however add any code to those methods.
Abstract classes allow you to do the same thing, along with adding code to the method.
Now if you can achieve the same goal with abstract classes, why do we even need the concept of interfaces?
I've been told that it has to do with OO theory from C++ to Java, which is what PHP's OO stuff is based on. Is the concept useful in Java but not in PHP? Is it just a way to keep from having placeholders littered in the abstract class? Am I missing something?
The entire point of interfaces is to give you the flexibility to have your class be forced to implement multiple interfaces, but still not allow multiple inheritance. The issues with inheriting from multiple classes are many and varied and the wikipedia page on it sums them up pretty well.
Interfaces are a compromise. Most of the problems with multiple inheritance don't apply to abstract base classes, so most modern languages these days disable multiple inheritance yet call abstract base classes interfaces and allows a class to "implement" as many of those as they want.
The concept is useful all around in object oriented programming. To me I think of an interface as a contract. So long my class and your class agree on this method signature contract we can "interface". As for abstract classes those I see as more of base classes that stub out some methods and I need to fill in the details.
Why would you need an interface, if there are already abstract classes?
To prevent multiple inheritance (can cause multiple known problems).
One of such problems:
The "diamond problem" (sometimes referred to as the "deadly diamond of
death") is an ambiguity that arises when two classes B and C inherit
from A and class D inherits from both B and C. If there is a method
in A that B and C have overridden, and D does not override it, then
which version of the method does D inherit: that of B, or that of C?
Source: https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem
Why/When to use an interface?
An example... All cars in the world have the same interface (methods)... AccelerationPedalIsOnTheRight(), BrakePedalISOnTheLeft(). Imagine that each car brand would have these "methods" different from another brand. BMW would have The brakes on the right side, and Honda would have brakes on the left side of the wheel. People would have to learn how these "methods" work every time they would buy a different brand of car. That's why it's a good idea to have the same interface in multiple "places."
What does an interface do for you (why would someone even use one)?
An interface prevents you from making "mistakes" (it assures you that all classes which implement a specific interface, will all have the methods which are in the interface).
// Methods inside this interface must be implemented in all classes which implement this interface.
interface IPersonService
{
public function Create($personObject);
}
class MySqlPerson implements IPersonService
{
public function Create($personObject)
{
// Create a new person in MySql database.
}
}
class MongoPerson implements IPersonService
{
public function Create($personObject)
{
// Mongo database creates a new person differently then MySQL does. But the code outside of this method doesn't care how a person will be added to the database, all it has to know is that the method Create() has 1 parameter (the person object).
}
}
This way, the Create() method will always be used the same way. It doesn't matter if we are using the MySqlPerson class or the MongoPerson class. The way how we are using a method stays the same (the interface stays the same).
For example, it will be used like this (everywhere in our code):
new MySqlPerson()->Create($personObject);
new MongoPerson()->Create($personObject);
This way, something like this can't happen:
new MySqlPerson()->Create($personObject)
new MongoPerson()->Create($personsName, $personsAge);
It's much easier to remember one interface and use the same one everywhere, than multiple different ones.
This way, the inside of the Create() method can be different for different classes, without affecting the "outside" code, which calls this method. All the outside code has to know is that the method Create() has 1 parameter ($personObject), because that's how the outside code will use/call the method. The outside code doesn't care what's happening inside the method; it only has to know how to use/call it.
You can do this without an interface as well, but if you use an interface, it's "safer" (because it prevents you to make mistakes). The interface assures you that the method Create() will have the same signature (same types and a same number of parameters) in all classes that implement the interface. This way you can be sure that ANY class which implements the IPersonService interface, will have the method Create() (in this example) and will need only 1 parameter ($personObject) to get called/used.
A class that implements an interface must implement all methods, which the interface does/has.
I hope that I didn't repeat myself too much.
The difference between using an interface and an abstract class has more to do with code organization for me, than enforcement by the language itself. I use them a lot when preparing code for other developers to work with so that they stay within the intended design patterns. Interfaces are a kind of "design by contract" whereby your code is agreeing to respond to a prescribed set of API calls that may be coming from code you do not have aceess to.
While inheritance from abstract class is a "is a" relation, that isn't always what you want, and implementing an interface is more of a "acts like a" relation. This difference can be quite significant in certain contexts.
For example, let us say you have an abstract class Account from which many other classes extend (types of accounts and so forth). It has a particular set of methods that are only applicable to that type group. However, some of these account subclasses implement Versionable, or Listable, or Editable so that they can be thrown into controllers that expect to use those APIs. The controller does not care what type of object it is
By contrast, I can also create an object that does not extend from Account, say a User abstract class, and still implement Listable and Editable, but not Versionable, which doesn't make sense here.
In this way, I am saying that FooUser subclass is NOT an account, but DOES act like an Editable object. Likewise BarAccount extends from Account, but is not a User subclass, but implements Editable, Listable and also Versionable.
Adding all of these APIs for Editable, Listable and Versionable into the abstract classes itself would not only be cluttered and ugly, but would either duplicate the common interfaces in Account and User, or force my User object to implement Versionable, probably just to throw an exception.
Interfaces are essentially a blueprint for what you can create. They define what methods a class must have, but you can create extra methods outside of those limitations.
I'm not sure what you mean by not being able to add code to methods - because you can. Are you applying the interface to an abstract class or the class that extends it?
A method in the interface applied to the abstract class will need to be implemented in that abstract class. However apply that interface to the extending class and the method only needs implementing in the extending class. I could be wrong here - I don't use interfaces as often as I could/should.
I've always thought of interfaces as a pattern for external developers or an extra ruleset to ensure things are correct.
You will use interfaces in PHP:
To hide implementation - establish an access protocol to a class of objects an change the underlying implementation without refactoring in all the places you've used that objects
To check type - as in making sure that a parameter has a specific type $object instanceof MyInterface
To enforce parameter checking at runtime
To implement multiple behaviours into a single class (build complex types)
class Car implements EngineInterface, BodyInterface, SteeringInterface {
so that a Car object ca now start(), stop() (EngineInterface) or goRight(),goLeft() (Steering interface)
and other things I cannot think of right now
Number 4 it's probably the most obvious use case that you cannot address with abstract classes.
From Thinking in Java:
An interface says, “This is what all classes that implement this particular interface will look like.” Thus, any code that uses a particular interface knows what methods can be called for that interface, and that’s all. So the interface is used to establish a “protocol” between classes.
Interfaces exist not as a base on which classes can extend but as a map of required functions.
The following is an example of using an interface where an abstract class does not fit:
Lets say I have a calendar application that allows users to import calendar data from external sources. I would write classes to handle importing each type of data source (ical, rss, atom, json) Each of those classes would implement a common interface that would ensure they all have the common public methods that my application needs to get the data.
<?php
interface ImportableFeed
{
public function getEvents();
}
Then when a user adds a new feed I can identify the type of feed it is and use the class developed for that type to import the data. Each class written to import data for a specific feed would have completely different code, there may otherwise be very few similarities between the classes outside of the fact that they are required to implement the interface that allows my application to consume them. If I were to use an abstract class, I could very easily ignore the fact that I have not overridden the getEvents() method which would then break my application in this instance whereas using an interface would not let my app run if ANY of the methods defined in the interface do not exist in the class that implemented it. My app doesn't have to care what class it uses to get data from a feed, only that the methods it needs to get that data are present.
To take this a step further, the interface proves to be extremely useful when I come back to my calendar app with the intent of adding another feed type. Using the ImportableFeed interface means I can continue adding more classes that import different feed types by simply adding new classes that implement this interface. This allows me to add tons of functionality without having to add unnecessarily bulk to my core application since my core application only relies on there being the public methods available that the interface requires so as long as my new feed import classes implement the ImportableFeed interface then I know I can just drop it in place and keep moving.
This is just a very simple start. I can then create another interface that all my calendar classes can be required to implement that offers more functionality specific to the feed type the class handles. Another good example would be a method to verify the feed type, etc.
This goes beyond the question but since I used the example above:
Interfaces come with their own set of issues if used in this manner. I find myself needing to ensure the output that is returned from the methods implemented to match the interface and to achieve this I use an IDE that reads PHPDoc blocks and add the return type as a type hint in a PHPDoc block of the interface which will then translate to the concrete class that implements it. My classes that consume the data output from the classes that implement this interface will then at the very least know it's expecting an array returned in this example:
<?php
interface ImportableFeed
{
/**
* #return array
*/
public function getEvents();
}
There isn't much room in which to compare abstract classes and interfaces. Interfaces are simply maps that when implemented require the class to have a set of public interfaces.
Interfaces aren't just for making sure developers implement certain methods. The idea is that because these classes are guaranteed to have certain methods, you can use these methods even if you don't know the class's actual type. Example:
interface Readable {
String read();
}
List<Readable> readables; // dunno what these actually are, but we know they have read();
for(Readable reader : readables)
System.out.println(reader.read());
In many cases, it doesn't make sense to provide a base class, abstract or not, because the implementations vary wildly and don't share anything in common besides a few methods.
Dynamically typed languages have the notion of "duck-typing" where you don't need interfaces; you are free to assume that the object has the method that you're calling on it. This works around the problem in statically typed languages where your object has some method (in my example, read()), but doesn't implement the interface.
In my opinion, interfaces should be preferred over non-functional abstract classes. I wouldn't be surprised if there would be even a performance hit there, as there is only one object instantiated, instead of parsing two, combining them (although, I can't be sure, I'm not familiar with the inner workings of OOP PHP).
It is true that interfaces are less useful/meaningful than compared to, say, Java. On the other hand, PHP6 will introduce even more type hinting, including type hinting for return values. This should add some value to PHP interfaces.
tl;dr: interfaces defines a list of methods that need to be followed (think API), while an abstract class gives some basic/common functionality, which the subclasses refine to specific needs.
I can't remember if PHP is different in this respect, but in Java, you can implement multiple Interfaces, but you can't inherit multiple abstract classes. I'd assume PHP works the same way.
In PHP you can apply multiple interfaces by seperating them with a comma (I think, I don't find that a clean soloution).
As for multiple abstract classes you could have multiple abstracts extending each other (again, I'm not totally sure about that but I think I've seen that somewhere before). The only thing you can't extend is a final class.
Interfaces will not give your code any performance boosts or anything like that, but they can go a long way toward making it maintainable. It is true that an abstract class (or even a non-abstract class) can be used to establish an interface to your code, but proper interfaces (the ones you define with the keyword and that only contain method signatures) are just plain easier to sort through and read.
That being said, I tend to use discretion when deciding whether or not to use an interface over a class. Sometimes I want default method implementations, or variables that will be common to all subclasses.
Of course, the point about multiple-interface implementation is a sound one, too. If you have a class that implements multiple interfaces, you can use an object of that class as different types in the same application.
The fact that your question is about PHP, though, makes things a bit more interesting. Typing to interfaces is still not incredibly necessary in PHP, where you can pretty much feed anything to any method, regardless of its type. You can statically type method parameters, but some of that is broken (String, I believe, causes some hiccups). Couple this with the fact that you can't type most other references, and there isn't much value in trying to force static typing in PHP (at this point). And because of that, the value of interfaces in PHP, at this point is far less than it is in more strongly-typed languages. They have the benefit of readability, but little else. Multiple-implementation isn't even beneficial, because you still have to declare the methods and give them bodies within the implementor.
Interfaces are like your genes.
Abstract classes are like your actual parents.
Their purposes are hereditary, but in the case of abstract classes vs interfaces, what is inherited is more specific.
I don't know about other languages, what is the concept of interface there. But for PHP, I will try my best to explain it. Just be patient, and Please comment if this helped.
An interface works as a "contracts", specifying what a set of subclasses does, but not how they do it.
The Rule
An Interface can't be instantiate.
You can't implement any method in an interface,i.e. it only contains .signature of the method but not details(body).
Interfaces can contain methods and/or constants, but no attributes. Interface constants have the same restrictions as class constants. Interface methods are implicitly abstract.
Interfaces must not declare constructors or destructors, since these are implementation details on the class
level.
All the methods in an interface must have public visibility.
Now let's take an example.
Suppose we have two toys: one is a Dog, and other one is a Cat.
As we know a dog barks, and cat mews.These two have same speak method, but with different functionality or implementation.
Suppose we are giving the user a remote control that has a speak button.
When the user presses speak button, the toy have to speak it doesn't matter if it's Dog or a Cat.
This a good case to use an interface, not an abstract class because the implementations are different.
Why? Remember
If you need to support the child classes by adding some non-abstract method, you should use abstract classes. Otherwise, interfaces would be your choice.
Below are the points for PHP Interface
It is used to define required no of methods in class [if you want to load html then id and name is required so in this case interface include setID and setName].
Interface strictly force class to include all the methods define in it.
You can only define method in interface with public accessibility.
You can also extend interface like class. You can extend interface in php using extends keyword.
Extend multiple interface.
You can not implement 2 interfaces if both share function with same name. It will throw error.
Example code :
interface test{
public function A($i);
public function B($j = 20);
}
class xyz implements test{
public function A($a){
echo "CLASS A Value is ".$a;
}
public function B($b){
echo "CLASS B Value is ".$b;
}
}
$x = new xyz();
echo $x->A(11);
echo "<br/>";
echo $x->B(10);
We saw that abstract classes and interfaces are similar in that they provide abstract methods that must be implemented in the child classes. However, they still have the following differences:
1.Interfaces can include abstract methods and constants, but cannot contain concrete methods and variables.
2.All the methods in the interface must be in the public visibility
scope.
3.A class can implement more than one interface, while it can inherit
from only one abstract class.
interface abstract class
the code - abstract methods - abstract methods
- constants - constants
- concrete methods
- concrete variables
access modifiers
- public - public
- protected
- private
etc.
number of parents The same class can implement
more than 1 interface The child class can
inherit only from 1 abstract class
Hope this will helps to anyone to understand!