• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Interfaces Implementation.

 
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let me start with an Example:

Let Interface class be FunBehaviour

Class GrandParent {

}
Class Parent extends Class GrandParent , implements FunBehaviour
{
// implementation of funBehaviour is done.
}
Class Child extends Parent
{
}

As per the concept, it says that even though the Child Class don't implement the FunBehaviour ,since its super class implements that behaviour , it also applies to Child.
My doubt is
In realtime , it is not compulsory that a Child must have that Behaviour..he may have RudeBehaviour irrespective of his parent..

Is there any concept in java , where the Child will not get the Behaviour of the Parent as in above case..if he doesn't posses that behaviour..

Waiting for response......
 
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is more a general issue of OO design rather than an SCJP topic. So I am moving it to a more appropriate forum.
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Does a Child inherit state and behaviour from its ancestors? Is this an appropriate model? Is FunBehaviour an appropriate inteface? I think that these are the issues that have to be discussed to answer your question.


(Sorry no time for more now, have to go to work)
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by siva prasaad:

Is there any concept in java , where the Child will not get the Behaviour of the Parent as in above case..if he doesn't posses that behaviour..



Not using inheritance - in that respect, OOD inheritance is very different from inheritance regarding creatures.

In Java, you would have to use composition instead.
 
siva prasaad
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To Barry Gant ,
As per interface, it says "It has funBehaviour method" and those who possess that character can implement that funBehaviour.

So, we observe that Child class which extends the Parent class , will get the behaviour implemented by the Parent Class as per the concept.

Is anything i missed out...please inform ,so that we will be clear..
 
siva prasaad
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To Preuss,

Can you please detail out the composition model..
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let's try and clarify some points:

The issue with "OO" inheritance being different from inheritance in creatures may be better illustrated in some more-complete code samples.

In "real life" a child inherits from a parent, but that is only a partial inheritance. The child gets neither all the genetic information of the parent, nor everything owned by the parent.

In the world of OO design (particularly in Java, but also in the majority of other languages) inheritance as a concept is much stricter. Inheritance implies that "child" inherits everything about the "parent". So much so that we can treat every child as if it is a parent. This is not the same as the "real life" example above.

In OO code would more likely say that the parent inherits from the child. This may sound backwards, but it might be useful to think of OO inheritance as an "IS A" relationship. Every person is somebodies child, even if they have since become a parent themselves. It is not true that every child is somebodies parent.



In the above example, The OO inheritance structure shows that a Parent IS A Child. But we still need to be able to get the father's name and mother's name from each child.

To do this we can use composition:



Each child has a reference to both its parents, so that when asked, it can pass on requests to that parent. This is the most basic form of composition, but composition can also be achieved with groups (such as an array or a java.util.Collection)



Is that any clearer?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We actually should distinuish between implementation inheritance and interface inheritance.

Interface inheritance is concerned with what operations can be used from outside the class. If a class inherits the interface from it's superclass, you typically want it to also be a *subtype*, conforming to Liskov's Substitution Principle. With other words, you want all clients of the superclass to be able to also use the subclass instead, without even having to know that the subclass exists. So if the superclass has FunBehaviour operations, it might be that clients rely on those operations. So to work with subclasses too, those subclasses will have to have those operations, too.

Implementation inheritance simply is a form of reuse. A class inherits some methods, but those methods don't have to become part of the visible interface - the class doesn't need to be subtype, it doesn't need to conform to LSP. Pure implementation inheritance isn't implemented in Java, though - implementation inheritance always implies interface inheritance here. It is implemented in other languages, for example in C++ via private inheritance. (I've never found someone who really missed it in Java, though.)

Does that help?
 
siva prasaad
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks to the above Authors for giving the detailed information...

Regarding Preuss, Can we say that this is one of the loop-hole in java. or the creators of Java are aware of this and due to some problems not used it in java.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As far as I can tell, the language designers of Java left out pure implementation inheritance deliberately. It's a feature that adds quite an amount of complexity to the language itself and to tools like compilers and IDEs. They probably decided that the small benefit simply wasn't worth it. In fact, as I wrote earlier, I don't know anyone who has ever complaint about it missing from Java.
 
reply
    Bookmark Topic Watch Topic
  • New Topic