«

On 8/14/2011 7:42 AM, markspace wrote:
> public class Stooges {
>
> private final ArrayList stooges;
>
> public Stooges() {
> ArrayList temp = new ArrayList(3);
> temp.add( "Larry" );
> temp.add( "Moe" );
> temp.add( "Curly" );
> stooges = temp;
> }
> public List getStooges() {
> return new ArrayList( stooges );
> }
> }

I want to make one small change here. The above is correct, but
misleading. Both of the following are also immutable and thread safe:


public class Stooges {

private final ArrayList stooges;

public Stooges() {
ArrayList stooges = new ArrayList(3);
stooges.add( "Larry" );
stooges.add( "Moe" );
stooges.add( "Curly" );
}
public List getStooges() {
return new ArrayList( stooges );
}
}


-- or --

public class Stooges {

private final ArrayList stooges = new ArrayList(3);

public Stooges() {
stooges.add( "Larry" );
stooges.add( "Moe" );
stooges.add( "Curly" );
}
public List getStooges() {
return new ArrayList( stooges );
}
}

markspace wrote:
>> public class Stooges {
>>
>> private final ArrayList stooges;
>>
>> public Stooges() {
>> ArrayList temp = new ArrayList(3);
>> temp.add( "Larry" );
>> temp.add( "Moe" );
>> temp.add( "Curly" );
>> stooges = temp;
>> }
>> public List getStooges() {
>> return new ArrayList( stooges );
>> }
>> }
>
> I want to make one small change here. The above is correct, but
> misleading. Both of the following are also immutable and thread safe:
>
>
> public class Stooges {
>
> private final ArrayList stooges;
>
> public Stooges() {
> ArrayList stooges = new ArrayList(3);
> stooges.add( "Larry" );
> stooges.add( "Moe" );
> stooges.add( "Curly" );
> }
> public List getStooges() {
> return new ArrayList( stooges );
> }
> }
>
>
> -- or --
>
> public class Stooges {
>
> private final ArrayList stooges = new ArrayList(3);
>
> public Stooges() {
> stooges.add( "Larry" );
> stooges.add( "Moe" );
> stooges.add( "Curly" );
> }
> public List getStooges() {
> return new ArrayList( stooges );
> }
> }

See JLS §17.5:
"The usage model for final fields is a simple one. Set the final fields foran object in that object's constructor. Do not write a reference to the object being constructed in a place where another thread can see it before the object's constructor is finished. If this is followed, then when the object is seen by another thread, that thread will always see the correctly constructed version of that object's final fields. It will also see versions of any object or array referenced by those final fields that are at least asup-to-date as the final fields are."

--
Lew

On 8/14/2011 9:10 AM, Lew wrote:

> See JLS §17.5: "...It will also see versions of
> any object or array referenced by those final fields that are at
> least as up-to-date as the final fields are."
>

This is a little misleading, I think. In fact the update does not occur
when the final field is written ("at least as up-to-date as the final
fields are"). The update occurs at the end of the constructor.

JLS 17.5.1:
"The semantics for final fields are as follows. Let o be an object, and
c be a constructor for o in which f is written. A freeze action on a
final field f of o takes place when c exits, either normally or abruptly."

The "freeze action" is a little unclear. It's not technically a
synchronization, because immutable objects are specifically stated to
not use synchronization. It is a happens-before though (even though
that language isn't used), and it appears to imply a memory-barrier.

I'm not sure exactly why they use "freeze action" and not
happens-before. There might be some subtle difference for compiler
writers, than doesn't affect the rest of us.

Qu0ll wrote:
> Lew wrote:
> [snip]
>> Point being that there are particular use cases when it's OK to use a
>> constructor if the advantages of a factory method are not particularly
>> compelling, or if the hoops to implement and use a factory method are
>> too epicyclic. But Patricia's advice and insights are very sound (as they
>> always are from her); factory methods bring great advantages for a lot of
>> scenarios. I certainly plan to increase my appreciation for them
>> because of her post.
>
> In general is it better to have static factory methods on the class that is
> to be instantiated or to have a separate factory class?

That is a very good question.

I don't think there is a general rule here. You have to do what is smart for the given situation. Either way, make sure the factory method is well written.

If the construction is tightly bound to the class under construction, that would argue for the static method belonging to the class to be built. OTOH, if the factory is one of a class of factories, e.g., for collections, then it might make more sense to push it out into a helper class. Do what makes for the cleanest design that is easiest to maintain over the long term for the scenario. One goal is to make it easy to figure out where the factory is when you need instances. Another is to have compiler-enforced type safety.

Also, there may be cases where the factory method should be an instance method of a separate class, e.g., if you want to load a configuration to guidethe construction and have different instances work from different configurations.

Do what makes sense.

--
Lew