Java Design – Using Abstract Methods as Static Methods

designjava

In an attempt to write some generic code I find myself putting, in my abstract class, a method that returns some static information about how the class should be treated. This method doesn't use any state data and would be static, except that static abstract methods aren't allowed. Is this a code smell? is there something one should do to avoid this?

I haven't writtent he real code yet. Here is a quick example, conceptually. Little slopy programing wise to make to make it a quick read. basically a way for the code to return information to the model, in this case, about how it should be treated within the generic functions of the model. Assume the enum stored whatever configuration state in this case.

public abstract modelObject{

    public abstract ModelGroup getModelGroup;

    public final void addToModel(){
        Model.store(this.getModelGroup, this);
    }
}


public class myObject extends modelObject{
    public ModelGroup getModelGroup(){
        return ModelGroup.MyGroup;
    }
}

public class DifferentClass extends ModelObject{
    public ModelGroup getModelGroup(){
        return ModelGroup.differentGroup;
    }

}

Best Answer

Preferably, rather than providing properties that specify how the object should be treated, the class-dependent behavior should instead be encapsulated inside an abstract method. For example, use:

obj.doSomething(); // Abstract method - subclasses override with appropriate behavior

instead of:

if(obj.getModelGroup() == ModelGroup.MyGroup) {
    doSomethingWith(obj); // Behavior specific to one subclass
} else {
    doSomethingElseWith(obj); // Behavior specific to another subclass
}

Having said that, there are perfectly legitimate cases where implementers of a method might not use instance-specific state.

As an example, consider the java.sql.Driver interface (it's not an abstract class, but it easily could be). If you have a separate class for each type of driver, its methods probably don't require any instance-specific state. The jdbcCompliant, getMinorVersion, and getMajorVersion methods likely return hard-coded constants. The acceptsURL and connect methods likely have behavior that isn't instance-specific.

In short: it depends. Not using instance state in an abstract method implementation isn't inherently wrong; however, in some cases it may indicate that your code could benefit from being restructured.

Related Solutions

Java – Mocking static methods

Generally speaking, @KonradMorawski's answer is good and complete. However, I would like to add that there is one scenario that I would consider it valuable to mock static methods - the static factory method.

Personally, in my code I very infrequently use static factory methods; I only use them if the created object is stateless, the factory is stateless, and the created object has no dependencies - and even then I'm still not very likely most of the time. Otherwise, I use an instance of a factory object, which can then be mocked.

The issue with using a static factory method as provided is that the created objects will not be mocks or spys, which means you will not be able to call verify on them, and you will not control access to these objects in advance. For example consider a math application like the following:

public abstract class ComplexNumber {
    private double realPart;
    private double imaginaryPart;
    ComplexNumber(double realPart, double imaginaryPart) {
        this.realPart = realPart;
        this.imaginaryPart = imaginaryPart;
    }
    public static ComplexNumber create(double realPart, double imaginaryPart) {
        return new ComplexNumber(realPart, imaginaryPart);
    }
}

public class RootCalculator {
    // Whatever is appropriate
    public List<ComplexNumber> roots(double... coefficients) {
        // somewhere in the code
        ComplexNumber number = new ComplexNumber(something, somethingElse);
        // blah blah
    }
}

public class RootCalculatorTest {
     @Test
     public testCalculator() {
         RootCalculator calc = new RootCalculator();
         List<ComplexNumber> roots = calc.roots(1, 0, 1); // equivalent to x^2 + 1 = 0
         for(ComplexNumber number : roots) {
             // verify(...);
         }
     }
}

Note that you can't call verify on the returned complex numbers, nor can you verify that the factory method itself was called the correct number of times. With PowerMock you can do both. Note that using PowerMock here is superior to just calling new ComplexNumber().

Of course the best way to do it is just inject an instance of a factory, which can then be mocked, avoiding PowerMock and allowing you to do all the normal testing behavior.

C# – Empty virtual method on base class VS abstract methods

In this case the base class should know nothing of SectionA. The derived class should implement the extra properties that that type needs.

For certain operations where another class needs to pull information out regardless of the type of document you will want that method on the base class ideally virtual with a basic implementation and allow derived classes to override it if needed (eg ToPlainText which would just output all the sections of a document would be on Document, FancyDocument can override the implementation to also output SectionA).

For instances where another class doesn't care about the type of document but does care if it has certain properties use interfaces. IDocument would have all the common sections and Document would implement it. IDocumentWithSectionA would inheerit IDocument and FancyDocument would implement that. This then lets you derive another NeitherFancyNorNotFancyDocument that has SectionA which can also implement IDocumentsWithSectionA.

Obviously You'd have more useful names than IDocumentWithSectionA but that depends on the usecase.

TL;DR use the abstract class for what should be common to all documents and some common functionality, use interfaces as the contract saying what a document has.

Best Answer

Related Solutions

Java – Mocking static methods

C# – Empty virtual method on base class VS abstract methods

Related Topic