Static Method Pros and Cons

Discussion in 'Java' started by Axehelm, May 26, 2004.

  1. Axehelm

    Axehelm Guest

    Okay, I'm in a debate over whether or not static methods are a good idea in
    a general domain class.

    I'm personally not a fan of static methods but we seem to be using them to
    load an object. For example if you have an Employee class rather then
    instantiating an instance you call a static method 'GetEmployees' and it
    returns a List of Employee objects.

    I'm looking for what other people are doing and if you feel this is a good
    or bad idea.

    Thanks
    Axehelm, May 26, 2004
    #1
    1. Advertising

  2. Axehelm

    Roedy Green Guest

    On Wed, 26 May 2004 22:18:33 GMT, "Axehelm" <> wrote
    or quoted :

    >I'm personally not a fan of static methods but we seem to be using them to
    >load an object. For example if you have an Employee class rather then
    >instantiating an instance you call a static method 'GetEmployees' and it
    >returns a List of Employee objects.
    >
    >I'm looking for what other people are doing and if you feel this is a good
    >or bad idea.


    sounds like a standard factory design pattern. See
    http://mindprod.com/jgloss/factorymethod.html
    http://mindprod.com/jgloss/designpatterns.html

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, May 26, 2004
    #2
    1. Advertising

  3. Axehelm

    Ryan Stewart Guest

    "Roedy Green" <> wrote in message
    news:...
    > On Wed, 26 May 2004 22:18:33 GMT, "Axehelm" <> wrote
    > or quoted :
    >
    > >I'm personally not a fan of static methods but we seem to be using them

    to
    > >load an object. For example if you have an Employee class rather then
    > >instantiating an instance you call a static method 'GetEmployees' and it
    > >returns a List of Employee objects.
    > >
    > >I'm looking for what other people are doing and if you feel this is a

    good
    > >or bad idea.

    >
    > sounds like a standard factory design pattern. See
    > http://mindprod.com/jgloss/factorymethod.html
    > http://mindprod.com/jgloss/designpatterns.html
    >

    Or a DAO pattern:
    http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
    Ryan Stewart, May 27, 2004
    #3
  4. Axehelm

    P.Hill Guest

    Ryan Stewart wrote:

    >>>[...]
    >>>I'm personally not a fan of static methods but we seem to be using them
    >>>[...]

    >
    > Or a DAO pattern:
    > http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html


    No, please don't have static methods in the DAO. DAOs are supposed to be
    objects, did you miss the "O"?

    In the example you cited, even the Factory that produces the DOAs is not static;
    only DAOFactory.getDAOFactorygetDAOFactory(int whichFactory)
    is static.

    -Paul
    P.Hill, May 27, 2004
    #4
  5. Axehelm wrote:
    > For example if you have an Employee class rather then
    > instantiating an instance you call a static method 'GetEmployees' and it
    > returns a List of Employee objects.


    Without more context it is a little bit difficult to give a final
    verdict. I would tend to say it is not a good idea.

    If I assume you model some kind of organizational structure, then a more
    natural way would be to e.g. have an (abstract) "Organization" class
    with subclasses like "Company", "Department", "Unit", etc. Then the
    "Organization" might have a non-static method like getEmployees() which
    is inherited by the subclasses.

    The usage you describe sounds very much like an attempt to get the
    equivalent of some global variable. I do not agree with other posters
    that this is an application of the factory design pattern. A factory
    returns one(!) particular (freshly or cached) object, build according to
    specification. That specification is provided in the form of the
    actual parameters to the method invocation. This does not happen in your
    example. It is almost the opposite: Instead of getting a specific
    object, your method is supposed to dump all objects on the caller.

    > I'm looking for what other people are doing and if you feel this is a good
    > or bad idea.


    With a 90% probability a bad idea, incorrect modeling of object
    relations and an abuse of a language feature.

    /Thomas
    Thomas Weidenfeller, May 27, 2004
    #5
  6. Axehelm

    John Davison Guest

    Axehelm wrote:

    > Okay, I'm in a debate over whether or not static methods are a good idea in
    > a general domain class.
    >
    > I'm personally not a fan of static methods but we seem to be using them to
    > load an object. For example if you have an Employee class rather then
    > instantiating an instance you call a static method 'GetEmployees' and it
    > returns a List of Employee objects.
    >
    > I'm looking for what other people are doing and if you feel this is a good
    > or bad idea.
    >
    > Thanks
    >
    >


    Somebody tell me what a "general domain class" is. I've not heard of
    that yet.

    - john
    John Davison, May 27, 2004
    #6
  7. Axehelm

    Chris Smith Guest

    > "Axehelm" <> wrote:
    >
    > >I'm personally not a fan of static methods but we seem to be using them to
    > >load an object. For example if you have an Employee class rather then
    > >instantiating an instance you call a static method 'GetEmployees' and it
    > >returns a List of Employee objects.
    > >
    > >I'm looking for what other people are doing and if you feel this is a good
    > >or bad idea.


    Roedy Green wrote:
    > sounds like a standard factory design pattern. See
    > http://mindprod.com/jgloss/factorymethod.html
    > http://mindprod.com/jgloss/designpatterns.html


    Indeed that seems to be what it is, but that doesn't help answer the
    question about whether it's a good idea. Here's an attempt to answer
    that question.

    1. Simple static factory methods

    If a static method returns a single instance of Employee representing
    its parameters, then there is a trade-off between that static factory
    method and a constructor. The constructor is, obviously, much clearer
    about what it's doing, but suffers from the limitation that it has to
    return a new object. Depending on performance concerns and design
    considerations, this may or may not be acceptable.

    For example, if you treat Employee as a value object (i.e., it's
    immutable, and overrides equals() and hashCode() to specify that it's
    equal to any other object with the same state), then returning a new
    instance isn't a problem for program correctness -- although performance
    may still be a concern. But if you treat Employee as an entity object
    (meaning that it's mutable and fails to override equals() and hashCode()
    methods), then uniqueness of instances -- at least within a transaction
    -- is probably critical for the program to work correctly, and a
    constructor is just not possible.

    2. Other methods

    Something other than a static factory method has to live somewhere, so
    for example the "getEmployees" method mentioned earlier would need to
    either be static or live in a separate class.

    The typical way to solve this is to introduce what I often call a
    "universe class". That is, a class of which there's only intended to be
    one instance within a single context (i.e., transaction or session),
    which represents the entire scope of the system. The word universe is
    used in the set theory sense: basically you ask "what's the universe
    from which this application finds employees?" That is, it probably
    doesn't deal with all employees of all companies in the whole world. It
    might deal with employees of your company (in which case the universe
    class may be called Company), or in your department (in which case the
    universe class may be called Department). The static method on the
    Employee class may then become an instance method on the universe class.

    The choice between static methods and a universe class is clarity and
    flexibility versus complexity. Clearly, introducing the new class adds
    a bit to the complexity of the solution. For one, you need a way to get
    an instance of the universe class... outside of a transactional
    environment, it may just be a singleton; but in a transactional
    environment, things get a little more interesting. On the other hand,
    you have a natural place for a good bit of functionality that deals with
    the whole collection of employees, and you get the flexibility of
    maintaining per-transaction state for the containing entity, and perhaps
    even expanding the scope of the application in the future.

    --
    www.designacourse.com
    The Easiest Way to Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
    Chris Smith, May 27, 2004
    #7
  8. Axehelm wrote:

    > Okay, I'm in a debate over whether or not static methods are a good idea in
    > a general domain class.
    >
    > I'm personally not a fan of static methods but we seem to be using them to
    > load an object. For example if you have an Employee class rather then
    > instantiating an instance you call a static method 'GetEmployees' and it
    > returns a List of Employee objects.
    >
    > I'm looking for what other people are doing and if you feel this is a good
    > or bad idea.


    Static methods are good and appropriate in many situations. The main
    differentiator, between static methods and instance methods is that the
    former are not polymorphic. A secondary differentiator is that static
    methods don't have access to a "this" object, but any instance method
    that does not need to be polymorphic can be turned into a static method
    on the same class by adding a parameter representing the object on which
    to operate (i.e. a substitute for "this"). Where you have a choice
    between the two, which you should choose is largely a matter of style,
    convention, and preference.

    To be sure, many situations fall much more naturally on one side or the
    other. The strategy I described for making an instance method into a
    static one is probably a bad idea most of the time, for example. If in
    doubt, err on the side of the instance method. On the other hand, don't
    be bigoted against static methods -- as with many things, you need to
    evaluate on a case by case basis.

    --
    John Bollinger
    John C. Bollinger, May 27, 2004
    #8
  9. Axehelm

    Roedy Green Guest

    On Thu, 27 May 2004 07:09:41 -0600, Chris Smith <>
    wrote or quoted :

    >
    >The choice between static methods and a universe class is clarity and
    >flexibility versus complexity.


    It boils down to:

    Static is easier, but instance lets you change your mind later and
    override or fine tune the factory.

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, May 28, 2004
    #9
    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. Kumar Vijay Mishra

    PSL pros and cons

    Kumar Vijay Mishra, Sep 29, 2004, in forum: VHDL
    Replies:
    2
    Views:
    2,582
    vhdlcohen
    Oct 2, 2004
  2. Benny
    Replies:
    1
    Views:
    429
    Paul Wistrand
    Mar 1, 2004
  3. Maric Michaud

    threading and multicores, pros and cons

    Maric Michaud, Feb 14, 2007, in forum: Python
    Replies:
    24
    Views:
    1,144
    Paul Boddie
    Feb 20, 2007
  4. static cons v/s cons

    , Dec 7, 2008, in forum: C Programming
    Replies:
    5
    Views:
    450
    James Kuyper
    Dec 8, 2008
  5. Judson Lester
    Replies:
    0
    Views:
    90
    Judson Lester
    Dec 15, 2007
Loading...

Share This Page