Constructor / inheritance / encapsulation issue

Question

Please consider this code:
public class Main {
  public static void main(String[] args) {  new BBB();  }
    public static class AAA {
        private int x;
        AAA() {  foo();  x = 123; }
        public void foo() { println("AAA::foo()"); }
    public static class BBB extends AAA {
        BBB() { super(); }
        public void foo() { println("BBB::foo()"); }
}The result is that the constructor in AAA invokes BBB's foo(), which violates encapsulation. I would just like to ask:
Invoking public/protected instance methods in the constructors of non-final classes is absolutely forbidden, right?
I am not asking why that happens. Rather, I just want to confirm the answer is "yes", it is forbidden. Or, if there are cases when it is ok, I am interested in learning them. Doing more that initializing instance variables in a constructor seems intriguing. But doing so could create weird situations (as in AAA's constructor) where you can access the private variable "x" of AAA and then invoke the BBB's foo().
ps: the "users online" and "guests online" forum statistics always equal zero.

Answer 1

dpxqb wrote:
abillconsl wrote:
dpxqb wrote:
Please consider this code:
The result is that the constructor in AAA invokes BBB's foo(), which violates encapsulation.Why does it violate encapsulation? BBB is a subclass of AAA, not just any class.So I design class AAA.
AAA's constructor requires that AAA's foo() be invoked to initialize.
AAA cannot control the behavior of BBB.
BBB subclasses AAA, and overrides foo().
If BBB's foo() does not invoke super(), AAA cannot initialize and thus neither can BBB.
I see more what you're talking about. Well first of all you don't have foo() invoking super() you have B() doing it - small point but worth getting straight. I never said, and didn't mean that your code was desireable BTW ... I said it's understandable and a good learning devise. Two other posters gave you good advice as to what to do about it. I'll give you another. make foo() private instead of public. There is no reason to show all your implementation code to everyone and good reasons not to. If foo() should not be called by anything but the ctor or AAA, then hide it. There is not reason that I can see to override that method either. AAA should be initialized only by AAA, and BBB by BBB. So you call foo instead aaaInitialize() and foo in BBB bbbinitialize.
Further, in the AAA constructor, a private variable is accessed "x", and then in the next line a method of a subclass is invoked. This blurs the boundary between what is hidden by the super class and exposed by a subclass (breaking encapsulation).
I would just like to ask:
Invoking public/protected instance methods in the constructors of non-final classes is absolutely forbidden, right?No it's not forbidden at all.The super class looses the ability to initialize itself. It becomes dependent on subclass behavior which breaks encapsulation.
I am not asking why that happens. Rather, I just want to confirm the answer is "yes", it is forbidden. Or, if there are cases when it is ok, I am interested in learning them.You should do a Topeka on the subject.ok.
Doing more that initializing instance variables in a constructor seems intriguing.
It's done all the time. For example, in the constructor you might all methods like: "createAndBuildGUI()", which would build the graphics part of a desktop app - instead of doing all that code directly in the one constr method. Just one example. IDE's like Eclipse do things like this.
But doing so could create weird situations (as in AAA's constructor) where you can access the private variable "x" of AAA and then invoke the BBB's foo().This is not wierd - it's designed to work like this.I just don't get it. A super class should never be allowed to invoke subclass's methods. The super class has no idea what the subclass's methods would do, so how could this be a reliable way to code? A class that invokes protected/public methods in the constructor is fragile and breakable. A concrete class should always be able to initialize itself regardless of what subclasses do.
As jschell hinted, I totally lost focus on what a "constructor" is suppose to do: just initialize the object and get it ready to roll, and nothing more. no behavior. thanks.