Interfaces and abstract class inheritance, implementation in extended classes

Question

In every example I've seen, extended classes implement the interfaces of their parents. For reference, the following example:

interface MyInterface{
    public function foo();
    public function bar();
}

abstract class MyAbstract implements MyInterface{
    public function foo(){ /* stuff */ }
    public function bar(){ /* stuff */ }
}

// what i usually see
class MyClass extends MyAbstract implements MyInterface{}

// what i'm curious about
class MyOtherClass extends MyAbstract{}

Is failure to implement an interface in a child, which is implemented by a parent, considered bad practice or something? Are there any technical drawbacks to omitting the implementation in the child?

@Gordon - No sir, I have not. So I assume you typically omit the interface from child class declarations. — Dan Lugg, Jun 16 '11 at 08:41
yes, exactly. The child will implement that interface anyway. See http://codepad.org/OTZ2J5kB — Gordon, Jun 16 '11 at 08:52

score 23 · Accepted Answer · answered Jun 16 '11 at 08:41

23

I would consider that you are on the right path. There is no need to declare that you are implementing the interface, when extending a class that already implements it. For me it's just another piece of code to maintain if change is needed. So, yes, you are correct!

answered Jun 16 '11 at 08:41

Emil Ivanov

37,300
12
75
90

Thanks **Emil Ivanov**; That's what I assumed. I haven't worked much with interfaces (*beyond SPL, et al.*) and am beginning to incorporate them into my projects, as more and more of my code will be touched by client programmers. My main concern was if any changes to inheritance could occur due to omission. – Dan Lugg Jun 16 '11 at 08:44

Shef · Answer 2 · 2011-06-16T09:02:33.880

Is failure to implement an interface in a child, which is implemented by a parent, considered bad practice or something? Are there any technical drawbacks to omitting the implementation in the child?

I just can't answer your question better than this guy has:

By their nature, although sometimes they may look quite similar, abstract classes and class interfaces serve very distinct purposes.

The interface of a class is meant as a tool for the "user" of that class. An interface is a public presentation for the class, and it should advertise, to anyone considering to use it, what methods and constants are available and accessible from the outside. So, as it name suggests, it always sits between the user and the class implementing it.

On the other hand, an abstract class is a tool aimed at helping the "implementor" of the classes that extend it. It is an infrastructure that can impose restrictions and guidelines about what the concrete classes should look like. From a class design perspective, abstract classes are more architecturally important than interfaces. In this case, the implementor sits between the abstract class and the concrete one, building the latter on top of the former.

Reference

Thus, it's up to you to decide, based on who is going to use (instantiate) your classes, and who is going to write them. If you are the sole user and writer of your classes, then, maybe, just maybe, you don't need them both. But, if you want to give everyone a stripped down to core bits blueprint for the class writer(s) and class user(s), then you should consider using both abstracting and implementing.

Valentine Shi · Answer 3 · 2019-04-11T07:09:42.090

Maybe a little late to the table but I see the above comments do not clarify the main misunderstanding underlying the OP's question.

So the underlying questions are:

Why we use both an Abstract class and an Interface on the same line?
Should both an Abstract method and an Interface declare the same methods at all?

But before some clarifications why to use either of the two above:

Either of them are used by one programmer to define the contract (requirements, obligations, limitations) the other programmers have to obey when they create the concrete classes (and eventually entire software application) based on Abstract classes / Interfaces developed by that programmer.
An Abstract class, in turn, is used to provide the later created concrete class with methods & data structures blueprint via:
1. data structures declarations (optional),
2. base implementation of methods (and their signatures, optional)
3. just methods declarations (similar to an Interface usage, optional).
An Interface is used to provide a concrete class with a methods blueprint via
1. just methods (and their signatures, optional) declarations.

Here is an example for an Abstract and concrete classes.

abstract class MyAbstractClass {

    public function foo() {
        // Base implementation of the method here.
    }

    public function bar() {
        // Base implementation of the method here.
    }

    // Effectively similar to baz() declaration within some interface:
    public abstract function baz($value);

}

class MyConcreteClass extends MyAbstractClass {

    // foo() and bar() are inherited here from MyAbstractClass.

    // baz() must be implemented or declared abstract again.
    public function baz($value) {
        // implementation.
    }

}

Then the questions come:

Why we need an Interface here?
Do we need an Interface to duplicate same method declarations?

The answers:

Due to the fact that PHP allows only single inheritance for each subclass (you cannot write class MyConcreteClass extends MyAbstractClass, MyAnotherClass {}), when we need to expand the concrete class functionality beyond the already used Abstract class we have to declare this additional functionality via one or more Interfaces.

Like this:
```
class MyConcreteClass 
    extends MyAbstractClass 
    implements MyInterface, MyAnotherInterface {
    // Methods and data implementations go here.
}
```
As the result from the answer 1, an Interface better not to duplicate an Abstract class methods' declarations (this is basically useless). An Interface(s) should decalre the methods that may help to enhance the concrete (or another Abstract class, why not) functionality to provide the programmer that will use these with the firm contract for each object built on top of these classes and interfaces.

Finally, answer to the the OP question whether to use an Interface for an Abstract class or for the concrete class is:

use for either or both (or as needed) as long as an Interface enhances a class contract with new methods' declarations.

score 0 · Answer 4 · answered Feb 05 '18 at 08:43

Well, I was confused too, but I think you should use the latter one, You are right, If you implement the interface in the abstract class, then there is no need to write the interface, you can write the method in interface all into abstract as abstract methods, because you will extend the abstract class whatever, and you will have to use the abstract class as a param type when you use the class in other place, that's not a good thing, I think an abstract class should't be used as a param type, while an interface should be.

score 0 · Answer 5 · answered Jun 16 '11 at 08:45

Is failure to implement an interface in a child, which is implemented by a parent, considered bad practice or something?

The child always implements the interface, it can not go around with this.

I have no clue if that is bad practice or something. I would say it's a language feature.

Are there any technical drawbacks to omitting the implementation in the child?

You can not test the reflection of the abstract class for having the interface for example.

However, abstract class are already an interface, so technically they themselves not really need the interface but you can do so to keep things fluid within the inheritance.

Interfaces and abstract class inheritance, implementation in extended classes

5 Answers5

Linked