Code styleguide - protected variables vs. public/private concepts

[b....@freenet.de]

Hi there,

while working through my notes I found a point "strange things". I think I mentioned this before as some kind of footnote or BTW. I'm getting used to the rule to write variable definitions (even if private) at the class' top. But I don't understand the following:

package org.apache.fop.layoutmgr.table;
[...]

    public TableCellLayoutManager(TableCell node, PrimaryGridUnit pgu) {
        super(node);
        fobj = node;
        this.gridUnit = pgu;
    }
[...]

The TableCellLayoutManager is a AbstractBaseLayoutManager which has a constructor with a FObj as only parameter. This FObj-variable is defined protected, mkay, and the constructor's parameter is handed over to this variable, mkay too. But why does the more specific TableCellLayoutManager set this again? There are two scenarios:

1. "Speed is everything":
1.1 class variables are at least protected to allow direct manipulation (they should become public, so everyone can make use of the speed up)
1.2 No method is available to modify the variable
1.3 The variable does not have any dependencies like property listeners
-> Remove the parameter from the constructor

2. "Information hiding for tight event management"
2.1 class variables are always private
2.2 Manipulation is only possible through methods (interfaces ought to be defined)
2.3 all interaction behind the method is implied (setting a property causes a notify, removing the element causes deregistering of all listeners...)
-> implement some more methods

So there must be a third concept (which I'd like to apply to my changes, too) or changes need to be done (at least an issue somewhere would be nice). I know these copy & paste mistakes causing hours of digging into the sources and recognizing, that something's just slightly beyond oo-concepts. This one is painless, consumes at least time for variable assignment, maybe the compiler optimizes this to only one call. But it could get worse...

Re: Code styleguide - protected variables vs. public/private concepts

[Manuel Mall <mm...@arcus.com.au>]

On Wednesday 08 March 2006 00:00, b.ohnsorg@freenet.de wrote:
> Hi there,
>
> while working through my notes I found a point "strange things". I
> think I mentioned this before as some kind of footnote or BTW. I'm
> getting used to the rule to write variable definitions (even if
> private) at the class' top. But I don't understand the following:
>
> package org.apache.fop.layoutmgr.table;
> [...]
>
>     public TableCellLayoutManager(TableCell node, PrimaryGridUnit
> pgu) { super(node);
>         fobj = node;
>         this.gridUnit = pgu;
>     }
> [...]
>
> The TableCellLayoutManager is a AbstractBaseLayoutManager which has a
> constructor with a FObj as only parameter. This FObj-variable is
> defined protected, mkay, and the constructor's parameter is handed
> over to this variable, mkay too. But why does the more specific
> TableCellLayoutManager set this again? There are two scenarios:

There is another scenario: It was simply forgotten to adjust during a 
refactoring. If you look closely there are quite a few of these 
'little' things scattered through code base. For example 
TableAndCaptionLayoutManager and TableCaptionLayoutManager have the 
same 'defect' of setting the fobj member.

>
> 1. "Speed is everything":
> 1.1 class variables are at least protected to allow direct
> manipulation (they should become public, so everyone can make use of
> the speed up) 1.2 No method is available to modify the variable
> 1.3 The variable does not have any dependencies like property
> listeners -> Remove the parameter from the constructor
>
> 2. "Information hiding for tight event management"
> 2.1 class variables are always private
> 2.2 Manipulation is only possible through methods (interfaces ought
> to be defined) 2.3 all interaction behind the method is implied
> (setting a property causes a notify, removing the element causes
> deregistering of all listeners...) -> implement some more methods
>
<snip/>

Manuel