Java – Static Methods vs Interface Implementation

designdesign-patternsinterfacesjavastatic methods

Here is my problem:

I stared to create an e-commerce web site info collector.

So I created a parser for each site.
The parser class is stateless.

I have got methods like:

getItemPrice(WebElement page)
getItemTitel(WebElement page)
getItemDescription(WebElement page)
etc..

While creating a JUnit tests for that the convenient way was to make them static methods.

While creating the next parser for the next page ,again I needed the same methods.
So it just popped out that an interface of an IItem is required here for future changes, etc.
Therefore I have a problem to set these methods as static.
Which require to create an instance of a stateless class which lead to simple factory to create these instances etc.

I'm not sure whether this Interface is causing me too much of an overhead or not.

Any ideas?

Best Answer

I don't think there will be too much overhead when using an interface. You can even argue that the use of static methods could generate more overhead in this case, depending on how much different implementations you want to support and how many methods you need.

When using static methods, you need to have some logic which implementation you have to use, which is basically a big switch statement for every method. This can be simplified by putting a wrapper around all those implementations, but evaluating the same switch statement over and over again for each method you want to call is not really advisable.

With the use of interfaces this will be reduced to just one evaluation of the switch statement (in the factory).

Related Solutions

Java – How to deal with static utility classes when designing for testability

(No "official" sources here, I'm afraid - it's not like there's a specification for how to test well. Just my opinions, which will hopefully be useful.)

When these static methods represent genuine dependencies, create wrappers. So for things like:

ImageIO
HTTP clients (or anything else network-related)
The file system
Getting the current time (my favourite example of where dependency injection helps)

... it makes sense to create an interface.

But many of the methods in Apache Commons probably shouldn't be mocked/faked. For example, take a method to join together a list of strings, adding a comma between them. There's no point in mocking these - just let the static call do its normal work. You don't want or need to replace the normal behaviour; you're not dealing with an external resource or something that's hard to work with, it's just data. The result is predictable and you'd never want it to be anything other than what it'll give you anyway.

I suspect that having removed all the static calls which really are convenience methods with predictable, "pure" outcomes (like base64 or URL encoding) rather than entry points into a whole big mess of logical dependencies (like HTTP) you'll find it's entirely practical to do the right thing with the genuine dependencies.

Java EE – Handling EJB Exceptions with Multiple Implementations

You can use:

@Stateless(name="online")
public class DataAccess_Online implements DataAccess { ... }

@EJB(beanName="online")
DataAccess da;

Best Answer

Related Solutions

Java – How to deal with static utility classes when designing for testability

Java EE – Handling EJB Exceptions with Multiple Implementations

Related Topic