aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes multi-inheritance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "multi-inheritance" Watch "multi-inheritance" New topic
Author

multi-inheritance

zb cong
Ranch Hand

Joined: Jan 14, 2002
Posts: 416
hello
in a school project,there is a "student" object that has a "score" attribute and some methods,and a "staff" object that has a "salary" attribute and special methods too,the third object is "stu_sta" which is both student and staff.it should have both "score" and "salary" attributes.

i know that java don't support multi-inheritance,it can implement multiple interfaces.but i wonder how to fulfill aforementioned scenario?

how does a child inheritant the attributes of parent INTERFACE??
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
You don't inherit attributes from an interface.

Can you tell us more about *why* you need one object that is both a student and staff?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
zb cong
Ranch Hand

Joined: Jan 14, 2002
Posts: 416
this is a school management system,in the school,there are three kinds of people,one is student,the second is staff,the third is such kind of people:they study in the school and at same time,they have job in the school too.so i need such a role that have both the features of student and staff.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Just because there is a person in the real word that is both a student and staff at the same time you don't necessarily need an object in your software system that represents both at the same time. To do that, you should have a more technical reason.

It *can* be done, but it can also become rather complex - probably more complex than you need it to be. That's why I'd rather discuss more about your requirements before going down that path...
zb cong
Ranch Hand

Joined: Jan 14, 2002
Posts: 416
do you mean that i only need one class that include all attributes of student and stuff?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
No.

Let's say there is a person with the name Jim, who is both a student and part of the school's staff.

If I understand you correctly, you would want to have an object for Jim that is both of type Student and of type Staff at the same time. Correct?

What I don't yet understand is your reason for wanting to have that object.

What if you had *two* objects in the system, one "Jim in the role of a student" and one "Jim in the role of a staff member"?

For some systems that will just work well. For others probably not. It's far from clear to me which set your system belongs to. What is it supposed *to do*?
Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 1006
    
    3
Originally posted by zb cong:

i know that java don't support multi-inheritance,it can implement multiple interfaces.but i wonder how to fulfill aforementioned scenario?

how does a child inheritant the attributes of parent INTERFACE??


Just have the new class implement both interfaces.



Notice that the fields are declared in the concrete class, not the interfaces. (Any field in an interface is automatically final.) I don't feel too bad about this, because even though the setters and getters are declared in the interfaces, the fields aren't mentioned until the concrete class provides implementations for the methods.

There, that answers your original explicit question. However Ilja's right, doing this might or might not be the best design.

Ryan
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I liked that ZB used the word "role" early on. You can change the roles an object plays without changing the type via the State pattern. If the same methods will behave differently when a person is in Student mode or Staff mode, swap in different behavior modules based on the state. The changeable methods delegate to the behavior object:

You have to switch modes with this, and you can't be both at the same time, though defining "same time" here could be very tricky.

If you need to be both at the same time or if the different roles have different methods (not just different behavior) then I'd be tempted to make a Student interface, Staff interface and an InterestingPerson interface that implements both of the others. I can easily see this happening if you have a collection of courses and each has associated people. For one course Jim is a student, for another he's an instructor.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:

If you need to be both at the same time or if the different roles have different methods (not just different behavior) then I'd be tempted to make a Student interface, Staff interface and an InterestingPerson interface that implements both of the others. I can easily see this happening if you have a collection of courses and each has associated people. For one course Jim is a student, for another he's an instructor.


Another possible solution is the Role Object pattern, which makes it possible that an object plays an arbitrary number of roles at the same time.

I'm not convinced that any of those complex solutions really is warranted in this case, though.
Gerald Davis
Ranch Hand

Joined: May 15, 2002
Posts: 872
I got to check this pattern out.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Thanks, Ilja, I hadn't seen that by that name, but I was thinking almost exactly the same thing. It's a bit strange to have to cast the roles you get from a person, but it certainly allows a lot of flexibility with good OCP.
Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 1006
    
    3
Originally posted by Ilja Preuss:


Another possible solution is the Role Object pattern, which makes it possible that an object plays an arbitrary number of roles at the same time.


I'm glad you brought this pattern up, because I've had a nagging problem with it since the first time I read it.

In the pattern (as descibed here ) the clients have to ask the ComponentCore for a particular ComponentRole object and then perform any role-specific operations on that ComponentRole.

Doesn't the fact that the client needs to know how a ComponentCore implements the different roles (as ComponentRole objects) break the whole implementation transparency concept?

Of course, what are the alternatives?
  • Try to anticipate all the possible behaviors that any role might need and implement them in the core class, even if they just forward the method calls to the roles? Ouch.
  • Define some generic method that could be a gateway to all possible behaviors... something like doOperation(String roleType, String stringArg, int intArg, Object objArg)? That's inefficient.


  • Is the Role Object pattern just an attempt to pick the least bad alternative?

    ...or am I missing some hidden elegance of the pattern?

    Ryan
    [ April 26, 2005: Message edited by: Ryan McGuire ]
    Ernest Friedman-Hill
    author and iconoclast
    Marshal

    Joined: Jul 08, 2003
    Posts: 24183
        
      34

    The Eclipse framework has a variation on the "Adapter" pattern that could be salient here. You can ask an object, or a central "AdapterFactory", for an adapter that implements some given interface in terms of a given object. What you get back depends on what code has been written, of course: you might end up with the original object, cast to that interface, or you might end up with another class that acts as a traditional adapter.

    The core of this is an "Adaptable" interface that has a method like

    Object getAdapter(Class intfce)

    You can call getAdapter() on an Adaptable and then cast the result, or you call

    Object getAdapter(Object adaptable, Class intfce)

    on the AdapterFactory.

    So you might call

    Employee emp = (Employee) AdapterFactory.getAdapter(aStudent, Employee.class);

    "emp" might be null or a null object, if the Student isn't an employee, or it might just be aStudent, which you cast, or it might be a separate EmployeeStudentAdapter class.

    This all seems rather heavyweight for the problem being discussed, though.


    [Jess in Action][AskingGoodQuestions]
    Stan James
    (instanceof Sidekick)
    Ranch Hand

    Joined: Jan 29, 2003
    Posts: 8791
    I like that. It's similiar coupling to knowing that (or asking whether) something implements an interface.
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Ernest, that sounds very similar to the Role Object pattern to me (besides the factory), though the patterns might differ in intent?
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Ilja Preuss:
    Ernest, that sounds very similar to the Role Object pattern to me (besides the factory), though the patterns might differ in intent?


    On a second thought, there is an important difference: a Role always also imlements the interface of the original base object.
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Ryan McGuire:
    In the pattern (as descibed here ) the clients have to ask the ComponentCore for a particular ComponentRole object and then perform any role-specific operations on that ComponentRole.

    Doesn't the fact that the client needs to know how a ComponentCore implements the different roles (as ComponentRole objects) break the whole implementation transparency concept?


    The way I understand the pattern, all the client needs to know about is the ConcreteRole it needs to perform its responsibility, and the Spec used to get that role. As far as I can tell, the ConcreteRole could well be an abstract class (despite its name) which just defines the additional operations provided by the role, and the client could then work with an arbitrary implementation of the role without knowing about it.

    Does that conflict with your understanding of the pattern? Or am I missing something?
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: multi-inheritance