?(inheritance) from a newbie

[Panday Manako]

Hi!
I'm reading peter van der linden's book.
I have these 2 classes...
class Fruit
{
String zesty = "Fruit String";
void doThis()
{
System.out.println("Fruit Method");
}
}
class Citrus extends Fruit
{
String zesty = "Citrus String";
void doThis()
{
System.out.println("Citrus Method");
}
public static void main(String args[])
{
Citrus c = new Citrus();
Fruit f = c;
c.doThis(); //displays "Citrus Method"
f.doThis(); //displays "Citrus Method"
System.out.println(c.zesty); //displays "Citrus String"
System.out.println(f.zesty); //displays "Fruit String"
}
}
Is it correct to say that when names are the same in inheritance and you assign a subclass(c) to its superclass type(f), the object(f) always uses its data variables and for the methods it uses the subclass methods?
Thanks in advance.

[Junilu Lacar]

This illustrates the fact that only methods are polymorphic; instance variables are not. Methods are resolved using the actual object type (at runtime), instance variables are resolved using the declared object type (compile time).
Maybe Java does this to discourage making instance variables anything but private. This helps keep the encapsulation of a class intact. In general, you should keep instance variable private. If you must expose them to the world, use accessor methods. You will still be breaking encapsulation by using an accessor method but at least it's a little more flexible and it's polymorphic.
J.Lacar

[This message has been edited by JUNILU LACAR (edited April 01, 2001).]

[Panday Manako]

Thanks!

[Mike Curwen]

This is a statment that confuses me, and I'm hearing it more and more.

You will still be breaking encapsulation by using an accessor method

I can recall helping someone in my highschool computer science class. (Unstructured BASIC, in case anyone's interested). This fellow never quite understood the whole idea of using OUTPUT. He could do the looping and logic, but I always had to remind him... "and now do you want your user to see the result, or have the compuer keep it to itself?".

I'm reminded of this when I read someone make a statement like that I've quoted. I've seen it in books written by much smarter people than me. But I can't help but wonder... what good is a class when you cannot access the data inside?

Encapsulation is (to me) about hiding data that you don't want a user to know about (like an object id, or internal Primary Key, or some other flag values). It's also about preventing coders from sticking their fingers in the cookie jar, and exploiting what is supposed to be internal workings of a class. (Don't change that value! We want it to be that way!) Prevent this sort of thing by hiding it. Just don't write accessor methods for those values! But otherwise, how else is someone supposed to gain legitimate information from the class, if not through accessor methods?

[Sri Bala]

Encapsulation is not just about hiding the data from the user. To be more precise, encapsulation is, "Hiding the implementation details from the user". The user only needs to know to use the object with its interface. A setter method may validate and change the datatype and represent the data internally in a different manner and a getter can decode it and return it to the user. The user need not be bothered about these details.

[Mike Curwen]

Yes, but was about accessor methods?

[Cindy Glass]

The point is that in a true Object oriented approach, you would NOT ask for the value of a variable and then YOU do something with it. Instead you would ask the OBJECT to do something FOR you and just return the finished product.
Getters and setters help access the objects variables and therefore (while sometimes convenient) help break the encapsulation of the object. Think of it like - looking at an objects' variables is like looking at their underwear, or their secrets. Sometimes you can do it, it just isn't very nice.
You should look for "doer" methods instead, that do not require exposing how the variables are set or maintained.
[This message has been edited by Cindy Glass (edited April 02, 2001).]

[Thomas Paul]

Imagine an object representing an order from a user. You simply want to display the total. The total is made up of a bunch of detail lines, shipping cost, and tax. You could run a get method and get each individual part of the total and add them up or you could run a getTotal(). The object may not actually store the total, however. It may be that the object does the calculation and then gives you the result. The huge advantage to this is if another category is created (e.g. gift wrap) you would not have to make any changes to get the correct total.

[Junilu Lacar]

Please don't read anything else into the statement about accessor methods breaking encapsulation. I am not saying that they are evil and should never be used (although some people think so). However, you should be aware of the consequences of using them so that you can make an informed decision on whether or not they are appropriate in the context of your design.
Bruce Eckel writes "A primary consideration in object-oriented design is "separating the things that change from the things that stay the same."
Robert Martin says that the advantage of doing OO is that it facilitates "dependency management" (or something to that effect).
Then you will hear about keeping classes loosely coupled.
With these bits of wisdom from the gurus in mind, you should use accessor methods with care. Evaluate the potential negative effects that changes to the program's design may have on the couplings created by using accessor methods. If you think those risks are acceptable and it makes your life easier to use them(for now), you may be justified in using accessor methods.
J.Lacar

[This message has been edited by JUNILU LACAR (edited April 02, 2001).]

[Mike Curwen]

The arguments I've heard are good, but I'll say this "I can still imagine wanting to retrieve an atomic data item." That is: NOT a calculated getTotal, or getRecordCount.

Look through the API... it's peppered with get methods, many of them returning a single, uncalculated primitive type.

In some of the classes I've wrote, I need a way to determine the Max allowed items. This is not calculated, it's a set integer. If I wrap a data access class, I need a way to get the connection object.

I think there's really two arguments here. When programmers include (by default) a getter and setter for each private variable, this is a very bad thing, and certainly does break encapsulation, and goes against the spirit of OO. But including a get method for variables that make sense.. I don't think there is such a problem there. And I suppose someone's response will be: "You are not using OO correctly, rethink your design."
[This message has been edited by Mike Curwen (edited April 03, 2001).]

[Thomas Paul]

If I wrap a dataaccess class, I need a way to get the connection object.

Actually you don't. Instead you provide methods to access the Connection object.

[Mike Curwen]

Ummm... no.
Sometimes it's useful to provide a naked connection object. The DriveManager class does this, why can't I?