« Return to Thread: Re: svn commit: r653826 [1/3] - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/trunk/ src/java/org/apache/fop/apps/ src/java/org/apache/fop/fonts/ src/java/org/apache/fop/fonts/autodetect/ src/java/org/apache/fop/fonts/base14/ src/java/org/a...

Re: svn commit: r653826 [1/3] - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/trunk/ src/java/org/apache/fop/apps/ src/java/org/apache/fop/fonts/ src/java/org/apache/fop/fonts/autodetect/ src/java/org/apache/fop/fonts/base14/ src/java/org/a...

by Andreas Delmelle-2 :: Rate this Message:

Reply to Author | View in Thread

On May 9, 2008, at 17:22, Adrian Cumiskey wrote:

> Andreas Delmelle wrote:
>> Maybe a matter of style, but if see this, I usually move the  
>> assignment to the member initialization, i.e.
>> class FopFactory {
>> ...
>>    private FontManager fontManager = new FontManager(this);
>> ...
>> That is, unless there is a specific reason to wait until  
>> getFontManager() is called before initializing (?)
>> (Haven't checked whether the fontManager needs a fully initialized  
>> FopFactory to work properly...)
>
> Not really of style.. just generally a design decision to  
> instantiate objects only when they are called upon (on demand)  
> rather than up front.

OK, no biggie... In this case, the end-result will be the same.

OTOH, the motivation for doing so should, IMO, not really be driven  
by a general design decision, but rather by the question:
"Does it make sense for FopFactory not to have a FontManager?"
If not, then we might as well initialize it together with the  
FopFactory, to stress that.



Cheers

Andreas

 « Return to Thread: Re: svn commit: r653826 [1/3] - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/trunk/ src/java/org/apache/fop/apps/ src/java/org/apache/fop/fonts/ src/java/org/apache/fop/fonts/autodetect/ src/java/org/apache/fop/fonts/base14/ src/java/org/a...

LightInTheBox - Buy quality products at wholesale price