• Post Reply Bookmark Topic Watch Topic
  • New Topic

Regarding Abstract Classes and Access Modifiers!  RSS feed

 
Ashwin Rao
Ranch Hand
Posts: 89
C++ Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm having difficulty understanding this small piece of code:


The above is an abstract class which describes the basic structure that every fruit should "extend".
The below is a concrete subclass of the Fruit class called Apple.


Also do note that the two pieces of code are in different packages!

Upon compiling the Apple class I get the following error:


What I don't understand is this: I've given a non-abstract implementation to the "setTasteType" method in the Apple class and clearly setTasteType should have the authority to modify the private instance variables of Fruit. But it turns out I'm wrong. Can somebody explain where my thinking has gone awry?

Any help is much appreciated!
 
Joe Harry
Ranch Hand
Posts: 10128
3
Eclipse IDE Mac PPC Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What do you expect the rules for a private access modifier be? You declare it private and expect it to be visible in your sub classes? Isn't that defeating the whole purpose of being private to a specific class?
 
Ashwin Rao
Ranch Hand
Posts: 89
C++ Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My doubt is: "setTasteType" is a method that is a member of the Fruit class. Shouldn't it have access to Fruit's private variables?
 
Joe Harry
Ranch Hand
Posts: 10128
3
Eclipse IDE Mac PPC Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ashwin Rao wrote:My doubt is: "setTasteType" is a method that is a member of the Fruit class. Shouldn't it have access to Fruit's private variables?


If you are in the Fruit class yes, but not from the Apple class which is the error that you get!
 
Tomas Linhart
Ranch Hand
Posts: 86
2
Java Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Joe Harry wrote:What do you expect the rules for a private access modifier be? You declare it private and expect it to be visible in your sub classes? Isn't that defeating the whole purpose of being private to a specific class?

Actually, this is what confuses me as well. I know all the rules for access modifiers, but I might have failed at getting the logic. I understand the inheritance as a "IS-A" relationship. If I have a base class Car that has a private field color, then I would expect a subclass Ferrari to also have access to the color field. I know I can do this with a protected modifier, but I just can't justify using a private modifier for fields of classes that are to be subclassed. In other words, I can't think up an example, where it would be correct to have a private field in the base class that's for sure going to be subclassed. If inheritance is a "IS-A" relationship and member fields represent the state of an object, both base class and a subclass should share the same state with the same access to it. Where do I fail with this assumtion?
 
E Armitage
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Keeping the field private in the superclass is a way of protecting against sub classes modifying (or accessing) that field in a way that was not intended when the superclass was written. That's why you see private fields with their getters and setters in the same (super)class. The field can still be accessed or set in the sub classes but only through public or protected methods in the superclass.
 
Tomas Linhart
Ranch Hand
Posts: 86
2
Java Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is reasonable explanation, thanks. But then, why there is also the protected modifier (leaving aside that it provides also the package access)? Maybe I just need two simple examples, that would help me to understand the cases, where either design is perfectly justified.
 
E Armitage
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tomas Linhart wrote:This is reasonable explanation, thanks. But then, why there is also the protected modifier (leaving aside that it provides also the package access)? Maybe I just need two simple examples, that would help me to understand the cases, where either design is perfectly justified.


protected would be if when writing the super class you decide it is ok for sub classes to access/change that field directly without going through any super class method.
 
Tomas Linhart
Ranch Hand
Posts: 86
2
Java Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I understand that, but as I said, I can't think up the use cases for either scenario (where the other way wouldn't be correct).
 
E Armitage
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tomas Linhart wrote:I understand that, but as I said, I can't think up the use cases for either scenario (where the other way wouldn't be correct).



There are plenty of cases. e.g if a value is calculated in the constructor and you only want the value to ever be set through that calculation in the constructor then you don't want sub classes setting that value and would declare the field as private. e.g an area property that is calculated from length and width passed into the constructor.
 
Tomas Linhart
Ranch Hand
Posts: 86
2
Java Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Got it, thank you.
 
Campbell Ritchie
Marshal
Posts: 56541
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The design you were given is flawed. Whoever wrote a class with a private field and no means to set the taste made a mistake. I personally think the mistake is in making that method abstract.
 
E Armitage
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:The design you were given is flawed. Whoever wrote a class with a private field and no means to set the taste made a mistake. I personally think the mistake is in making that method abstract.


Looks ok since the abstract method is public. So the means to set the taste has been delegated to sub classes.
 
Dave Tolls
Ranch Foreman
Posts: 3061
37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
E Armitage wrote:
Campbell Ritchie wrote:The design you were given is flawed. Whoever wrote a class with a private field and no means to set the taste made a mistake. I personally think the mistake is in making that method abstract.


Looks ok since the abstract method is public. So the means to set the taste has been delegated to sub classes.


Except that taste is an attribute of Fruit, not its subclasses, so Fruit has to have the responsibility of handling access to it.

As for protected (and this isn't directed at you) I've only ever used it for methods.
 
E Armitage
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:The design you were given is flawed. Whoever wrote a class with a private field and no means to set the taste made a mistake. I personally think the mistake is in making that method abstract.


Yes, (thanks Dave for pointing it out for me), there isn't a way provided to sub classes for setting the tasteType.
 
Campbell Ritchie
Marshal
Posts: 56541
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maybe it would be better to insist all fields be initialised via the constructor, so the Fruit class would require a taste parameter for its constructor.
 
S Majumder
Ranch Hand
Posts: 349
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ashwin Rao wrote:

What I don't understand is this: I've given a non-abstract implementation to the "setTasteType" method in the Apple class and clearly setTasteType should have the authority to modify the private instance variables of Fruit. But it turns out I'm wrong. Can somebody explain where my thinking has gone awry?

Any help is much appreciated!


Ashwin,

The tasteType is being defined as private in the Fruit class , and we can not access the private member variable directly to any class outside of that class where that property is being defined !!!

As Campbell mentioned :
The design you were given is flawed.


Hope you understand .

Thanks ,
Satya
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!