Skip to main content

(Not So) Stupid Questions 21: All Statics

January 29, 2009

Editor's note: Sometimes the most interesting discussions begin when someone says, "This may be a stupid question, but ...." If the person asking the question has taken the time to think about the problem before asking, the question is often not stupid at all. The uncertainty points out an ambiguity in the specs, holes in the docs, or a search for how more experienced programmers might address a particular problem. From time to time, we will print one of the "(Not So) Stupid Questions" we receive and invite our readers to answer the question in the feedback section.

Remember that new people are joining the Java community all the time and may be looking for help from those with more experience. Also, those who began with Java as their first language can benefit from those coming to the community with experience in other languages. As always, answer the questions with kindness. You are also welcome to submit your questions to

This may be a stupid question, but ... "Is it a bad idea to make all our methods static?"

First thoughts:

I have a question that I am very confused about, and I don't know how it is affecting my application. We have one application that uses Struts.

In the DAO, where we write the business logic, we made all the methods static.

By definition, statics are called by their class name, so in our Action and DAO classes, we just call these static methods.

is this a good approach? If not, what would work better?

width="1" height="1" border="0" alt=" " />
Related Topics >> Programming   |   


wrong or not?

In the context of a multithreaded application (which all webapplications implicitly are) using static methods (except potentially static factories) is a bad idea as they're inherently single-threaded, causing a very real risk of data corruption and performance trouble.

In single threaded applications (which really don't exist in Java, but for most purposes the small systems many beginners write can be considered such) that's however not a problem. Of course you're no longer working in an object oriented fashion, but are rather following procedural programming paradigms. While not fundamentally flawed, one has to wonder why one would use an object oriented language for the purpose of procedural programming when there is a plethora of languages designed for it out there, languages like Pascal, Modula, Fortran, C, and many others.

wrong or not?

In the context of a multithreaded application ... using static methods ... is a bad idea as they're inherently single-threaded, causing a very real risk of data corruption and performance trouble. The assertion that static methods are "inherently single-threaded" is wrong. Static methods behave identically to non-static methods: they will be executed in the calling thread's context, using one execution stack per thread. Thread-safety is all about shared data. Whether you get synchronization on shared data right or wrong has nothing to do with using static or non-static methods.

wrong or not?

Ditto. One of the consequences of having only static methods is that you can't have polymorphism. This means that you can't mock the DAO for making unit tests (or simple integration tests) of the business tier. Independently on any consideration on OOD, functional, etc... this is the worst point IMO since it has an impact on quality.

wrong or not?

At least in an environment not under your control, static context can be very bad. fabriziogiudici also makes a very valid comment about testability which may become virtually impossible. Imagine such a class being referred to but in another layer which for instance provides resource access. No (at least convenient) way to mock that. Its hard coded in your class and you would have to wrap it into an interface on your own. Any client code would have to in order to be testable. For other drawbacks of static stuff see my blog on that matter.

definitely not a good idea

creating a DAO layer made of static methods means: - not coding against an interface but against an implementation - not being able to use dependency injection to wire-up the DAOs - not being able to use AOP-style interceptors (at least not using dynamic proxies) to do logging, performance measurement, transaction demarcation, etc. - having access only to static fields in the DAO - and many more many other disadvantages of static methods (no polymorphism, no overriding, etc.) are probably not that important in the case of DAOs. all in all: not a good idea. cheers, gerald

definitely not a good idea

I've been coding DAOs for a long time and in the last few years I've used Stored Procedures exclusively. Although I've nearly always used instance methods, my classes never have state and not once have I had the need to use polymorphism or other OO or AOP technique. Therefore, althought writing instance methods seems a more prudent and flexible approach, in reality you will probably not need the extra flexibility.

procedural programming style is easy, even if less powerful

First of all, I can see the issues with threading, injection, testing, polymorphism and so on. On the other hand, you might want to define a really simple way of programming, with as few concepts as possible. For example, your system or problem domain might be simple, your wiring and testing requirements minimal and your developers trained in pre-OO concepts only. Then static methods and procedural programming will save the cost of teaching and comprehending OO concepts. I think Fowler discusses a similar trade-off in Enterprise Patterns, between a procedural and a "strong OO" domain layer.