Re: [General]acces of members of subclass

Daniel Moyne wrote:
So Lew as superclasses cannot acces subclass members (in you example you
just provide methods "bar" in the subclass sub but no members) there is no
reasons to declare them as public and then only private makes sense ; am I
correct ?

Good question.

First a terminology point: both methods and fields are "members" of a class, or instance. Fields are also sometimes called "attributes", especially when associated with getter and setter methods ('getFoo()' and 'setFoo( value )'). Anyhow, the method 'bar()' in my example is a member of 'Sub', and makes the same point that a field member would - that subclass members can and often should be public, or protected, not necessarily private.

So 'private' access makes sense for the explicit purpose of hiding implementation, one of those Good Things you hear about. However, some members, usually just methods and not fields, will have wider access than that. If you want to make a field public, it is legal if not always desirable to do so.

The reason to declare a subclass member 'public' is to give it wide access to all users, but those users will have to declare their variables *to the subclass type* to benefit from those members.

So in the upthread example:
===================
public class Super
{
public void foo() { ... }
}

public class Sub extends Super
{
public void bar() { ... }
}

public class Client
{
public void main( String [] args )
{
Super sup = new Sub();
sup.bar(); // illegal!
}
}
===================

the class 'Client' made a mistake - it used a superclass variable but it wanted subclass functionality. It is not enough that the method is public - the variable has to be aware of it, too. Like this:

===================
public class Client
{
public void main( String [] args )
{
Sub sub = new Sub();
sub.bar(); // legal!
}
}
===================

Variables are doorkeepers to the real objects, not the objects themselves. They only let through the references that are on their list, and if you're not on the list, you don't get in.

Now coming back to method "bar" I have seen in the net some java code based
on method :
getMethod
and then invoke
that would allow to access this method from outside of the subclass but I
could not find this back for this topics.

You are probably referring to polymorphism and method overrides. This would apply to the method 'foo()' in the example, but not to fields. Once the compile-time doorkeeper lets the call in, say to 'foo()', the actual object behind the door executes the call. Because the object's actual run-time type is 'Sub', then it executes the subclass's version of the method.

This does not work for 'bar()' because the superclass variable doesn't have awareness of that call to even let it through.

The access of method of subclass was not on my original post ; it was only
about access to members of subclass "Sub".

The exact same logic applies to member fields as member methods - the variable type must be aware of the member in order to refer to the member. Supertype variables cannot refer to subtype members. If you need awareness of the subtype member, then the client code would declare the variable of the subtype.

This is commonly done with 'ArrayList' as a subtype of 'List', for example. Most of the time, one uses the 'List' type, but every so often one needs the specific characteristics of the subtype. At those times, the client declares its variable 'ArrayList', or some other suitable specific type.

--
Lew
.

Relevant Pages

  • Re: Help with design please
    ... entities from the problem space that are cohesive. ... disconnects in how the solution is viewed by different team members. ... >>relationships with the arrow on the superclass end. ... >>relationship the union of subclass members must be a complete set of the ...
    (comp.object)
  • Re: A hopefully interesting design question ...
    ... I will definitely look into the State Pattern ... AnswerBox: ... That is, members of OO ... it becomes obvious if one explicitly defines a subclass ...
    (comp.object)
  • Re: A hopefully interesting design question ...
    ... void RequestImputable; // from EditedAnswerBox ... AnswerBox: ... That is, members of OO ... it becomes obvious if one explicitly defines a subclass ...
    (comp.object)
  • Re: UML "OR" Composition Question
    ... "Each superclass instance in D must have exactly one ... from the fact that the union of subclass members must be a complete set ... of the superclass members. ... known in data modeling as a 'direct instance' of the superclass. ...
    (comp.object)
  • Re: UML "OR" Composition Question
    ... the union of members of sibling subsets must be a complete ... > instantiate a superclass without specifying a leaf subclass as well.] ... Since the diagram is only a view to the model, it needs not to show the ... siblings of Y, Z. Additionally, these additional siblings aren't ...
    (comp.object)