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...
