wood burning stoves 2.0*
The moose likes Beginning Java and the fly likes Simple inheritance example Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Simple inheritance example" Watch "Simple inheritance example" New topic
Author

Simple inheritance example

Federico Minarelli
Greenhorn

Joined: Jan 16, 2010
Posts: 29
Hello everybody!

I was trying to write a simple example of inheritance and I have a doubt if mine could be a good approach to solve the following problem: I have two classes, representing respectively a Person and an Employee (Employee IS-A Person) and a third class, representing a Company, having an hire() method which promotes a Person to Employee.. Now, it is of course not allowed to downcast a Person to an Employee, so I came to the following design:


My doubt is whether it is a good idea to use an Employee constructor which receives a Person in order to set the Person-specific attributes of the Employee object?
What is, in your opinion, the most elegant solution to such problem?

Thanks a lot!
Bye!
Pierre Sugar
Ranch Hand

Joined: Dec 08, 2002
Posts: 62

If you are creating an employee why would you want first create a person? Just introduce the constructor




Pierre
Federico Minarelli
Greenhorn

Joined: Jan 16, 2010
Posts: 29
hi pierre!
Thank you for answering... I suppose that I already have a Person object which I want to promote to Employee.. And I also figure out that in the future one may wish to store more attributes for a Person.. So it would be better (in my opinion) to pass directly a Person object in the constructor.. I thought that in this way Employee would be coupled to Person, but other classes won't.. If I add another attribute to PErson, in such way I should edit just the Person and Employee code, while using a constructor such as yours, I should edit the code of all the classes instancing Employees... On the other side, classes creating Persons would have to be edited in any case... What do you think about this?

Thanks again! Bye
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38519
    
  23
I quite like the copy constructor. There is however another way to do it
"Favour composition over inheritance."
Give the Employee class a Person as a final field, then the Person object and the Employee object can have their separate existences. If the Employee is dismissed, the included Person object will continue its life.
Pierre Sugar
Ranch Hand

Joined: Dec 08, 2002
Posts: 62

I think in this case Ritchie's suggestion (Employee has-a Person) is the best choice especially when Person is living at its own and is subject to changes. If you introduce additional fields in your Person class you would also have to change your Empolyees' class (adding an new constructor with the additional fields). Changes in a parent class shouldn't force to change the subclasses from a maintenance point of view.
Vinoth Kumar Kannan
Ranch Hand

Joined: Aug 19, 2009
Posts: 276

I dont understand how giving Person as a final field in Employee would change things..can i see some kind of sample code, so that i can understand better the differences please..


OCPJP 6
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38519
    
  23
Vinoth Kumar Kannan
Ranch Hand

Joined: Aug 19, 2009
Posts: 276

That was indeed very kind of you,Campbell. Thanks.
Correct me if i'm wrong please - Now, the point is that, in Fede's code if incase you want to change the Class structure of Person you would have to modify the Employee constructor too. Now with this final Person, you wont have to do that. Also, the ultimate point of Employee IS-A Person is maintained as well, though not with the extends keyword.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38519
    
  23
Not quite. An Employee object IS-NOT-A Person object in this example, but am Employee object HAS-A Person object. It might be a good idea to throw an Exception from the constructor if null is passed, so as never to have a null Person reference.
Federico Minarelli
Greenhorn

Joined: Jan 16, 2010
Posts: 29
Thank you very much Campbell!! Yours (although you borrowed it from the GoF, isn't it? ;)) is exactly the elegant solution I was looking for!
Bye
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38519
    
  23
You're welcome

As far as I remember, "prefer composition over inheritance" has been regarded as a standard design principle at least since the days of Gamma Helm Johnson and Vlissides.
Priety Sharma
Ranch Hand

Joined: Jun 10, 2008
Posts: 156



As Campbell has given in his Employee class.

Shouldnt this method just return back the same reference of the person object.
I mean this:


Instead of again creating a person object?

Priety.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38519
    
  23
The reason for returning a new Person object is to allow users to manipulate that object without changing the state of the original object.

Your version is of course just as valid, allowing the original Person object's state to be changed.
Vinoth Kumar Kannan
Ranch Hand

Joined: Aug 19, 2009
Posts: 276

Defensive copying
http://www.javapractices.com/topic/TopicAction.do?Id=15
Priety Sharma
Ranch Hand

Joined: Jun 10, 2008
Posts: 156

Thanks Campbell,

I was thinking of returning the same person object since the Employee and Person object are related.

By the way its a pleasure being on CODERANCH/JAVARANCH forums.

So much help and so much expertise available.

This is a superb site.

Hats off to all of you for this good work.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38519
    
  23
You're welcome And thanks to Vinoth Kumar Kannan for reminding us of the correct name for the procedure.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Simple inheritance example