Steve Brewin ha scritto:
> As to the synchronization issues, the lazy initialization pattern (that
> Stefano so loves) is not an accident. The intent is that in deployments
> where synchronization is required, you subclass to add synchronization,
> normally just on the getter method. In single threaded or per thread
> environments, the vanilla code is just fine. I hate synchronization being
> imposed when it is not required. Similairly, if you want to avoid lazy
> initialisation with this pattern, you just invoke the getter earlier, such
> as in the constructor of the using class.
Hi Steve,
I have no problem with lazy initialization, I have problems with too
many granular methods not used by anyone and creating problems in
reading the code.
To make it more clear to people with short memory (like me), I attach
the mail where I explained what IMHO was wrong in a specific instance of
that pattern. IMHO reducing the complexity of the code does not change
the fact that you can have an unsynchronized getter and you can then
have subclass or wrappers to synchronize it. If you only want to expose
the getter then IMHO you don't need all of the other
update/compute/getbasic/handle/set methods as you can "inline" the whole
code in the only published method.
That specific mail didn't receive any answer, so probably I was alone in
that thought, and that's ok. I wrote this just to clarify what I don't
love ;-)
Happy to see you around,
Stefano
--- Begin Message ---
Stefano Bagnara wrote:
To me it's something like obfuscated: I feel worst than browsing
decompiled code ;-)
And here is the pratical example:
Take this code:
-----------------
/**
* Answer if <code>aMessage</code> has been SEEN.
* @param aMessage
* @return boolean
* @throws MessagingException
*/
protected boolean isSeen(MimeMessage aMessage) throws MessagingException
{
boolean isSeen = false;
if (isMarkSeenPermanent().booleanValue())
isSeen = aMessage.isSet(Flags.Flag.SEEN);
else
isSeen = handleMarkSeenNotPermanent(aMessage);
return isSeen;
}
/**
* Answer the result of computing markSeenPermanent.
* @return Boolean
*/
protected Boolean computeMarkSeenPermanent()
{
return new Boolean(
getFolder().getPermanentFlags().contains(Flags.Flag.SEEN));
}
/**
* <p>Handler for when the folder does not support the SEEN flag.
* The default behaviour implemented here is to answer the value of the
* SEEN flag anyway.</p>
*
* <p>Subclasses may choose to override this method and implement their own
* solutions.</p>
*
* @param aMessage
* @return boolean
* @throws MessagingException
*/
protected boolean handleMarkSeenNotPermanent(MimeMessage aMessage)
throws MessagingException
{
return aMessage.isSet(Flags.Flag.SEEN);
}
/**
* Returns the isMarkSeenPermanent.
* @return Boolean
*/
protected Boolean isMarkSeenPermanent()
{
Boolean markSeenPermanent = null;
if (null == (markSeenPermanent = isMarkSeenPermanentBasic()))
{
updateMarkSeenPermanent();
return isMarkSeenPermanent();
}
return markSeenPermanent;
}
/**
* Returns the markSeenPermanent.
* @return Boolean
*/
private Boolean isMarkSeenPermanentBasic()
{
return fieldMarkSeenPermanent;
}
/**
* Sets the markSeenPermanent.
* @param markSeenPermanent The isMarkSeenPermanent to set
*/
protected void setMarkSeenPermanent(Boolean markSeenPermanent)
{
fieldMarkSeenPermanent = markSeenPermanent;
}
/**
* Updates the markSeenPermanent.
*/
protected void updateMarkSeenPermanent()
{
setMarkSeenPermanent(computeMarkSeenPermanent());
}
---------------
The only method used from the remaining FetchMail code is isSeen.
How much long does it take to understand the you can replace the whole
thing with:
----------
protected boolean isSeen(MimeMessage aMessage) throws MessagingException {
return aMessage.isSet(Flags.Flag.SEEN);
}
----------
????!??!?
I can't find any good reason to keep the old code: One could say that
this is a facility for subclasses, but I think that we shouldn't
obfuscate our classes to provide facilities to subclasses.
In fact you can do anything you can do in the original code also in my
refactored code (isSeen is protected).
This is just an example to make more clear why I loose to much time on
that code and I think it should be changed, even at the code of
introduce a few bugs we can anyway fix.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- End Message ---
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
