• Post Reply Bookmark Topic Watch Topic
  • New Topic

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

 
Monica Shiralkar
Ranch Hand
Posts: 914
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 555
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:

Then your main would contain:
 
Monica Shiralkar
Ranch Hand
Posts: 914
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Java Cowboy
Sheriff
Posts: 16007
87
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 10949
158
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 914
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 2846
43
Eclipse IDE Firefox Browser Java MySQL Database VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:
 
Monica Shiralkar
Ranch Hand
Posts: 914
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 10949
158
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 2835
30
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 10949
158
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Creator of Enthuware JWS+ V6
Saloon Keeper
Posts: 2966
210
Android Chrome Eclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Congratulations Monica Shiralkar,

Your question has made it to our Journal   

Have a Cow!
 
Randall Twede
Ranch Hand
Posts: 4683
8
Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
IMO interfaces and abstract classes are kind of a last resort. use them if that is what you truly need. usually you don't.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!