my dog learned polymorphism*
The moose likes Agile and Other Processes and the fly likes Role of static utility methods Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Role of static utility methods" Watch "Role of static utility methods" New topic
Author

Role of static utility methods

Gopal Shah
Ranch Hand

Joined: May 17, 2003
Posts: 65
Hi All,

I have been following the XP practices of writing unit test cases, then refactoring the code, etc.

I just noticed that my design hardly has any place for static util methods, especially if the method belongs to a 3rd party library.

e.g. if I were to test the following method:



Observation:
Typically computeCos..() is just a plain utility method, but I am tempted to make it an instance method of some object like MyMathUtils.

This is becoz when I am testing client code, I wud like to make a mock object MyMathUtil object (When testing client code, MyMathUtil is a secondary object)

I have given a simple stupid example of computeCosFun.., but consider a really complex static util method which itself invokes static native library methods, it would be very difficult to write test cases for the clients of MyMathUtil.computeCos...()

Easiest thing is to make computeCos...() an instance method of MyMathUtils even though I realize it doesn't use any state of MyMathUtils.

Eventually I realize there is hardly any role for static util methods when following Agile methodology

Any thoughts ?

Regards,
Gopal
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I think you've found there is not much place for statics in "good" design, where "good" has a definition involving flexibility and testability. You'll find much agreement with your conclusions.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Gopal Shah
Ranch Hand

Joined: May 17, 2003
Posts: 65
Thanks James. Is this a proven fact ? Are there any articles on this topic and is it considered a best practice.

I thought/considered Sun's Java APIs (especially java.lang) were very well designed. I know Sun doesn't use Agile methodology but then does that mean Agile leads one to a design which is different from traditional OO design.

Could there be performance issues, I am working on embedded environment. Martin Fowler & team preach that you shouldn't worry about performance in the beginning, but then I am wondering why "static behavior was introduced in the first place". Static state is shared across all the instances of the Class, but static behavior is typically a util method which could belong to some or other object. If the language didn't support static methods, then lots of bad coding practices could have been avoided (Java code written in procedural lang style).
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
Static (class) methods have both advantages and disadvantages. I do just about all of my software development using an agile, test-driven approach, and I find that my designs still find a use for static methods.

The main advantage of a static method is that it does not need an object instance to be constructed in order to use it. This means it can be used from anywhere in the system without either: passing in an object (clutters constructors and/or method signatures), creating an object just to discard it (a pointless waste of resources), or messing with Singletons (vastly overused, dangerous, and a candidate for "anti-pattern" status).

The main disadvantages of a static method are that: (a) it ties the client code to a particular class implementation, thus preventing substitution with a different implementation at run time (b) it prevents child classes from overriding the behaviour, and thus severely limits the options for polymorphism. These make static methods a poor choice for behaviour which might benefit from being replaced for testing or for configuration using run-time "wiring" or compile-time overriding.

For me, static methods still have their place, though. Static methods are really good at making small chunks of general-purpose behaviour available to many places in a class hierarchy. For example, I use static methods for the following common situations:

Converting an object to a printable string representation without risking NullPointerExceptions:



Converting a string to an integer and gracefully handling missing values or parse problems:



And so on. Each of these cases would otherwise clutter up the application with "copy and paste" boilerplate code.

These static methods are small enough, fast enough, and simple enough that I feel I can rely on their unit tests to ensure that they work correctly, then just use them wherever required. For me, something such as:



Seems a pretty good expression of my intent.

Do I make sense?


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
I mostly agree with both Stan and Frank.

In testable code, there is still a place for utility methods, but it really prevents you from overusing them.

I actually don't see a general problem in instantiating an object just to call a method on it and discard it afterwards.

And I don't think that the JDK is a poster child for "traditional OO design". The first popular OO language was Smalltalk, and the OO principles we are rediscovering by applying Agile approaches are often well known in the Smalltalk community for decades know. Which is not too surprising - a lot of the Agile founders have a strong Smalltalk background.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Gopal Shah
Ranch Hand

Joined: May 17, 2003
Posts: 65
Thanks Frank & Ilja, makes sense. So small well tested static util methods are acceptable but not as Component interfaces or for methods with side effects.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I've been burned by using static methods as a typing shortcut. For example in my little projects I use

Logger.log( "message" );

because it's short and easy. I'm stuck with dragging my Logger along with any class I want to reuse in a new project even if that project has its own logger.

In my big work project we have a cache with static methods. We inherited this from a vendor so I'm not sure of the original reason. Later we wanted two caches with different life spans so somebody (was it me?) copied the class to a new name. That doesn't sound good, does it? Later again we wanted to have two or three different implementations of caching, so now all the static methods call non-static methods on an implementation object. Now we can swap in implementations with different tuning algorithms or instrumentation for debugging. Whew, a factory for non-static caches would have been nice in the first place.
 
jQuery in Action, 2nd edition
 
subject: Role of static utility methods