Difference between extending and implementing

gerryjuice

Wondering if anyone could give me a quick explanation into the difference between extending an interface and implementing an interface.

Hobbes

[edit]

You can extend an interface, you can only implement it within a class though.

Extending is for putting more functionality into an existing class/interface.

Implementing is more as a contract for your class/interface. It allows other classes to know how to talk to your class.

causal

A class can implement an interface (or several interfaces)
An interface can extend another interface (or several interfaces)

causal

tempest

causal wrote:

A class can implement an interface (or several interfaces)
An interface can extend another interface (or several interfaces)

causal

who says theres no multiple inheritance in Java ??

It's an interesting thing though implementing multiple interfaces as it raises all sorts of issues regarding the context of an operation name.

WARNING: considerable amount of personal opinion and completely Off Topic
Interfaces are used for lots of things they shouldn't be really. For example why is Serializable an interface. It doesn't define type. It defines a property of the object. It does not represent an "is a" relationship. You cannot say a Person is a Serializable. You can say that the data inside a Person object can be converted into a stream of bytes and reassembled from that stream of bytes.

I guess in general if the interface says "able" at the end it's not really defining type, but it's so common nowadays it's almost used without thinking.

Just because it makes the implementation generic doesn't make it right..

bonkey

tempest wrote:

Interfaces are used for lots of things they shouldn't be really.

Agreed, but I don't like your example

For example why is Serializable an interface.

Because thats the right way to implement serialization?

t does not represent an "is a" relationship.

Yes it does, just in a slightly abstract manner.

You cannot say a Person is a Serializable.

No, you would say that an instance of the Person class is a serializable object, or that the person class is a Serializable class.

Regardless, English grammar does not define what is and is not an interface.

I guess in general if the interface says "able" at the end it's not really defining type, but it's so common nowadays it's almost used without thinking.

It depends on how you define what you mean by type. If you mean in strict hierarchical terms of abstraction (a 205 is a type of Peugeot which is a type of car which is a type of vehicle), then sure...its not a type.

But thats not the only meaning of type.

Ever tried explaining to someone the difference between applications and data on a computer? Ultimately, what does it boil down to if not that there are two types of file - those than can be executed, and those that cannot. So, this gives us an executable type.

Just because it makes the implementation generic doesn't make it right..

I would look at it the other way around. Just because inheritance can be used to define hierarchical abstraction, doesn't mean its not right to use it for other purposes as well.

I can see no more elegant solution to the notion of abstract, common ability then the use of an interface. And if something is the most elegant solution to a problem, there should need to be a damn good reason not to use it, other than the notion that "but this isn't really what we wanted this to be used for in the purest sense".

jc

stevenmu

I tend to think of implementing interfaces as being descriptive but extending a class is definitive, my grammer's probably wrong there but basically one describes a class/object the other partly defines it. I don't think that even in english you could say they are both "is a" relationships. Using the Person/Serializable example, you could say "X is a Person", because person is a noun but you couldn't say "X is a Serializable" because serializable is an adjective. I suppose you could say "X is Serializable" which might make implementing an "is" relationship and extending an "is a" relationship.

For the OP, the quick way is that extending gives your class all the properties of the class you extend from. Other objects which know how to make use of the class you extend from can also then make use of your class. Implementing an interface forces you to implement it's properties in your class. Any other objects which can use objects that implement the interface can use your class aswell.

aspnet

An interface is a definition of behaviour....
Extending the interface is changing the definition of that behaviour.
Implementing an interface is filling in the details of that behaviour.

Hobbes

Someone give aspnet a cookie.

oscarBravo

[php]setcookie('aspnet', 'Nicely explained!');
echo $_COOKIE; [/php]

tempest

Didn't get back to this as I was away for cúpla lá.

aspnet wrote:

An interface is a definition of behaviour....
Extending the interface is changing the definition of that behaviour.
Implementing an interface is filling in the details of that behaviour.

Kind of true, but extending an interface can't change the definition of the behaviour, otherwise the contract of the original interface is broken when an instance of a sub interface implementation is treated as an instance of the super interface implementation.

If the expected behaviour of the interface changes then the interface needs to change completely, and this is not a valid use of extends.

Extension should only be used to add behaviour and not to modify existing behaviour.

bonkey wrote:

Agreed, but I don't like your example

Bad example

My main gripe with serializable is that it is used as a marker interface. It doesn't define the way that an object is Serializable, just that you can reflect me and turn my data into bytes then convert me back into myself. I don't argue that serialization is a bad thing, because it is not, just that the implementation is flawed. A serializable keyword would be considerably more appropriate, but I guess we need to live with the language the way that it is. It is essentially a hack, IMHO.

bonkey wrote:

Regardless, English grammar does not define what is and is not an interface.

Agreed, but it does provide a hint, because it is indicative of how humans think and the context with which we view the world (although it should remain a hint).

bonkey wrote:

Ever tried explaining to someone the difference between applications and data on a computer? Ultimately, what does it boil down to if not that there are two types of file - those than can be executed, and those that cannot. So, this gives us an executable type.

Or it makes it a command, and a command can be executed. Thereby making executable a property of the command. Once again it comes down to your view of things, and your level of abstraction. There is no right or wrong answer to things like this, but it's all good.

bonkey wrote:

I would look at it the other way around. Just because inheritance can be used to define hierarchical abstraction, doesn't mean its not right to use it for other purposes as well.

Inheritance can be used for many other things besides hierarchical abstraction. I don't argue against that, but the fact remains that the purpose of and reasoning for inheritance is to define such notions and as such using it for other purposes is counter intuitive. Relatively new approaches are arriving which would allow for these kinds of representations in a more intuitive manner. AOP for example, when used correctly, provides a powerful new alternatives, and in particular could potentially be applied to the Serialization process.

bonkey wrote:

I can see no more elegant solution to the notion of abstract, common ability then the use of an interface. And if something is the most elegant solution to a problem, there should need to be a damn good reason not to use it, other than the notion that "but this isn't really what we wanted this to be used for in the purest sense".

I couldn't agree more, but we should also be looking at why we are not using it as intended, and how we can abstract it into a concept for future use, be it a design pattern or a language paradigm which can be used in the future.

aspnet

Your are right.

Extending an interface is a difficult one to explain in one sentance without elaborating too much or giving examples ( interfaces are used in other programming languages besides java ).

tempest

aspnet wrote:

( interfaces are used in other programming languages besides java ).

True and where they are not present in the language they can be emulated using existing constructs as in C++ where you would use a class consisting solely of pure virtual functions.

The one thing that is constant in the paradigm is that the interface defines the contract which must be followed by the implementation.