This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
The code i'm about to give makes use of copy constructors. Today in class i asked the question of how i could make sure all of the object one is copied into object two and this is the code i have constructed to make use of what the instructor showed for that.
So it does work i making a complete copy of object one into object two. Now i know you can call down the parent structure but only up. So the question i asked in class after i found you can copy all of object one into object two. I decided to get a little fancy and maybe this cant be done in java. What if you have to instances of NightShift employee.
But you only want to copy over the department and the hourToWork and not the rate.
Is there a way to redesign the copy constructor in NightShift to call its grand parent constructor in Employee instead of using the super(parent) call constructor?
I don't know if this can be done? I guess im just curious. I tried super.super(obj) but that failed miserably. LOL
Thanks in advanced for anyone who can explain if it can be done or why this would not want to be done.
"Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do." -- Steve Jobs
If I understood your question correctly, you don't want the HourlyEmployee member variables/methods in one of your NightShfit Employee object?
Since, your NightShiftEmployee inherited the HourEmployee class, it will have all of the variables of super class. You cannot skip the HourlyEmployee constructor. If you only want the members of the Employee class, you should directly inherit Employee. May be, create a new NightShiftEmployeeNoRate class. But, this is not good design.
Thanks Prateek Parekh. I think i see what your talking about. This however raises a question to me. if you have a class and you are 4 subclasses deep and each class along the way has a toString method overriding each one before. Now that i'm in the the forth class and want to use toString in it and have the toString information called from the java.lang.Object class toString. Is there a way to call a past method from one of your grand parents? I know you can call one from you parent by using super but what if you wanted to go further up the tree? Is this even possible?
Joseph Swager wrote:Is there a way to call a past method from one of your grand parents? I know you can call one from you parent by using super but what if you wanted to go further up the tree? Is this even possible?
super.someMethod() simply means "don't look for someMethod() in this class, even if it's defined; start walking the inheritance tree upwards until you find it" - so if you have someMethod() in your "grand parent" class, but not in your parent, it'll be called in the grand parent; if you have it in both parent and grand parent, it'll be called in the parent.
Note that "super." is only needed if you have someMethod() defined in the current class, too; if your current class does not override that method, Java will automatically use the one in your superclass.
Back to your copying problem: you could still call the super constructor, and set whatever value for the rate you want, not necessarily the one in your source object.
However, take care with your design. If you want to omit the rate (defined in HourlyEmployee) because it's not relevant for your NightShift objects, you should not have NightShift extend HourlyEmployee in the first place. By writing 'class Foo extends Bar' you say 'Foo is a special case of Bar, it can do everything that Bar can, only perhaps differently, potentially adding to it'. You must never create subclasses that are not compatible with their superclasses. Read: http://en.wikipedia.org/wiki/Liskov_substitution_principle
Sometimes your object hierarchy will have classes that do not exist in real life (in the problem domain). Suppose you're modelling living creatures , which may be lizards, dogs and men. Lizards have no name, dogs and men do. Based on that, would it make sense to say that Man extends Dog? You may come up with abstract classes and interfaces such as Named or FourLegged, which do not represent any real thing, just abstracted properties.
Joined: May 06, 2010
Joseph Swager wrote:I tried to typecast the toString like this:
I was thinking this would give me the toString from the object method. However, I get a Exception in java.lang.StackOverflowError
Yes, that's because the method is invoked using dynamic binding, that is, using the run-time ("real") type of the object you invoke it on, instead of the type of the reference you invoke it on. In this case, the type of the reference was object, but the run-time type did not change. Your toString() invoked itself via the Object reference, resulting in infinite recursion - almost infinite, as it was stopped by the StackOverflow :-)
Istvan Kovacs thank you. I i final get why infinite recursion happens. SO i take it there is no way to call a grand parent method if the parent has on that overrides it. Let me see if I'm getting this straight? The child is only aware of the parent and is in no way capable of know its grand parent? If that is the case if a method in the parent overrides the grandparents method then there is no way to use it or this infinite recursion happens correct?
Joseph Swager wrote:Let me see if I'm getting this straight? The child is only aware of the parent and is in no way capable of know its grand parent?
Yes, that is a clear and correct summary.
Joined: May 06, 2010
I still have the feeling you're trying to code around bad design.
When you create a type (interface or class), you're defining a contract, making certain guarantees. Each subtype must offer at least the same guarantees - it may add new ones, but must not violate the ones it inherits. All code (application or test) that can work with GrandParent must work with Parent and Child; code that can work with Parent must also work properly when given an instance of Child. By bypassing Parent.method in Child, going straight to GrandParent, you're suggesting that the statement 'Child is a kind of Parent' (or, in code, 'Child extends Parent') does not hold. If that is the case, you'll need to fix your class hierarchy.
To understand what I mean, read http://en.wikipedia.org/wiki/Circle-ellipse_problem. The structure of the problem is different there, but what happens is they create a subclass (Circle) from a class (Ellipse), and violate the parent's contract - which may come surprising at first, as we're all taught in school that a circle is a kind of ellipse.