Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Observations about Interfaces

 
pagano monello
Ranch Hand
Posts: 38
1
Netbeans IDE
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The following observations refer to Mala Gupta “OCA Java SE 7 Certification Guide” example from page 304 on. I write the code below:



So I have three classes: Employee, Programmer and Manager; Employee is concrete, and the remaining two extend it. Now, to explain how to use interfaces, the Author adds two methods as it follows:

- attendTraining() to both classes Programmer and Manager
- conductInterviews() just to Manager

M. Gupta seems to suggest that the best way to do it can be accomplished by defining two interfaces in which to define the two methods as it follows:


So that the code for classes Programmer and Manager become:


So I have the following observations about it (and I must admit that I find it hard to understand this topic):

1. Why not to define attendTrainig method straight in class Employee? I guess it is possible and logically correct, but I am not sure at all. Maybe the Author has suggested to define it in an interface just to talk about multiple inheritance.
2. About defining conductInterview in an interface, I think that the scheme followed by the Author would have been mandatory if class Employee were abstract; in this case, endeed, it would be necessary to define an conductInterview method even in class Programmer. The fact is that class Employee is not abstract, so I think that it is correct to define the method conductInterview in it as a concrete method, and override it in class Manager. Is it correct, isn't it?

Can anyone give me hints about it, please?

Thank you in advance.
 
Don Fredricks
Greenhorn
Posts: 4
C++ Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One scenario I can envision is that you might, at some time in the future, have a class of employee (SeniorExecutive, perhaps?) for which attendTraining() does not make sense.

That said, other approaches to decomposing the problem space into Java entities are not wrong -- just different.

Don
 
pagano monello
Ranch Hand
Posts: 38
1
Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Don Fredricks,
thank you for your reply.

pagano
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
pagano monello wrote:1. Why not to define attendTrainig method straight in class Employee? I guess it is possible and logically correct, but I am not sure at all. Maybe the Author has suggested to define it in an interface just to talk about multiple inheritance.

Yes, if we assume that every employee is entitled to attend a training. And let's assume a programmer will attend a java training and the manager will follow a people management training. although it looks like the author just suggested the use of an interface to talk about multiple interface inheritance, there is still a difference between both approaches. If you use the interface-approach you only have to implement 2 methods (only relevant code)But if you would have defined the attendTraining method in the Employee class, you have to provide 3 implementations, because besides the specific implementations of Programmer and Manager, you'll also have to provide an implementation for the Employee class itselfYou could of course make the attendTraining method in the Employee class abstract, but that requires to make the Employee class abstract as well (and that's maybe not an option because this class might already be instantiated in other existing code and that would - as you know - result in compiler errors).

pagano monello wrote:2. About defining conductInterview in an interface, I think that the scheme followed by the Author would have been mandatory if class Employee were abstract; in this case, endeed, it would be necessary to define an conductInterview method even in class Programmer. The fact is that class Employee is not abstract, so I think that it is correct to define the method conductInterview in it as a concrete method, and override it in class Manager. Is it correct, isn't it?

No, I don't agree! And in my opinion your suggested design (although possible to implement) is bad. Why? Because if you define the conductInterview method in the Employee class every subclass will have a conductInterview method, even classes which never have to conduct an interview ever (like a Programmer or ManagementAssistant or Janitor). From a design perspective classes which should never ever conduct an interview, should not have the conductInterview method.

From a Java perspective you can add the conductInterview method in the Employee class and make sure that you get an error if this method is invoked on a programmer, but not on a manager (again only relevant code)But just because it can, it doesn't mean it's the best choice. From a design perspective, it's a very bad design. And you also have to be aware in other code that when you invoke the conductInterview method it could throw an exception (which you have to catch or prevent from happening). Let's assume you want to prevent the exception from happening. That could be easily done with the following codeEasy, isn't it? But what happens if a class like HRAssistant is added, you'll have to remember to update this method otherwise the HR assistant can't take the general part of the overview and give the introduction about the company. Therefore the design using the interface is much better: you don't have to care about an exception, and if classes are added later which can conduct interviews you don't have to change the doInterview method anymore. So that's why I agree with the author on using the Interviewer interface. The relevant codeAnd the improved doInterview methodAnd if a half year later the HRAssistant class is added, you only have to create this class and no changes are required to the doInterview method (that's in fact the Open/Closed principle, one of the most important principles of object-oriented programming)

Hope it helps!
Kind regards,
Roel

PS. This was a very good question and you really have thought about what you were reading, and that's important. Have a cow!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic