Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Interfaces

 
Joseph Vinodh
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1840
Eclipse IDE Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ...
 
Philip Shanks
Ranch Hand
Posts: 189
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Gaurav Mac Mathur
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1840
Eclipse IDE Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic