I have a number of situations where I have some BaseInterface that gets implemented by a bunch of objects. These objects also typically should implement interfaces such as Serializable or Counatble. Now it's unclear to me on when to have these additional interfaces be specified as being implemented by the classes implementing BaseInterface or when it's better to have BaseInterface extend these additional interfaces. I am looking for an overview of the implications of either approach, and a set of simple rules by which one can determine which approach should be taken in a given situation.
To increase clarity, I provide a simple example in code of both approaches:
Approach 1: Extend the base interface
interface BaseInterface extends Countable, Serializable {}
class Implementation implements BaseInterface{}
Approach 2: Implement the individual interfaces in the implementations
interface BaseInterface {}
class Implementation implements BaseInterface, Countable, Serializable {}
It seems that often one want to be able to assume something implementing BaseInterface is Countable, though OTOH this might not be needed and hinder implementation of BaseInterface where implementing Countable is simply not needed. Then there is also the interface segregation principle, which makes me wary of extending interfaces as in approach 1.
Note: This question is on where to put the interface implementation clause. It is not about code sharing via inheritance.
I propose a solution:
interface BaseInterface {}
abstract class AbstractBase implements BaseInterface {}
abstract class AbstractBaseCountable implements BaseInterface, Countable {}
abstract class AbstractBaseCountableSerializable implements BaseInterface, Countable, Serializable {}
class Implementation extends AbstractBase/* OR AbstractBaseCountable
OR AbstractBaseCountableSerializable */ {}
Thus, it may create classes with each of the different desired characteristics. Moreover, in certain implementations are abstract classes, so that the implementation classes are cleaner.
Related
What is difference between Abstract method in abstract class and Interface method in interface PHP ?
Note: I am not asking difference between Abstract class and Interface. I am asking only methods.
The following is my understanding of why they exist and how they can be useful. The are the same in general. They exist to give flexibility for better OOP design in my mind.
Interface methods must be implemented by any class implementing the Interface.
The same way abstract methods must be implemented by any class that extends the abstract class.
A class can implement multiple Interfaces but can only extend one class (abstract or concrete).
It is possible to have multiple implementation of an Interface with
different behaviors.
It is also possible to implement an Interface in abstract. That is, providing boiler plate for implementation of an Interface with most common methods implemented (at least with default behavior) and leave the implementation of the rest of the Interface methods to concrete class. This abstract implementation though can force the concrete class to implement some abstract methods (on top of Interface methods). These abstract methods may not necessarily be required for other implementations of the same Interface and should not be enforced by the Interface so they should not be in the Interface.
Does ArrayAccess extend Traversable? The man pages for each make no mention of the other. The ArrayAccess page does not indicate that it extends Traversable, but it doesn't explicitly deny it either. I ask because I have code that could take either Traversable or ArrayAccess, and I want to make sure that I need to test for both.
Short answer No.
for what you need you can use arrayiterator http://php.net/manual/en/class.arrayiterator.php
Interfaces do not implement each other "it extends."
Interfaces are made to implemented or extended by developer through interface / abstract classes / classes.
interfaces are contracts that some code implements and adheres to and
other code depends upon. It allows us to have assurance that any given
dependency will implement the methods we expect. Even further, with
the upcoming PHP 7, we can also use type hints (object and scalars)
and return types to further ensure that concrete implementations
adhere to the contracts.
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.
Using PHP 5.5, if I specify a hierarchy of interfaces and a parallel hierarchy of classes, I end up with child classes that inherit a certain type via more than one relationship. Does this suggest poor design? Can it create problems?
For example, see the code:
interface foo {}
interface bar extends foo {}
class myFoo implements foo {}
class myBar extends myFoo implements bar {}
In this example, myBar inherits the type 'foo' via two relationships:
It inherits 'foo' from it's concrete parent (myFoo)
It inherits 'foo' from the interface which it implements (bar)
The reason that I have a 1-to-1 relationship between interfaces and classes is so that I can substitute proxies and mocks for concrete classes at a granular level. (All my method parameters are expressed in terms of interfaces).
I could stop using inheritance in my interfaces but this seems to go against polymorphism. In addition, it creates problems when I am using my interfaces to define method signatures (i.e. not just to establish a common type).
It doesn't really matter either way. Think of it from the perspective of the "consumer" of an interface, not from the abstract idea of the interface itself:
function (bar $bar) {
...
}
This is where the rubber meets the road with interfaces. All this function is interested in is an object which has methods which conform to the methods defined in the bar interface. It doesn't care how exactly this object implements these methods, just that it has all the methods that interface bar defines. It also doesn't matter which methods are inherited, whether in the interface or the object. The sum aggregate of the instantiated object is all that matters.
Having said that, you may want to think about your interface and class design a little more nonetheless. What you're doing is not wrong per se, but there may be a better way to approach interfaces. Don't think of interfaces as a sketch for a class, think of interfaces as a definition of a capability. For that, again, think in terms of the consumer of such an interface. For example:
function renderThumbnail(Imaginable $item) {
printf('<img src="%s">', $item->getHighestResolutionImage()->getUrl());
}
interface Imaginable {
/**
* #return Image[]
*/
public function getImages();
/**
* #return Image
*/
public function getHighestResolutionImage();
}
This demonstrates one specific capability an object may have. Any object may have associated images. Any class implementing the Imaginable interface simply declares that it can provide an image on request. The renderThumbnail function simply needs any object which has an image. It doesn't matter what object gets passed into it, that object may implement a thousand other interfaces as well and be of any type of class, the important part is that it can do this one specific thing.
If you think about it in terms of "-able" capability interfaces, it should be obvious that you probably won't end up with two hierarchies running in parallel, and that will probably be the better design.
Abstract class abc{
---
}
I am new to OOP.I want to lean the object oriented programming concept. There is a confusion between abstract classes and interfaces. Where do we have to use this and which condition we have to you abstract and interface class. Please suggest me tutorial links so that i can easily get the functionality. Suppose we are going to drink water because i need it. This is the situation when i need water so i take water. In same case abstract and interface is needed.
An abstract class is a special kind of class that cannot be
instantiated. So the question is why we need a class that cannot be
instantiated? An abstract class is only to be sub-classed (inherited
from).
In other words, it only allows other classes to inherit from it but cannot be instantiated. The advantage is that it enforces certain hierarchies for all the subclasses. In simple words, it is a kind of contract that forces all the subclasses to carry on the same hierarchies or standards.
An interface is not a class. It is an entity that is defined by the
word Interface. An interface has no implementation; it only has the
signature or in other words, just the definition of the methods
without the body.
As one of the similarities to Abstract class, it is a contract that is used to define hierarchies for all subclasses or it defines specific set of methods and their arguments. The main difference between them is that a class can implement more than one interface but can only inherit from one abstract class. Since C# doesn’t support multiple inheritance, interfaces are used to implement multiple inheritance.
Read more - http://www.codeproject.com/Articles/11155/Abstract-Class-versus-Interface