Static methods verus Instance methods

Discussion in 'Java' started by lightning, Oct 28, 2008.

  1. lightning

    lightning Guest

    In project, I feel that using SomeClass.someMethod() is very
    convenient and quick to deal with sth.
    e.g:
    MailUtil.sendMail(String from,String to,String text) throws
    XXXException...

    In fact, I worte so much code to make tool methods in this way and
    feel that not only me myself feel good but also others using my code
    feel good.

    However,
    the code like:
    SomeClass x= Somelocator.getSomeinstance();// or SomeClass
    x=new ....
    x.someMethod();

    bothers us more.

    What's the advantage of using instance methods instead of using static
    methods in making tool methods?
    Memory issue? GC or jvm issue? Or just design pattern issue?
     
    lightning, Oct 28, 2008
    #1
    1. Advertising

  2. lightning

    Mark Space Guest

    lightning wrote:

    > Memory issue? GC or jvm issue? Or just design pattern issue?


    In my opinion, since static methods are not polymorphic in Java, you
    can't conveniently change implementations or code to an interface.

    Given a program that uses this static method:

    public class Utils {

    public void largeExpensiveFileIO( File f ) { //...

    }

    One cannot easily switch implementations of largeExpensiveFileIO to a
    test harness. You'll have to rig up a test class yourself.

    public interface MyUtils {
    public void largeExpensiveFileIO( File f );
    }

    class TestUtils implements MyUtils {
    @Override
    public void largeExpensiveFileIO( File f ) { //... test stuff
    }

    class LiveUtils implements MyUtils {
    @Override
    public void largeExpensiveFileIO( File f ) {
    Utils.largeExpensiveFileIO( f );
    }
    }

    Now you have a pair of classes you can easily test with. Code
    everything to the interface, then inject the class you want (test/live)
    at runtime.

    Which is better, provide an interface for your callers, or make them rig
    up a specific interface for their own problem domains? Heck if I know.

    If the static methods work, I think there's no reason not to use them.
    Do think a bit beyond just writing code and towards testing, maintenance
    and latter modification and extension. But if those can't be easily
    foreseen, I think static methods are adequate.
     
    Mark Space, Oct 28, 2008
    #2
    1. Advertising

  3. lightning

    Lew Guest

    On Oct 28, 3:36 am, "Peter Duniho" <>
    wrote:
    > On Tue, 28 Oct 2008 00:19:45 -0700, lightning <>  
    > wrote:
    >
    > > [...]
    > > What's the advantage of using instance methods instead of using static
    > > methods in making tool methods?
    > > Memory issue? GC or jvm issue? Or just design pattern issue?

    >
    > IMHO, there's no reason not to make a method static unless it has to  
    > access instance members of the class.  That's practically "by definition",  
    > as far as I'm concerned.
    >
    > There are numbers of examples of classes, often utility classes, that are  
    > _nothing_ but static methods.  There are some slight performance  
    > considerations, where static calls can have less overhead, but IMHO the  
    > main issue is simply one of design.  Don't give your code more access than  
    > it needs, and don't make callers make and/or use an instance if the code  
    > is never going to actually take advantage of data in the instance.


    IMO, though I see the value of Peter's advice, there's no reason *to*
    make a method static unless it absolutely must represent global
    behavior from a design standpoint. Even if the method doesn't access
    instance state, there's no harm in having it be an instance method.

    Provided you have an instance available anyway.

    I believe this makes thread-safety and possible future refactoring
    easier. It also supports overriding the method in subclasses (if
    heritable) and simplifies the reference to the method. (No need for a
    class reference when 'this' is here.)

    Static methods are for factories and non-instantiable classes, the
    rest of the time I use instance methods unless the behavior is truly
    intended to represent class-wide behavior.

    Just another POV. I would not ding a module in code review for
    following Pete's standard, nor for declaring an instance method that
    doesn't access the instance's state (again, provided you have an
    instance anyway).

    In that way, my standards are similar to those I use for brace
    placement in control structures. While I believe it's more logical
    and easier to read to have the opening brace on its own line, it's a
    well-established convention to have it on the end of the condition
    line, so I don't ding either approach.

    To summarize:
    Static methods represent global behavior, and are best used as factory
    methods and in non-instantiable classes. Instance methods must be
    used in order to access instance state, and may help even absent that
    if you want the ability to override them. When in doubt, Peter will
    call for a static method, and I will call for an instance method
    whenever access is via an instance anyway.

    --
    Lew
     
    Lew, Oct 28, 2008
    #3
  4. lightning

    Arne Vajhøj Guest

    lightning wrote:
    > In project, I feel that using SomeClass.someMethod() is very
    > convenient and quick to deal with sth.
    > e.g:
    > MailUtil.sendMail(String from,String to,String text) throws
    > XXXException...
    >
    > In fact, I worte so much code to make tool methods in this way and
    > feel that not only me myself feel good but also others using my code
    > feel good.
    >
    > However,
    > the code like:
    > SomeClass x= Somelocator.getSomeinstance();// or SomeClass
    > x=new ....
    > x.someMethod();
    >
    > bothers us more.
    >
    > What's the advantage of using instance methods instead of using static
    > methods in making tool methods?
    > Memory issue? GC or jvm issue? Or just design pattern issue?


    It is rather common to use static methods in FoobarUtil and FoobarHelper
    classes.

    As a general rule though be careful only to create static methods when
    you are absolutely sure that they will stay static forever. It is very
    common to start with static methods and then have to refactor to
    non-static methods later when requirements become more complex. I have
    never seen the other direction. So if in doubt make it non-static.

    Arne
     
    Arne Vajhøj, Oct 28, 2008
    #4
  5. lightning

    Daniel Pitts Guest

    lightning wrote:
    > In project, I feel that using SomeClass.someMethod() is very
    > convenient and quick to deal with sth.
    > e.g:
    > MailUtil.sendMail(String from,String to,String text) throws
    > XXXException...
    >
    > In fact, I worte so much code to make tool methods in this way and
    > feel that not only me myself feel good but also others using my code
    > feel good.
    >
    > However,
    > the code like:
    > SomeClass x= Somelocator.getSomeinstance();// or SomeClass
    > x=new ....
    > x.someMethod();
    >
    > bothers us more.
    >
    > What's the advantage of using instance methods instead of using static
    > methods in making tool methods?
    > Memory issue? GC or jvm issue? Or just design pattern issue?

    Design pattern is the common one. I have several times had to refactor
    from static methods into a instance class. I have *never* had to
    refactor the other way.

    Now, it depends on what the use of method is, and if it depends on other
    methods itself.

    If it is a simple method that is basically a "functional style" function
    (meaning no state is used or modified during the call), then it is "safe
    enough" to use static.

    If it is a method that makes lots of other callbacks or calls many other
    static methods, it might make more sense to put it, along with a lot of
    the other calls, into there own class.

    As for memory/gc, creating an instance takes a minuscule amount of
    memory, and static takes slightly less. The benefits of instance
    methods are they are polymorphic and can have state.

    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
     
    Daniel Pitts, Oct 30, 2008
    #5
    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. Neo
    Replies:
    1
    Views:
    531
    Scott Allen
    Jan 7, 2005
  2. =?Utf-8?B?RGlmZmlkZW50?=

    Advantages of Static Vs Instance methods?

    =?Utf-8?B?RGlmZmlkZW50?=, Jan 13, 2006, in forum: ASP .Net
    Replies:
    9
    Views:
    31,315
  3. Paul Butcher
    Replies:
    12
    Views:
    750
    Gary Wright
    Nov 28, 2007
  4. Leon Bogaert
    Replies:
    19
    Views:
    339
    Robert Klemme
    Mar 23, 2008
  5. Kenneth McDonald
    Replies:
    5
    Views:
    342
    Kenneth McDonald
    Sep 26, 2008
Loading...

Share This Page