Best suitable for the below scenaio : Interface/Abstract class

[Pavan Kumar Dittakavi]

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]

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]

Why not start by researching the dictum “Favour composition over inheritance”?

[Pavan Kumar Dittakavi]

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]

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.

[Saurabh Pillai]

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]

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.