Java Interface - constants and static class in normal interface

Question

Consider following interface.

public interface ThirdPartyApiHandler {

    public OperationResult doOperation(OperationInput input);

    public static class OperationResult {
         //members of OpeationResult. metrics after file processing
         private int successfulRecords;
         private int failedRecords;
    }  

    public static class OperationInput {
         //implementations call third party API to process this file.
         private String inputBatchFile; 
    }  

    //Constant which would be same across all implementations.
    public static final int GLOBAL_CONSTANT = 1;
}

Is above interface a bad design?

1. OperationResult and OperationInput are defined as static class. They would be only used by implementations and not anywhere else. Advantage that I see here is - I don't have to create separate files for these two classes. Also they get namespace of parent class.

2. I have read about constant interface. But in this case, I am defining constant in normal interface which are bound to be same across all implementations and would be used in those implementations.

I am using this pattern for first time so wanted to get suggestions.

Answer 1

OperationResult and OperationInput are defined as static inner class. They won't be used anywhere else.

That's OK since they will not be used anywhere else. If they're long than I would prefer to have them in separate classes.

I have read about constant interface. But in this case, I am defining constant in normal interface which are bound to be same across all implementations and would be used in those implementations.

That's a good place to declare such a field.

Answer 2

Having nested classes in interfaces is only matter of additional namespace. This approach help to organize the code when small interfaces are created to support simple data structure.

I recommend you this lecture: Java Tip 75: Use nested classes for better organization.

Note that public and static are redundant in this case so you do not need them. What you need to remember is that having such classes do not limit other developers to use them in other parts of code.

From my point of view, this is a good design but, i would extend and replace the class with interfaces.

public interface ThirdPartyApiHandler {

    OperationResult doOperation(OperationInput input);

    interface OperationResult {
         int getSuccessfulRecords();
         int getFailedRecords();
    }  

    interface OperationInput {
         String getInputBatchFile(); 
    }  

    final int GLOBAL_CONSTANT = 1; //This could be replaced by enum but no need 
}

Answer 3

Is above interface a bad design?

That would depend on your implementation design and it's usability in your project. Logic looks all legal to me. Possible use case of such a design can be as follows

public interface A {
    static class B {
        public static boolean verifyState( A a ) {
            return (true if object implementing class A looks to be in a valid state)
        }
    }
}

Also

public static class OperationResult {
     //members of OpeationResult. metrics after file processing
     private int successfulRecords;
     private int failedRecords;
} 

In above class you have instance variables successfulRecords and failedRecords . why not make the instance variable of these static classes also static so that you can access them using ThirdPartyApiHandler.OperationResult.successfulRecords. You can even have static getters and setters for your variables.

---

OperationResult and OperationInput are defined as static inner class.

Contrarily to popular belief there's no such thing as an "static inner class": this simply makes no sense, there's nothing "inner" and no "outter" class when a nested class is static, so it cannot be "static inner".

Picked up above from this SO question. Read the 1st answer. I think that will answer all your questions.

Answer 4

Is above interface a bad design?

Quite simply, yes.

Putting any logic in an interface is semantically incorrect. An interface exposes functionality to consumers - that is its single purpose, and that should not be diluted.

Consider implementing any common functionality in a base implementation class and use inheritance, or in one or more services and use composition, in your different interface implementations.

EDIT - quote from Joshua Bloch's Effective Java

When a class implements an interface, the interface serves as a type that can be used to refer to instances of the class. That a class implements an interface should therefore say something about what a client can do with instances of the class. It is inappropriate to define an interface for any other purpose.