Re: Synchronization of the constructor
Patricia Shanahan wrote:
I have been shifting away from public constructors towards private or
protected constructors with a public static factory method.
In this approach, it is easy to make the constructor do absolutely
nothing but construction. The factory method can do additional steps,
such as starting a thread or calling synchronized methods, to bring the
object into full operation before returning it.
In addition to making it easier to write thread-safe code, the factory
method approach is generally more flexible than calling constructors
directly from other classes.
In addition to the benefits Patricia mentioned, factory methods can infer g=
eneric parameters in a lot of situations where you'd have to state them exp=
licitly with constructors. They can also call builders for you, if you hav=
e that need.
I do recommend that one not make a religion out of factory methods. Badly =
designed factory methods are especially evil. (I remember one project wher=
e the "factory" method required explicit knowledge of the class under const=
ruction, had naming conventions connecting the method to both the class und=
er construction and the associated unit test that had to be followed or the=
code broke, abandoned compiler-enforceable type relationships, and require=
d a cast to the target type anyway, all to accomplish a simple no-argument =
constructor call of the target type.) Then again, badly-designed code is a=
lways evil, isn't it?
Point being that there are particular use cases when it's OK to use a const=
ructor if the advantages of a factory method are not particularly compellin=
g, 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 fro=
m her); factory methods bring great advantages for a lot of scenarios. I c=
ertainly plan to increase my appreciation for them because of her post.
--
Lew