On Wednesday 08 March 2006 00:00, [EMAIL PROTECTED] 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
