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.
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.
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.
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 :-)
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.