Re: General rule for constructors
pek wrote:
Hello, I've been reading lately Effective Java and Josh Bloch suggests
more than once to avoid using the default public constructors in order
to solve particular problems. More specifically, Item 1 says "Consider
static factory methods instead of constructors" or Item 2 "Consider a
builder when faced with many constructors" etc etc..
While all these paradigms are great (I was stunned when reading the
Builder pattern) I do feel that his general advice for constructors is
thinking like method visibility (start from private and build up to
public):
First try to see if all other are relevant to your problem and then,
as a final solution, create a public constructor.
Is this the way I should be thinking? Is creating a public constructor
the least desired way of constructing an object? Or are these
solutions good only for the problems they specifically solve?
Not that I'm against it. On the contrary, his solutions blow my mind
away (obviously, I'm not the guy you would call an advanced
programmer).
Thank you,
Panagiotis
So, the best advice that I can give you on this subject is borrowed from
a book (I believe Effective C++):
"Make your classes easy to use correctly, and difficult to use incorrectly."
You should consider that rule when deciding on whether you want to use
constructor versus some sort of factory (be it a builder, configurable
factory, static factory method, or something else).
The other important consideration is in the future when you create a
sub-class, or a replacement implementation, will it be easy for users of
your current "instantiation approach" to benefit from your enhancements
(whether it Just Happens, or is a simple change in one place)
And remember Rule #1: Every rule has an exception. Except this one. :-)
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>