Is it good to create an interface and then its implementation class, instead of just the class?

[Monica Shiralkar]

I have a class which does Analytics using Apache Storm. From the main method I am calling, an analyticsProcess() method which performs the entire analytics.Should I instead first create an interface which has this analyticsProcess method definition and then implement this analyticsProcess in implementation class? Which is a better programming practice?

thanks

[Fred Kleinschmidt]

What would be the purpose of creating an Interface? Why not just create an Analytics class that has an instance method to run the analysis? Something like:

public class Analytics {
   public Analytics() {
      // do whatever is needed to initialize the class
   }

   public void process() {
      // perform analytics here
   }
}

Then your main would contain:

   Analytics a = new Analytics();
   a.process();

[Monica Shiralkar]

Tomorrow if the implementation is in another technology apart from Strom e.g Spark, then it can implement this process method. Also it can be useful for unit testing. What is the reason that interface is inappropriate for this case?

thanks

[Jesper de Jong]

It depends.

It is not a good idea to blindly always write an interface + a class that implements the interface, just because someone says it is good practice to always do that. That leads to unnecessary extra code. Always make sure that there is a good reason for any design decision you make - and "just because it is good practice" is often not really a good reason.

But often it is a good idea, for example when you want to keep the API and its implementation separate, and you want code that uses the class only depend on the API (= the interface) and not any particular implementation of the API; or if you want to have different implementations of the API, as you mention yourself, for example one that does analytics using Storm and another one that does it using Spark, and you want to be able to easily switch between the two (without needing to change all the code that is using the API).

It can also help with automatic testing - when you write tests for a class that depends on other classes, if you split those other classes in an interface + class, then you can easily create a mock implementation of the interface to use for testing classes that depend on that interface. Testing tools like Mockito make it really easy to automatically generate mock implementations of interfaces.

[Junilu Lacar]

My rule of thumb is to provide interfaces at key integration points, like between business and persistence layers.  The main consideration is testability and in particular, your ability to unit test classes in one layer independently from classes that reside in a different layer. Within a layer, deciding to provide a layer of abstraction depends primarily on the stability of an implementation.  If I don't expect the implementation to change that often, then I would rather not add complexity by introducing an interface that's used only by other classes in the same layer.

[Monica Shiralkar]

I am now thinking whether creating an Abstract class and its implementation would be more appropriate in my case. There will be an Abstract class named Analytics such that it has one abstract method  named performAnalytics() and a concrete method named readConfig() which reads application configuration The class Spark analytics.java will implement the performAnalytics() method. Will it be a correct way if coding?   Thanks

[Carey Brown]

I'm getting the sense that for a given configuration you may want to instantiate one of several Analytics subclasses. If that is the case then you might want to consider a "factory" approach where the readConfig() is private and is called by the factory() method in order to return an new instance of one of the subclasses. Hypothetically:

public abstract class Analytics {

    private void readConfig( String configFileName ) { ... }

    public static Analytics factory( String configFileName ) {
        readConfig( configFileName );
        if( isSubclassA )
            return new SubclassA();
        if( isSubclassB )
            return new SubclassB();
    }
}

public class SubclassA
extends Analytics
{
...
}

[Monica Shiralkar]

Thanks. as of now I do not want different Analytics implementations but I am thinking of keeping it this way as a good programming practice for  future.

[Junilu Lacar]

Whether a practice is good or not is not absolute, it depends on the context. Always consider context. I seldom use the term "best practice" anymore since people, especially those with less experience, tend to then apply them without considering context and that can often lead to anti-patterns.

[Dave Tolls]

Monica Shiralkar wrote:Thanks. as of now I do not want different Analytics implementations but I am thinking of keeping it this way as a good programming practice for  future.

Re: the bit in italics.
In my case I would then just write the one class that does what you need it to do now.
Trying to future-proof your code at this stage is often not productive, so long as you bear in mind that you will likely need to refactor at some point...which is something that should always be borne in mind anyway.  And the main result of that should be avoiding monster methods, which are a lot harder to refactor.

[Junilu Lacar]

in a tweet, Sandi Metz wrote:Don't write code that guesses the future, arrange code so you can adapt to the future when it arrives.

https://twitter.com/sandimetz/status/441241600077725697

[Frits Walraven]

Congratulations Monica Shiralkar,

Your question has made it to our Journal   

Have a Cow!

[Randall Twede]

IMO interfaces and abstract classes are kind of a last resort. use them if that is what you truly need. usually you don't.

[Monica Shiralkar]

Thanks for the cow.