This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Java in General and the fly likes Best suitable for the below scenaio : Interface/Abstract class Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Best suitable for the below scenaio : Interface/Abstract class" Watch "Best suitable for the below scenaio : Interface/Abstract class" New topic
Author

Best suitable for the below scenaio : Interface/Abstract class

Pavan Kumar Dittakavi
Ranch Hand

Joined: Feb 12, 2011
Posts: 104

Hi Experts,

Firstly, I'm aware of the posts that are made in conjunction with this topic but I however, have a slight different variant of the classic question regarding interfaces and Abstraction. Assume that there is this task of designing an Editor and there could either be a text editor and some other binary editor. How can someone design this?

Question 1:Is it just that we can create a base class [ abstract ] Editor and then subclass them so as to produce TextEditor and BinaryEditor? Or should interfaces come into picture where in the interface IEditor comes into picture which lays out what all the methods that a concrete class needs to have? Which one should one chose and Why?

I tend to think about the first approach of going with the abstract classes[ Ultimately, both the editors have an IS-A relationship with the editor, but is this reasoning alone correct]. Question 2:But if that is the case, what case could provoke someone to have an interface? Question 3: Finally, if interface is just to enforce concrete classes to have specified interaces[methods] defined in them, can't the same be accomplished by an [ abstract method ] abstract class ?

Thanks,
Pavan.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Q1) Assuming all Editors expose the same public methods, I would definitely start with an interface. Note, however, that interface/abstract class is not an either-or proposition. It's quite common to use both. They serve two different but complementary roles. Also, note that extending an interface, extending a class, and implementing and interface are all IS-A relationships.

Q2&Q3) Yes, you can accomplish the same contract enforcement with a purely abstract class that you can with an interface. Note, however, that the primary job of an interface is to provide a definition of the public view of a purely abstract type, while the primary job of an abstract class is to provide partial implementation of an abstract type. The language designer chose (wisely, IMHO) to make those two distinct concepts at the language level. They wouldn't have had to, but I think it makes the language easier to understand, and I expect it makes writing compilers and JVMs easier as well. Also, with just abstract classes, you cannot declare yourself to be of multiple types. That is, Java supports multiple inheritance of interface, but not of implementation. (Another wise decision.)


Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38020
    
  22
Why not start by researching the dictum “Favour composition over inheritance”?
Pavan Kumar Dittakavi
Ranch Hand

Joined: Feb 12, 2011
Posts: 104

Thanks Jeff and Ritchie. BTW, I came across this question while having a coffee. Im currently checking the 'Effective Java' book by Joshua Blosch. It's a real classic to me. And I would stumble upon the Composition VS Inheritance soon. I shall post my views once I reach there.

Thanks,
Pavan.
Mohamed Sanaulla
Saloon Keeper

Joined: Sep 08, 2007
Posts: 3068
    
  33

Designing the correct class hierarchy is not always a trivial issue. You might want to think a bit ahead in future about the application and make decisions (though avoid over designing the code). Adding to what Jeff said, when you use an Abstract class you end up with being unable to extend any other class and you hit the limitation of extending one class, but whereas when you use an Interface you still keep the option of extending one more class- I am not sure if this would make more sense but good to keep this in mind.

You might tend to prefer inheritance because it easier to implement and make your code look right. But when you continuously proceed adding layers of hierarchy you end up with a tightly coupled code and may also be less cohesive. I cant foresee such an issue in the example you have stated.

Another advantage of using Interfaces are that you can keep your implementations independent of the consumers of the interface and also encapsulate the type related information from the consumer of your API which means suppose there is an Interface Iface and its two implementations- IOneImpl and ITwoImpl, so being the consumer of the API offered by Iface, I would not really worry if I am using an instance of IOneImpl or ITwoImpl as long as the functionality is intact. Once the consumer gets an idea of the type then there might be a possible instanceof check/casting to get the required functionality but it only makes things worser as your code becomes more coupled.


Mohamed Sanaulla | My Blog
Saurabh Pillai
Ranch Hand

Joined: Sep 12, 2008
Posts: 506
Jeff Verdegan wrote:Q1) Assuming all Editors expose the same public methods, I would definitely start with an interface. Note, however, that interface/abstract class is not an either-or proposition. It's quite common to use both. They serve two different but complementary roles. Also, note that extending an interface, extending a class, and implementing and interface are all IS-A relationships.


IMO,Abstract class makes better choice. Because, open,read,save etc are common functions to any editor. so they should go to abstract class so that child classes do not need to implement them separately. and particular editor specific functions can be included in relevant child class.

view/opinion?
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Saurabh Pillai wrote:
Jeff Verdegan wrote:Q1) Assuming all Editors expose the same public methods, I would definitely start with an interface. Note, however, that interface/abstract class is not an either-or proposition. It's quite common to use both. They serve two different but complementary roles. Also, note that extending an interface, extending a class, and implementing and interface are all IS-A relationships.


IMO,Abstract class makes better choice. Because, open,read,save etc are common functions to any editor. so they should go to abstract class so that child classes do not need to implement them separately.


You're making a very common mistake. You're thinking that inheritance is about code sharing. It's not. It's primarily about type implementation and specialization, though code sharing is a nice side benefit. Even without inheriting an implementation, one can still use that code. Google for prefer composition over inheritance.

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Best suitable for the below scenaio : Interface/Abstract class
 
Similar Threads
Why abstract classes? why not extend base class and override those methods in subclas
Difference between Interfaces and abstract classes
Difference between abstract class and interface
why to go for interface
Abstract Classes Vs Interfaces