multi-inheritance
Hi experts,
Suppose I wanna design a program for a faculty,I should consider students,employees,...
but here someone could be students and employee together...
I think here I need multi-inheritance but there is no multi-inheritance,so I designed it like this,
an interface for students,a class for students,
an interface for employees,a class for employees,
another class that implements student interface and employee interface,(for those are student and employee)
I dont know whether there are better ways for this,
Thanks in advance.
[592 byte] By [
mehdi62b] at [2007-9-30 23:25:04]
Your instinct to use multiple interfaces is the right one. Normally, I do not 'combine' two interfaces into another interface unless I am at a very abstract level. It's usually easier to have the class (say EmployeeStudent) implement both. Your processing will usually inspect one interface or the other, but rarely both at the same time.
It's really a matter of personal preference. I tend to create 'flat' interface inheritance structures.
- Saish
"My karma ran over your dogma." - Anon
Saish at 2007-7-7 14:00:56 >
Thanks for the reply,
I found another design,
I can have an interface for students and a StudentClass implements StudentInterface and also an interface for employees and a EmployeeClass implements EmployeeInterface,
then I derive a class(StudentEmployee) from StudentClass and implement EmployeeInterface.I think this could be a better approach.
I dont know which one could be better?
The following may be overkill, but it illustrates how to use interface inheritance and composition to mimic multiple inheritance:
public interface IStudent {
abstract public void enroll();
}
public interface IEmployee {
abstract public double getSalary();
}
public class StudentImpl implements IStudent {
public void enroll() {
// spiffy code goes here
}
}
public class EmployeeImpl implements IEmployee {
public double getSalary() {
// semi-spiffy code goes here
}
}
Now, why go to all this trouble? StudentImpl and EmployeeImpl, while both classes, are really also delegates. Let's make the StudentEmployee:
public class StudentEmployee implements IStudent, IEmployee {
private StudentImpl student;
private EmployeeImpl employee;
public void enroll() {
student.enroll();
}
public double getSalary() {
return employee.getSalary();
}
}
Delegation and composition make the most sense when you can factor-out Student behavior into a StudentImpl class. Now, if you create multiple types of students, all can delegate the implementation to StudentImpl to satisfy the requirements of IStudent, without having to copy-paste code.
When you want to implement two interfaces, you simply delegate the calls to two helper classes. This methodology generally pays off when you have logic common to multiple classes implementing the interface. You don't necessarily want to restrict your design to use single inheritance, because you only get to do that once. Rather, free your design up by factoring-out the implementation. Now, if desired, Student could extend Observer and still gain the 'benefits' of being IStudent. If you later create HonorStudent, and the enroll() behavior is the same, you simply delegate the call to the common StudentImpl object.
public class HonorStudent extends ImportantPerson implements IStudent {
private StudentImpl studentImpl;
public void enroll() {
studentImpl.enroll();
}
// Abstract protected method from ImportantPerson
final protected void iniitateTantrum() {
// not so spiffy code here
}
}
- Saish
"My karma ran over your dogma." - Anon
Saish at 2007-7-7 14:00:56 >
At the university I went to...
University positions:
1. There was paid members of the faculty
2. There were unpaid members of the faculty
3. There were paid positions that were not faculty.
4. There were unpaid positions that were not faculty.
Student positions:
A. Students could belong to all of the above
B. Students could belong to more than one of the above.
Other relationships:
X. Faculty could be students
Y. Employees (not faculty) could be students.
Note that the other relationships really did represent something different than when a student took on the other role.
For example one student:
- Year 1/2: full time student
- Year 3: full time student, faculty (paid TA)
- Year 3 summer: full time employee (not faculty)
- Year 4: full time employee
- Year 5: full time employee, part time student
- Year 6: full time employee, part time student, unpaid teaching position.
Now you could certainly implement the 8! factorial combinations represented by the above using interfaces and combinations thereof but I suspect that that is not going be an approach that will work well.
Thank you "Saish" and "jschell" very much,I got everything perfectly :)(At the university I go to...)
> At the university I went to...
>
> University positions:
> 1. There was paid members of the faculty
> 2. There were unpaid members of the faculty
> 3. There were paid positions that were not faculty.
> 4. There were unpaid positions that were not
> faculty.
>
> Student positions:
> A. Students could belong to all of the above
> B. Students could belong to more than one of the
> above.
>
> Other relationships:
> X. Faculty could be students
> Y. Employees (not faculty) could be students.
>
Sounds like a good candidate for Decorator.
- Saish
"My karma ran over your dogma." - Anon
Saish at 2007-7-7 14:00:56 >
