This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of DevSecOps Adventures: A Game-Changing Approach with Chocolate, LEGO, and Coaching Games and have Dana Pylayeva on-line!
See this thread for details.
  • 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
  • Ron McLeod
  • Paul Clapham
  • Devaka Cooray
  • Tim Cooke
Sheriffs:
  • Rob Spoor
  • Liutauras Vilda
  • paul wheaton
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Mikalai Zaikin
  • Carey Brown
  • Piet Souris
Bartenders:
  • Stephan van Hulst

father & mother class

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All

Forgive me if this question sounds frivolous to you OO gurus.

In Java say I have 2 classes (father & mother)

Now I want 2 create a child class which has all the functionalities of both the parent classes
As Java does not support multiple inheritance how can we get around this problem

Rgrds
Rahil
 
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
 
Ranch Hand
Posts: 154
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Rahil

As far as I am aware (I stand to be corrected) the way most people do it is via delegation.

i.e your child class would hold say the mother class as an instance attribute

The child class would define methods with the same signature as those you
need from the mother class.

These methods would "delegate" calls to the mother class

i.e

child method

public void doSomething(){
getMother().doSomething();
}

Where getMother() returns an instance of the mother class held as an attribute of the child class.

This is admittedly tedious because for every method in the mother class that you need, you have to define a "delegation" method in the child class.

Also as opposed to inheritence adding a new method to the mother doesn't automatically propogate to the child class.

You could still inherit normally from the father class and delegate to the mother class.

Not that elegant a solution but its the one I've seen most used.

There's some blurb here which may help



web page


web page
 
Graham VMead
Ranch Hand
Posts: 154
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OOps Slight error, the methods you define on the child need not be the same signature but they do still delegate. As far as I'm aware this is an example of the "adapter" pattern.

There's some stuff in my previous post links about dynamic proxies which may cut the tedium but I haven't used these myself.
 
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
With all this Object Oriented Bureaucracy it seems that we have lost to plot completely. It might be worth stepping back and think about what you are trying to do. Maybe you don't need Mother and Father classes. Can these objects be better represented Relationally, using simple data types in container classes or you can put Father and Mother code into one class.

Parent =new Parent(�Mother�) /** or new Parent(�Father�) **/

This is my favourite way to represent these objects because having Mother and Father specific code in one place can help plenty because it is easier to spot reuse potential.

Some time the Mother and Father methods are the same, sometimes they are completely different other times they are neither so you might need couple of IF statement to factor out code that are not the same.
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Gerald has a good point.

Should there be a Parent class that has the all the method that the child could need, and then Father and Mother could extend the Parent class, and override the methods it does not need with blank implementation, then the child can extend Parent and get all the methods.

Personally, I don't feel too good about the above way, and like the delegation way better, if this is indeed the design needed.

Its like you want the child to get both parents gene pool and combine them into one. It is almost like it should be upside down.

Mark
 
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
helloooow!!! The Adapter Pattern!!!
 
Gerald Davis
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
person = new Person(�Child�) /** person = new Person(�Mother�) or new or person(�Father�) **/

Sorry, I ment do it this way. This way the entities Mother, Father, and Child is hidden behind the Person class.So these entities can be implemented simple data types or with the 3 classes without effecting client code.
I don't have to tell you the benefits of datahiding.
 
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 Gerald Davis:
Some time the Mother and Father methods are the same, sometimes they are completely different other times they are neither so you might need couple of IF statement to factor out code that are not the same.



Or you avoid the if statement(s) and do it the *really* OO way:

mother = new Person(new MotherBehaviour());
father = new Person(new FatherBehaviour());
child = new Person(new CompositeBehaviour(new MotherBehaviour(), new FatherBehaviour()));

Of course this only works well if all three instances need the same interface - and it might actually be overkill in simple cases. In other situations, it might well save the maintainability of your system!
 
Gerald Davis
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:


Or you avoid the if statement(s) and do it the *really* OO way:

mother = new Person(new MotherBehaviour());
father = new Person(new FatherBehaviour());
child = new Person(new CompositeBehaviour(new MotherBehaviour(), new FatherBehaviour()));

Of course this only works well if all three instances need the same interface - and it might actually be overkill in simple cases. In other situations, it might well save the maintainability of your system!



I make a terrible habit of resigning my application, so I like to expose the end developer to less objects as possible in this case, only the the Person object. I am sure that should the IF statement be a bad thing, I can change the implementation without the end user ever knowing about it. Indeed I figured that it would be possible to use Hashtable without any trouble. Your example forces the design more or less in stone, hence it becomes inflexible.

Maybe the difference between Mother and Father is so small that it isn't worth creating two different Classes, but use only one, however conceptionally it might still wise represent them as Mother or Father. Again my example allowed this.


/** Less verbose way combining mother and father together **/
child = new Person(�Mother,Father�);
[ January 12, 2005: Message edited by: Gerald Davis ]
 
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

Originally posted by Gerald Davis:
I make a terrible habit of resigning my application, so I like to expose the end developer to less objects as possible in this case, only the the Person object.



I can resonate with that feeling. Actually if I were to publish the API to an outside team, I might not even expose the Person class, but only an interface.

OTOH sometimes it might be desirable to give clients the ability to provide Person instances with their own Behaviour implementations. This has to be decided on a case by case basis.

Inside the team, though, I prefer the practice of Collective Code Ownership, therefore nothing ever is cast in stone. In that case, I wouldn't worry about providing a facade, unless it would the code much more expressive.


/** Less verbose way combining mother and father together **/
child = new Person(�Mother,Father�);



I'd actually prefer something along the lines of

child = PersonFactory.create(Type.MOTHER, Type.FATHER);

then (using the vararg feature of Tiger).
 
Graham VMead
Ranch Hand
Posts: 154
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Seems like horses for courses to me, depends on

1) If you just want to present one object type i.e Person : I Prefer the passing of a behaviour object in to the constructor rather than a "String".

2) How much the interfaces of child/mother/father vary otherwise with the Person() approach you may end up implementing a few methods that do nothing in the specific behaviour objects, or conditional logic in the Person class.

Both approaches, delegation or Person(behaviour) seem ok to me and I would personally decide dependent on what I was trying to use the child/mother/classes for.
 
I hired a bunch of ninjas. The fridge is empty, but I can't find them to tell them the mission.
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic