GeeCON Prague 2014*
The moose likes Java in General and the fly likes Interfaces Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Java in General
Bookmark "Interfaces" Watch "Interfaces" New topic
Author

Interfaces

Joseph Vinodh
Greenhorn

Joined: Feb 25, 2003
Posts: 11
How to implement multiple inheritance in Java through interfaces?Please give an example.
Suppose i am having a class called employee and another class supervisor. Now i would like to create a Manager class which should have both employee and supervisor + it's own attributes. How to reuse both the classes employee and supervisor in Manager class? Thanks in advance.
Joel McNary
Bartender

Joined: Aug 20, 2001
Posts: 1817

The simple answer is that you can't. The longer answer is cut-and-paste.
Java does not support multiple inheritance; that is, a class cannot inherit functionality from multiple super classes. The interface functionality provides a contract of supported methods, not an implementation of those methods.
For example, you have a Bird class, a Bat class, and an Insect class. They all would implement the Flyer interface, so that you could write a method that takes a Flyer parameter and call the fly() method of that object. But the Flyer interface cannot dictate how the implementing class flies: Insects have more wings than birds, and as such would implement the fly() method differently.
For you problem, a redesign of your classes might be more appropriate. Instead of having Manager inherit from both Supervisor and Employee, wouldn't it make more sense to have EMployee as the base class and Manager and Supervisor derive from it (after all, aren't Managers and Supervisors employees, too?) Secondly, a Manager sounds to me like a specialized type of Supervisor, so Manager should problebly extend Supervisor. What you have is:

This way you differentiate the Schleppie (common employee) from the Supervisors/Managers.


Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Going away from your question into OO concepts ... A human can be promoted from employee to manager. Can an object instance change classes? Nope!
Maybe we don't want a hierarchy at all. Maybe we want a plain person class that can plug in (have references to) other classes representing employee abilities, manager abilities, district supervisor abilities, delivery driver abilities, CEO abilities ...


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
Philip Shanks
Ranch Hand

Joined: Oct 15, 2002
Posts: 189
Originally posted by Stan James:
Going away from your question into OO concepts ... A human can be promoted from employee to manager. Can an object instance change classes? Nope!
Maybe we don't want a hierarchy at all. Maybe we want a plain person class that can plug in (have references to) other classes representing employee abilities, manager abilities, district supervisor abilities, delivery driver abilities, CEO abilities ...

Exactly... and such a design should have the capability to express transfers and demotions as well.
I once had a C++ instructor that posed such a question to the class... unfortunately it was never answered to my satisfaction. I'd still like to see a design that addresses the transitory roles of a dynamic object.


Philip Shanks, SCJP - Castro Valley, CA
My boss never outsources or has lay-offs, and He's always hiring. I work for Jesus! Prepare your resume!
Gaurav Mac Mathur
Ranch Hand

Joined: Feb 19, 2002
Posts: 47
well every Business object ( we call domain object ) must have a Interfaces and the objecy must be accessed vis these Interfaces only, so that we are very much sure that only the part that is to be exposed to Business and UI is added in interface and is accessed from Outside. (_ very much like EJB's Exposing only part of its Functionality using Remote Interface _).
So when one Object need to extend other Objects, we Extend its Interface with Other Objects Interfaces (_ possibally multiple interfaces _).
Guru's... Rectify me if i am wrong...
Cheers...
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Yes, I think you're on track. In one sense, everything you can tell about an object from the outside is its interface (small i). This is built of the class definition plus all implemented Java Interfaces (captital I).
So what I suggested is a bit confusing. If I can only use the Employee Interface when dealing with an Employee, how do I get to the special behaviors and attributes for Supervisor, Truck Driver, Officer, etc? Essentially I cannot, because they are hidden. So how do I get anything done?
Let's say various employees calculate pay differently. I can say Employee.getPayStrategy().computePay(). Now each employee can return its own pay strategy (hourly, salaried, commissioned) and the strategy can give me their paycheck amount.
If you have the GoF book, look at State and Strategy patterns. And I'm with Phillip - I've never had to follow this through to a complete solution on my own. The payroll example came right from Robert Martin's Agile Software Development book.
Joel McNary
Bartender

Joined: Aug 20, 2001
Posts: 1817

To all, I say, "Indeed."
I was going to mention problems inherant with promotion/demotion and representing employee types as classes, but decided that I wan't feeling long-winded enough to give an example of how I would model this. I'm feeling long-winded now.
First, I would have an Employee class. One of its attributes would be an EmployeePosition instance, where EmployeePosition defines (among other things) whether it is a manager, supervisor, schleppie, laywer, etc. Of course, there are a limited number of EmployeePositions, so there would either be a Factory/Singleton pattern or, if this were a Database-backed app, the EMPLOYEE_POSITION table would hold all instances (this way, the customer could change them on the fly, if wanted).
From the EmployeePosition class, we can get payRate calculation, security access, etc., adding more classes as needed. Access to the EmployeePosition object is granted though the interface from the Employee object, and access to these other elements is exposed thorough the interface to these objects.
I'm not going to model a whole office (it is significantly more complex than I've indicated here, seeing as how an Employee could have multiple titles and even multiple positions--how many hats do you wear?), but this basic concept can be extended ad infinitum (or ad naseum). The drawbacks to this method is that you do lose some in terms of performance, especially if this is a distributed application (there's a lot of RMI calls to get basic data; or, you have to return one course-gained object, which, depending on what it consists of, can take a significant amount of time to prepare).
But then, for optimal applications, flexibility does come at a cost to performance; If you increase flexibility, performance is garunteed to go down. The question is how much performance degredation can you tolerate before a). hard-coding everything, or b). waiting fo the next generation of machines to increase performance?
 
GeeCON Prague 2014
 
subject: Interfaces