Accessing Superclasses' fields

What is the best practice for accessing my superclass' fields? I understand the best approach for accessing other class' fields is to access them through get and sets. However, there is a special relationship you are making with inheritance. The fact that you are specializing an implementation means that you require/know about the entire generalization (i.e. superclass). So does it really make sense to have gets and sets for the fields in your superclass so the subclass can get to them? or is it acceptable to access the fields directly?

Ideally I would want to use the 'ever so talked about' old school "private protected" to encapsulate my code. IMHO, this was something that should not have been removed because other developers that are working in my package might not fully grasp my design and start using data items that they shouldn't.

here is little code snippets to help clarify what I am talking about.

Scenario 1:

publicabstractclass SuperClass{

private Value val;

protected Value getValue(){return val;}

protectedvoid setValue(Value val){ this.val = val;}

publicabstract doWork();

}

publicclass SubClassextends SuperClass{

publicvoid doWork(){

Value val = super.getValue();

val.doWork();

}

}

Scenario 2:

publicabstractclass SuperClass{

protected Value val;

publicabstract doWork();

}

publicclass SubClassextends SuperClass{

publicvoid doWork(){

val.doWork();

}

}

Direct access is easier to write and at this level seems appropiate

Thanks for your comments

Lance

[3010 byte] By [lance-johnson] at [2007-9-30 7:12:49]
# 1

that depends on what your superclass is doing. usually, setting the fields/method as protected is enough and the subclass can handle thos more easily. but there might be cases where your superclass needs absolute control over a field and just allow accessing it through superclass-controlled get/set methods. example could be a resource, e.g. a connection. If the connection would just be protected, every subclass could perform a connection.close(). if the superclass just offers a method closeConnection() it has full control and can decide e.g. to commit, rollback transactions or giving it back to a connection pool, etc.

MartinHilpert at 2007-7-1 23:30:17 > top of Java-index,Other Topics,Patterns & OO Design...
# 2

A lot also depends on who will be extending your class. If it's just you or your team, using direct access will probably be fine. If anyone might be extending this class or a large number of developers, you might want to avoid giving access to the internals. You will not be able to change them without breaking a lot of code. In addition, someone might break the class be setting val to null etc.

dubwai at 2007-7-1 23:30:17 > top of Java-index,Other Topics,Patterns & OO Design...
# 3

> A lot also depends on who will be extending your

> class. If it's just you or your team, using direct

> access will probably be fine. If anyone might be

> extending this class or a large number of developers,

> you might want to avoid giving access to the

> internals. You will not be able to change them

> without breaking a lot of code. In addition, someone

> might break the class be setting val to null etc.

Java is an object oriented language and from OOAD point of view thats the worst thing you could do. ARe we forgetting encapsulation. Secondly adding to dubwai's comments how r u going to ensure that who would extend your class or use it. From the ease point of view structured programming was the best thing. What brought OO concepts into picture was maintainabilty and reliability and thats why direct access is some kind of a taboo.

yrhduahcmarruhk at 2007-7-1 23:30:17 > top of Java-index,Other Topics,Patterns & OO Design...