xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From b.ohns...@freenet.de
Subject Code styleguide - protected variables vs. public/private concepts
Date Tue, 07 Mar 2006 16:00:50 GMT
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) {
        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...

View raw message