The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Refactroing and static methods

I am working on a product,which already has some features(windows forms,C#).But,code is not too easy to read.Most of functions are long,lot of code is repeated.I am refactoring code,and most time I find I am putting common code,in a class in a static method.This has one good affect,atleast now there is only one place where changes will have to be made,if need arises.
But,i am wondering having classes with static methods in long run will have any issues? We have no unit tests,in place now.
Sunday, June 03, 2007
How can you refactor without unit tests? Writing them should be the first thing to do when refactoring.

Not having any unit tests is not nice, but at least the new static methods you write should be covered.
TM Send private email
Sunday, June 03, 2007
I wouldn't worry about object-oriented purity at this point -- right now, you should just get the code to where it's testable and maintainable.
xampl Send private email
Sunday, June 03, 2007
In my experience, static methods tend to get in the way of future refactorings, so you end up spending time refactoring to get rid of them.

However, YAGNI, so go with what works now.
Chris Tavares Send private email
Sunday, June 03, 2007
Why are you putting the common code in *static* methods? Are you merging common code between different classes or is the code common between instance methods and class methods in the same class?

If you just have common code between several instance methods on the same class, then you can just factor that code into a new instance method: no need for the class (static) method. If the code is 'common' between several classes, then I would question whether it is really common at all: the code may read identically, but it is almost certainly referring to different class and instance members in each class in which it appears.

The only time you need a class (static) method is when you are going to do something without an instance of the class around (such as constructing a new instance). If the common code is called from within existing instance methods, then, by definition, you have an instance of the class handy: no need for class methods.
Jeff Dutky Send private email
Sunday, June 03, 2007
To Jeff

Sometimes the common code although called from instance method doesn't use or affect the object state (i.e instance data members), in which case it is perfectly acceptable to use static methods.
Sunday, June 03, 2007
Static methods good.
Static variables bad.
Monday, June 04, 2007
Using a Singleton pattern with instance methods will give you better options in the future.  I'm going through a refactoring of moving many static methods to the instance side to allow for better decoupling in future refactorings.  It's a pain so don't do what I did.
a non anon
Monday, June 04, 2007
Remember, the GC loves small objects. They are cheap to create (10 instructions!) and easy to recycle. You might enjoy reading this tech session from JavaOne:

A lot of people make static methods classes / singletons for utilities, because they think there is no reason for an instance. In reality, they are misusing the power and should just create a new utility object and throw it away.

Generally I try to use statics only for factory methods, singletons (e.g. caches), or variables that will span all instances and are heavy to create. Using a static for utilities or final class variables is premature optimization.
Benjamin Manes Send private email
Monday, June 04, 2007
Is a class with static constructor and with only static methods more expensive than a short lived object?
Friday, June 08, 2007
Hi Benjamin,
you say "Using a static for utilities or final class variables is premature optimization."

In what way its premature optimisation?
Saturday, June 09, 2007
Hi ravi,
To the best of my knowledge, once static data is loaded it cannot be unloaded by the JVM. This makes sense, because otherwise you would be recreating data that is meant to be initialized once across all instances of that class. In many ways a purely static class is like a singleton and you cannot reclaiming the memory. Thus, it would be more expensive long-term for short lived objects.

Most static utility classes I see are only needed in modestly used scenarios, so instantiating a light-weight object is better.  Similarly static final variables, which often are just private Strings or numbers, are light enough that you don't gain anything by keeping them in memory for long periods.

Personally, I try to use statics only for data that is heavy to instantiate and needed once, singletons, and factory methods. Sometimes the less you use a trick, the cleaner and more flexible the code!
Benjamin Manes Send private email
Tuesday, June 12, 2007
Hi Benjamin,
you make a good point.Using static methods based class is a trick,and less flexible.I will go over my codebase,and try to think how to do away with static classes.I am sure i will gain more insight.
Wednesday, June 13, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz