Java static methods can be a code smell

Definition of code smell (from Wikipedia):



“any symptom in the source code of a program that possibly indicates a deeper problem.”

In Java,
static methods allow you to execute code at a “class scope” as opposed to an instance scope like member methods. This means, they rely on class-level variables (if any), parameters passed to the static method, or any other globally accessible data. They are NOT object oriented. An object has state associated with it and can be manipulated only through methods that implement the object’s “behavior.” Static methods do not operate on state, they are not object oriented, and in fact they are procedural.

Is this bad?

No. Although Java is object oriented, there will be times when procedural-like programming in Java is necessary and/or preferred. The real power in any object-oriented language is the ability to closely implement a model of real-life systems in code (see my
post about object-oriented modeling). But even in the most hard-core object models, there will mostly likely be some glue code, or infrastructure code that will be implemented in a procedural style.

So if procedural-like programming in Java isn’t “that bad” and static methods are a form of procedural programming, are static methods bad?

Ahh… the answer isn’t as simple as a “yes”, or a “no” regardless of what you may read on other blogs But I could probably ramble on and on about why it’s really a decision that has to be made in context, so let’s keep this article focused by examining a set of statements that I encountered in
“How to Mock Static Methods” from Michael Minella’s blog:

“Something that has become a fundimental [sic] piece of the language (all you need to do is look at the Apache Commons project to see that) is so bad that it must be avoided at all costs in the name of testing. Gosling (or someone on his team) put it in the language for a reason and to avoid those uses solely because your toolset doesn’t support the testing of it is nonsense. Time to get a new toolset.”

First, I’d like to point out that just because something has become a fundamental piece of a language doesn’t mean it’s “good” or something that should be done. Take a look at
checked exceptions for reference. I recall EJB 1.x and 2.x becoming a “fundamental” piece of Java EE in the past, so look at that for reference too.

Second, although I do agree with Michael in theory that avoiding a particular language feature because your tools don’t support it is silly, his premise is focused on static methods. Avoiding static methods because your tooling doesn’t support them is NOT nonsense at all. In fact, the type of impedance caused by some of the good testing and/or mocking frameworks (of which
Mockito is my favorite
:) ) and static methods can be confidently identified as a code smell. This does not mean we should not do it, but we should exert extra effort to understand why we are doing it and explore alternatives if there are “deeper problems.”

There are at least two types of static methods that I would like to point out don’t usually show much impedance with testing/mocking frameworks. The first type is static methods used as utility methods, as those found in a lot of the
apache commons libraries, or your own internal commons libraries. These are usually routines that are supportive of a particular method’s objective, and mocking/stubbing them out of a unit test wouldn’t make sense. They are part of the implementation, and should be tested as such. The second type is static methods used in place of constructors as Joshua Bloch showed in his book
“Effective Java.” This use of static methods allows you to construct a new object using a method with a very descriptive name, among some other advantages. An offshoot of this second type of static method could include factory methods, but that would depend on context.

The most glaring code smell as a result of static methods and testing-framework impedance arises when a unit relies on a static method that performs logic outside the scope of the responsibility of that unit. In these cases, your testing framework will fight you because you cannot stub/mock the out-of-scope logic because it is “hardcoded” via a static method. This can be considered a “deeper problem” and is the focus of most blogs that tell you not to use static methods because testing becomes abnormally difficult or impossible. Changing the design approach to follow the Dependency Inversion Principle is one alternative. A better understanding of how to test the unit is yet another.

I assert strongly that in the case of static methods, the push-back you may get from your testing frameworks is indicative of a code smell, not that you need to try and find a framework that uses complex trickery with class loader remapping as a solution. One should be poised to evaluate the use and fundamental drawbacks of a particular approach in their design. Michael’s blog entry lends the reader to too easily assume a new tool/framework just because Java supports static methods and your current testing frameworks illuminate an impedance — in this case, the impedance reflects a code smell and some deeper, more critical thinking is required.


Reference:
Java static methods can be a code smell from our
JCG partner Christian Posta at the
Christian Posta Software blog.

Source : http://www.javacodegeeks.com/2012/05/java-static-methods-can-be-code-smell.html

Statement driven development

Today most methodologies used model oriented approach.
It can be domain-driven or reverse-engineering, one common point is that they start from a static definition of a model. For domain-driven, it is the domain issued by the development language itself. For the reverse-engineering it starts from a static model structure definition ex: a xsd, wsdl, database schema. 
Statement driven development focuses on the actions the developer can run on some models and not the models themselves.


 Example: a select statement fetching all the group members a user with group-administrator-role can manage.
 Here the statement can be materialized into a search query with sql as implementation.
The important thing for the developer is the query and its I/O not really the underneath model and … not the decorative technology.

Why Statement-Driven-Development

Couple of articles and limitations make me think that statement driven approach can be a flexible and fast alternative for developpers.
Usually after defining an abstract model such as ORM, the user have to write his UC statements. This means that
there is still this second step to perform.

The model is sometimes/often overkill. As a developer, you do not have to apprehend the entire model complexity before yielding productivity.

Limitation on standard 

Like in the JOOQ
article about function and stored procedure extracting the meta-information can reach some limits when entering in vendor specific particularities.

Native DSL 

There is a trend that states that SQL is the only DSL you need.
Why should you wrap it with other technology abstraction that limit its power?

Bye-Bye Domain Objects 

…Welcome DTO. 
I/O are by essence DTO (why should they be the exact reflection of a persistence layer?). This situation is just a specific exception. 
This exception is widely used by multiple apps/framework (strong resuability but limitations).
 
Remark: This article is not there to cover the ‘everlasting-debate’ DO vs. DTO. SDD just brings a new approach that do not exclude but complement the DDD/Rev-Eng one.
 

Concretely 

MinuteProject for release 0.8.1+ (mid-may-2012) will offer Statement-Driven-Development facilities.
  • The user will focus one SQL statement.
  • The output will be deduce by the execution of it.
  • The input will be easily configurable.

Example 

Here is a simple configuration. Statement-model is the new node.
  <model>
    ...
      <statement-model>
           <queries>
               <query name="get address street">
                  <query-body><value><![CDATA[select * from address where addressid > ?]]></value></query-body>
                  <query-params>
                      <query-param name="identifier_Address" is-mandatory="false" type="INT" sample="1"></query-param>
                  </query-params>
               </query>
           </queries>
      </statement-model>
  </model>


This configuration should be enough to get:
  • Input bean
  • Output bean
  • Output list bean
  • All the technology decoration ex for REST CXF:
    • Resource bean with REST path
    • spring config
    • Native DAO
Demonstration will be shipped in Minuteproject next release (0.8.1).

Integrating with REST is pretty much statement-driven: basically you just need to know the URL + its I/O.

Conclusion
 
  • With SDD you focus on the statement and the I/O.
  • Minuteproject simplifies the rest (technology wrapper).

Reference:
Statement driven development from our
JCG partner Florian Adler at the
minuteproject blog blog.

Source : http://www.javacodegeeks.com/2012/05/statement-driven-development.html