This week's book giveaway is in the General Computing forum. We're giving away four copies of Arduino in Action and have Martin Evans, Joshua Noble, and Jordan Hochenbaum on-line! See this thread for details.
Does any one know where I can get an excellent explanation about these important topics in a simply and intuitive way. These topics are fundamental and yet sometimes confusing. One of the confusion I have is that if a member in the base class is private the derived class does not inherit it. If it does not inherit it how is it going to store values in the object it creates from the base class?
When an object of the subclass is created on the heap, it will have a place in it for all of the fields that it has and all of the fields that it inherits from when the superclass constructor was executed. So the value of the superclass field is kept IN the subclass object. The subclass does not go back and store member variables in the superclass itself. If the field is private in the superclass it will not be inherited by the subclass and there will not be a place for it in the object on the heap. So the subclass can not get at that variable, but it can get at the fields that it inherited.
"JavaRanch, where the deer and the Certified play" - David O'Meara
Mulugeta Maru
Ranch Hand
Joined: Jan 20, 2003
Posts: 68
posted
0
I am lost. I do not understant this part of your answer. "If the field is private in the superclass it will not be inherited by the subclass and there will not be a place for it in the object on the heap. So the subclass can not get at that variable, but it can get at the fields that it inherited." If for example the base class has a private member called studentName (a field). When an object of the derived class is created whehre is it going to store the studentName?
Cindy Glass
"The Hood"
Sheriff
Joined: Sep 29, 2000
Posts: 8521
posted
0
It isn't. That is the point. As far as the subclass is concerned, that field does not exist.
Cindy, that isn't quite right. studentName has to be stored somewhere because the Base class might have a public getStudentName() method that allows the private property to be accessed. What Mulugeta doesn't realize is that when you create a child class you are also creating on the heap an object for every parent of the child class. So if we have a simple hierarchy of Base - Child we create three objects on the heap, Object, Base, and Child (all tied together) when we instantiate Child.
I am not sure I understand your answer. When an object is created from the derived class where is the studentName stored if it is a private field in the super class? :roll:
Mulugeta Maru
Ranch Hand
Joined: Jan 20, 2003
Posts: 68
posted
0
Hi Thomas, Please expand on your answer a little. I am sure there is more to it for me to clearly understand the concept. By the way is there any material out there which clearly explains this.
Cindy Glass
"The Hood"
Sheriff
Joined: Sep 29, 2000
Posts: 8521
posted
0
Originally posted by Thomas Paul: the Base class might have a public getStudentName() method that allows the private property to be accessed.
Well, yes, but then you are getting at it from the superclass, because the subclass can not. But your are correct, the superclass field IS out there - just marked private. However I only ever considered it 1 object on the heap with 2 parts, one part for the superclass stuff and another part for the subclass stuff. What would the 3rd part have in it???
Thomas Paul
mister krabs
Ranch Hand
Joined: May 05, 2000
Posts: 13974
posted
0
Originally posted by Cindy Glass: However I only ever considered it 1 object on the heap with 2 parts, one part for the superclass stuff and another part for the subclass stuff. What would the 3rd part have in it???
The parent of the superclass (and the parent of every class in Java), Object.
Cindy Glass
"The Hood"
Sheriff
Joined: Sep 29, 2000
Posts: 8521
posted
0
Duh!! :roll: the obvious - of course. [ March 12, 2003: Message edited by: Cindy Glass ]
if a member in the base class is private the derived class does not inherit it. If it does not inherit it how is it going to store values in the object it creates from the base class?
The whole point of polymorphism and inheritance is to create a "Common Interface" for classes that are related. In such cases sometimes it so happens that a member field/method which belongs to the base class need not be accessed by the derived class. The interface is set in such a way that it's not required to access the member elements at all. For instance take a base class called "Car" and derived classes such as "Honda" & "Ford". Now say if you had a member function called 'accelerateVehicle(int speed)'. Within this method we might have many fields and subfunctions such as 'gear', 'clutch', 'speedometer()' etc...these are something which are constructed by the base class programmer and are hidden (private/package access). Now in order to accelerate your your "Honda" or "Ford" you still can do that by just calling car.accelerateVehicle(int speed). It's the same for both makes/models (atleast here ).
Derek Grey
Ranch Hand
Joined: Feb 09, 2002
Posts: 204
posted
0
if a member in the base class is private the derived class does not inherit it. If it does not inherit it how is it going to store values in the object it creates from the base class?
The derived class inherits everything present in the base class. Always remember that the base class is a subset of the derived class. Derived Class = Base Class + Something extra Since you've written that "Something extra" you can access/modify it. But you can access only "public" declared fields/methods of the base class. The rest should be no concern of yours...its the headache of the programmer who wrote it (and has to maintain it.). One of the biggest advantages that I've found while coding using these concepts is that debugging gets restricted to only the derived class (the one I create).
Since you've written that "Something extra" you can access/modify it. But you can access only "public" declared fields/methods of the base class. The rest should be no concern of yours...its the headache of the programmer who wrote it (and has to maintain it.).
I think the part that confuses me (and possibly the original poster) is this: In your example of having a "vehicle" base class, let's say there are 3 variables: size, weight, and speed. -all integer variables marked private. If I create a sub-class called "ford", it inherits basically everything from the vehicle class, so if I create a new ford object, it will have size, weight, and speed variables correct? Assuming that's right, the part that I find confusing is that I can't directly access those variables - instead I have to use public methods that are in the vehicle class. (setSize, setWeight, etc etc) What's the logic behind this? As an aside, isn't there a keyword "protected" that WILL allow you to access a base-class varible directly from a sub-class? Thanks for any help!
What is with it is encapsulation. You say there are three private attributes: size, weight and speed. Let's say someone has figured out how to calcuate weight from size. So the parent can change it's implementation, but as long as it supports and stays true to the public method, you don't need to change your class. -steve [ March 12, 2003: Message edited by: Steve Fahlbusch ]
Mulugeta Maru
Ranch Hand
Joined: Jan 20, 2003
Posts: 68
posted
0
I thank you all who gave a version of their answer to my question. However, I did not get a clear answer to by original question �if a member in the base class is private the derived class does not inherit it. If it does not inherit it how is it going to store values in the object it creates from the base class? �. Since a private member in a superclass can not be inherited how is it possible for an object created from the subclass to store data in that field (the private member superclass field). And will these field live with the object created by the derived class? Some one suggested when we create an object from a derived class we also create two other objects � a superclass object and an instance of object class. This is confusing for me to say the least. Your help is very much appreciated.
Thomas Paul
mister krabs
Ranch Hand
Joined: May 05, 2000
Posts: 13974
posted
0
A class is made up of itself and every parent of that class. That means when you instantiate a class you always get at least two classes (your class plus an Object class). You can not change things that are private in your parent. You can use your parent's public methods (which you inherit) to change them. The reason for this is simple. Only your parent knows the proper way to store variables in the parent object. If you were allowed to directly change your parents variables then you may chnage them in an invalid way without knowing it.
[ March 13, 2003: Message edited by: Thomas Paul ]
Mulugeta Maru
Ranch Hand
Joined: Jan 20, 2003
Posts: 68
posted
0
Thank you Thomas. Your answer is clear and helpful. What happens when the parent is an abstract class? There wan't be an object of the abstract class and where is the private vaiables data that is in the prent class (abstract class) going to be stored?
Thomas Paul
mister krabs
Ranch Hand
Joined: May 05, 2000
Posts: 13974
posted
0
The parent class is still created. The only thing that prevents an abstract class from being instantiated is that it has undefined methods. Since the child has provided those methods, the class can be instantiated. Think of it this way, if abstract classes couldn't be instantiated then why are they allowed to have constructors? Abstract classes can be instantiated but not with new. They can only be instantiated through their non-abstract children. (Sort of like a dad who lives vicariously through his son. ) [ March 13, 2003: Message edited by: Thomas Paul ]
I had lunch with our software provider / maintenance people and of course we talked shop a great deal. A key person on the team is the one who advised me to come to JavaRanch. I am glad he did. During the course of our discussions this individual made a statement that surprised me more than a little. I was sharing my difficulty in following code that extensively uses polymorphic behaviour. His comment to me was; "I have yet to use polymorphism in my coding experience." Admittedly, he is not the most senior person on staff nor has he many years of experience with JAVA, but that statement has left me wanting to ask the question: how important is polymorphism in the overall scheme of things? doco [ March 13, 2003: Message edited by: doco mastadon ]
doco
Thomas Paul
mister krabs
Ranch Hand
Joined: May 05, 2000
Posts: 13974
posted
0
Did that person ever use JDBC? Did he ever use an XML parser? Did he ever use an iterator? I would say that person doesn't know what polymorphism is if he doesn't think he has ever used it.
I am not sure that is what he meant. I believe what he meant was that he himself had not written any code that was polymorphic (Abstract, Interface, Implements, etc). At any rae, I intend to learn it whether I use it or take advantage of it or not - but then why would one learn if one does not use; to know and not do is to not know. Thanks doco [ March 14, 2003: Message edited by: doco mastadon ]
Thomas Paul
mister krabs
Ranch Hand
Joined: May 05, 2000
Posts: 13974
posted
0
If a programmer is not making use of interfaces then they are not making use of design patterns. A Java programmer who is not using design patterns is not taking advatange of OO. It's like back in the old days when C++ first came around. A lot of the C programmers started writing procedural code in C++ and assumed they were doing OO. [ March 14, 2003: Message edited by: Thomas Paul ]
Mulugeta Maru
Ranch Hand
Joined: Jan 20, 2003
Posts: 68
posted
0
Thomas: What about static and final mebers that are in abstract class - will the derived class inherit them too? Thank you.
Whenever a new class instance is created, memory space is allocated for it with room for all the instance variables declared in the class type and all the instance variables declared in each superclass of the class type, including all the instance variables that may be hidden (�8.3). If there is not sufficient space available to allocate memory for the object, then creation of the class instance completes abruptly with an OutOfMemoryError. Otherwise, all the instance variables in the new object, including those declared in superclasses, are initialized to their default values (�4.5.5).
Dirk Schreckmann
Sheriff
Joined: Dec 10, 2001
Posts: 7023
posted
0
What about static and final mebers that are in abstract class - will the derived class inherit them too? Yes and yes. The static class members are inherited by the subclass. Static class methods don't participate in the polymorphic behavior of the class instances.
Howdy -- thought I'd add my bits... One way to think about polymorphism is that anytime the reference variable type and the actual object type are different, polymorphism is happening! : ) So, to look at how polymorphism is used in the Java API (and in your own code), look at the reference variable type for the argument and/or return type of a method you're calling. For example, if you put something in, say, an ArrayList (or any other collection), the ArrayList can't possibly have add() methods overloaded to take anything you could ever create to send it, so the ArrayList add() method looks like; add(Object o) Type 'Object' is the *ultimate* polymorphic type, because *any* type of object can be at the other end of an Object reference type... Object obj = new Dog(); Object obj2 = new JButton(); etc. So if Object is used as an argument type: public void takeObject(Object o) { } ANYTHING can be passed to that method! Dog d = new Dog(); takeObject(d); JButton button = new JButton("click"); takeObject(button); And so on... So all of the collection classes (HashMap, LinkedList, ArrayList, etc.) all have methods that can take an Object, so that you can pass ANYTHING into those methods. But the *real* object type is from whatever class *you* instantiated (Dog, JButton, etc.). This lets you make incredibly flexible code. For example: Imagine you're building the PetShop program. It's a simulation that will have dogs, cats, and birds. You're in charge of writing the PetShop program. So you write it like this; class PetShop { Dog[] dogArray; Cat[] catArray; Bird[] birdArray; // methods that take a Dog, Cat, Bird and add them // to the correct Array void addDog(Dog d) {...} void addCat(Cat c) { ... } void addBird(Bird b) { ...} // more methods here }
class Dog { void eat() { // dog-specific eat behavior } void showHappiness() { } } class Cat { void eatFood() { // cat-specific eat behavior } } class Bird { void doEat() { // bird-specific eat behavior } void beFriendly() { } } And imagine now it's time to call the eat() method on each of the animals in the PetShop. So you loop through each of the three arrays, and tell each Animal to eat. for (int i = 0; i < dogArray.length; i++) { dogArray[i].eat(); }
for (int i = 0; i < catArray.length; i++) { catArray[i].eatFood(); }
for (int i = 0; i < birdArray.length; i++) { birdArray[i].doEat(); } And when it's time to be friendly or happy, you do the same thing, looping through each of the arrays and calling whatever the appropriate method is for that animal type (beFriendly(), showHappiness(), etc.) Now you're done, and you leave to go on vacation. But as soon as you leave, the spec cha