General rule for constructors

Discussion in 'Java' started by pek, Aug 14, 2008.

  1. pek

    pek Guest

    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
     
    pek, Aug 14, 2008
    #1
    1. Advertising

  2. pek

    Danger_Duck Guest

    On Aug 14, 1:02 pm, 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


    What are you trying to do?
     
    Danger_Duck, Aug 14, 2008
    #2
    1. Advertising

  3. pek

    pek Guest

    On Aug 14, 8:43 pm, Danger_Duck <> wrote:
    > On Aug 14, 1:02 pm, 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

    >
    > What are you trying to do?


    Nothing in particular. Just asking what is the best way of thinking
    when it comes to constructors..
     
    pek, Aug 14, 2008
    #3
  4. pek wrote:
    > On Aug 14, 8:43 pm, Danger_Duck <> wrote:
    >> On Aug 14, 1:02 pm, 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

    >> What are you trying to do?

    >
    > Nothing in particular. Just asking what is the best way of thinking
    > when it comes to constructors..


    Josh Bloch hints are fine.

    Only keep in minds that JavaBeans needs at least a public constructor
    with no parameters. This apply only for JavaBeans.

    --
    Andrea Francia
    http://andreafrancia.blogspot.com/2008/07/colinux-linux-dentro-windows.html
     
    Andrea Francia, Aug 14, 2008
    #4
  5. pek

    Daniel Pitts Guest

    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/>
     
    Daniel Pitts, Aug 14, 2008
    #5
  6. pek

    Mark Space Guest

    Daniel Pitts wrote:

    > 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."


    Also, once you think you have correctly outlined how you class should
    work, check out some Design Patterns and see if they do something
    markedly different. There are patterns for code too, not just design.
    Best ways to implement something, and all that.

    I think your original statement is good as a general rule. You should
    make everything private by default, and then see what you absolutely
    have to make public. Don't forget about things like Facades and
    Proxies, which can help you hide the real object that does the work.

    However, there will also be some specific patterns for what you are
    doing, and also some anti-patterns too. Try to find the most specific
    ones and apply those. Too much generalization isn't good either.

    Time and familiarity will help you find the best patterns quickly. I'm
    definitely still learning here too. And mis-designed code that is
    nevertheless designed clearly and with forethought shouldn't be that
    hard to refactor if you later decide the use of a particular pattern
    wasn't the best. "Build one to throw away."
     
    Mark Space, Aug 14, 2008
    #6
  7. pek

    Arne Vajhøj Guest

    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).


    Note that consider != always.

    There are some classes where using a constructor ties a lot
    of your code to an implementation that you may want to
    change.

    JAXP W3C DOM Document is a good example of an alternative
    approach and why it is beneficial.

    You could argue that Spring is fundamentally based on the
    concept.

    So consider it and and chose it when it makes sense.

    Arne
     
    Arne Vajhøj, Aug 15, 2008
    #7
  8. pek

    Arne Vajhøj Guest

    Andrea Francia wrote:
    > Only keep in minds that JavaBeans needs at least a public constructor
    > with no parameters. This apply only for JavaBeans.


    It is also sometimes needed with serialization and externalization.

    Arne
     
    Arne Vajhøj, Aug 15, 2008
    #8
  9. I'm a big fan of JB and his Effective Java.. but look at the JDK, and
    work out the ratio of public constructors to factory methods. Public
    constructors are in an overwhelming majority.. so clearly most people
    are perfectly happy with constructors which, yes, hardcode the
    implementation type in your logic. Even Bloch's Collections API uses
    mostly the constructors approach.

    Last but not least, I would argue strongly that software needs to be
    thought of as fluid. With modern refactoring tools, we can quickly
    make the kinds of changes to whole codebases which just a few years
    ago would have been major headaches. JB's best advice is "If in doubt,
    leave it out." So given that your static factories are a bit more
    complex than plain constructors, I'd say leave them out (initially).
     
    softwarepearls_com, Aug 15, 2008
    #9
  10. pek

    Daniel Pitts Guest

    Arne Vajhøj wrote:
    > Andrea Francia wrote:
    >> Only keep in minds that JavaBeans needs at least a public constructor
    >> with no parameters. This apply only for JavaBeans.

    >
    > It is also sometimes needed with serialization and externalization.

    Sometimes, but only if you are doing custom work. Standard
    serialization will bypass the object initialization phase completely.
    No constructor, no default field values (other than the minumum
    null/false/0), etc.
    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
     
    Daniel Pitts, Aug 15, 2008
    #10
  11. pek

    Arne Vajhøj Guest

    Daniel Pitts wrote:
    > Arne Vajhøj wrote:
    >> Andrea Francia wrote:
    >>> Only keep in minds that JavaBeans needs at least a public constructor
    >>> with no parameters. This apply only for JavaBeans.

    >>
    >> It is also sometimes needed with serialization and externalization.

    > Sometimes, but only if you are doing custom work. Standard
    > serialization will bypass the object initialization phase completely. No
    > constructor, no default field values (other than the minumum
    > null/false/0), etc.


    If I remember correctly then Externalizable always requires the no arg
    constructor and Serializable requires no arg constructors for the stuff
    inside the class that are not Serializable.

    Arne
     
    Arne Vajhøj, Aug 15, 2008
    #11
  12. pek

    Arne Vajhøj Guest

    softwarepearls_com wrote:
    > I'm a big fan of JB and his Effective Java.. but look at the JDK, and
    > work out the ratio of public constructors to factory methods. Public
    > constructors are in an overwhelming majority.. so clearly most people
    > are perfectly happy with constructors which, yes, hardcode the
    > implementation type in your logic. Even Bloch's Collections API uses
    > mostly the constructors approach.


    It is only a small part of classes where one will want to be
    able to replace the implementation.

    Nobody wants to use a factory class for everything. Think Spring - you
    want to dynamically load the critical classes not every class.

    > Last but not least, I would argue strongly that software needs to be
    > thought of as fluid. With modern refactoring tools, we can quickly
    > make the kinds of changes to whole codebases which just a few years
    > ago would have been major headaches.


    I disagree.

    Changing lots of code to use a specific implementation is a
    bad practice even if it is somewhat automated.

    Noone will prefer:

    Connection con = new MySqlConnection(constr);

    over:

    Connection con = DriverManager.getConnection(conurl);

    just because you have a fancy tool that can change MySqlConnection
    to OracleConnection in the entire application.

    Arne
     
    Arne Vajhøj, Aug 16, 2008
    #12
  13. pek

    jolz Guest

    > Serializable requires no arg constructors for the stuff
    > inside the class that are not Serializable.


    Rather outside the class. For example:

    class A {}
    class B implements Serializable {
    A a = new A();
    }

    will fail during seralization even though A has a default constructor. But:

    class A {}
    class B extends A implements Serializable {}

    will be ok because not serializable A has a default constructor. Without
    it exception would be thrown during deserialization.
     
    jolz, Aug 16, 2008
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dave Rudolf
    Replies:
    12
    Views:
    8,303
    Martijn Lievaart
    Feb 6, 2004
  2. Dave Dean
    Replies:
    4
    Views:
    642
    Andy Peters
    Sep 18, 2006
  3. Replies:
    0
    Views:
    1,371
  4. Jeremy Smith
    Replies:
    2
    Views:
    590
    Jeremy Smith
    Aug 3, 2006
  5. Jess
    Replies:
    5
    Views:
    609
    Ron Natalie
    Jun 7, 2007
Loading...

Share This Page