Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

why need Interface if you can inherit directly from a class?  RSS feed

 
thomas chan
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
lets say in package A we have the class "word" that implements the interface "Iword"; both of them are in package A, and then in package B we can have the class "dictionary" that would like to access the implementations of the class "word". But, we don't want the class "dictionary" to directly accessing the implementations of "word", so "dictionary" can call the interface "Iword" to communicate with "word" instead. Using an interface seems to be one way of hiding the implementations of a class from users, right?

Well, but what if someone decided that he ain't going to use the interface and inherits/extends the class "word" directly in "dictionary"?? What can really stop him doing that?

I tried to declare the methods as protected in the class "word", but Netbeans complaned.
 
Sonny Gill
Ranch Hand
Posts: 1211
IntelliJ IDE Mac
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by thomas chan:


Well, but what if someone decided that he ain't going to use the interface and inherits/extends the class "word" directly in "dictionary"?? What can really stop him doing that?



Nothing stops him.

You use interfaces because it makes easier to make changes in future, extend a system or divide up work between multiple teams, and so on..
It is a good practice, and you will realize its benefit when you have to work through a large complex project with ever-changing requirements.

HTH

P.S. On the other hand you can force it a little bit, by not making the class public, and instead provide a public WordFactory class in the same package that provides a method that instantiates the a Word object and returns an instance with type IWord. You may want to read up a bit on design patterns for this one.
 
Dirk Schreckmann
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to JavaRanch, thomas chan!

lets say in package A we have the class "word" that implements the interface "Iword"; both of them are in package A, and then in package B we can have the class "dictionary" that would like to access the implementations of the class "word". But, we don't want the class "dictionary" to directly accessing the implementations of "word", so "dictionary" can call the interface "Iword" to communicate with "word" instead. Using an interface seems to be one way of hiding the implementations of a class from users, right?

Well, but what if someone decided that he ain't going to use the interface and inherits/extends the class "word" directly in "dictionary"?? What can really stop him doing that?


The author of class "word" need simply declare the class without an access modifier, so that it has default (package only) accessibility. Then, something outside the package cannot access it directly.

I tried to declare the methods as protected in the class "word", but Netbeans complaned.

I'm not certain I understand what you're saying. Did you try to declare methods from the interface as protected in the implementing class? That's not allowed, since you cannot override a method to have more restricted access. Note that any method declared in an interface is public, implicitly so if the author didn't explicitly declare it.

why need Interface if you can inherit directly from a class?

Java allows for only single inheritance - class A can extend only one other class, not two or more. Some relationships among types of objects are a bit more complex than would be possible to implement with single inheritance without another mechanism, such as interface implementation.

Consider the following contrived example to illustrate this point. Let classes Tree and Worm extend class LifeForm. Let classes Paper and Marble extend class Material. Now, consider that we want to implement some mechanism for grouping things that can burn. With interfaces, it's pretty easy. Just let classes Tree and Paper implement interface Burnable. We can then create a collection of Tree and Paper objects, referring to them simply as Burnable objects, and we can do things with them that Burnable objects can do (things like burn). Is that clear?

For me, I started to appreciate interfaces (and polymorphism) much more when I started creating programs with more than just a few classes and a thousand lines of code. So, if you're not quite in tune with this whole interface mechanism, perhaps you'll start to "get it" more, as you write more and bigger programs.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!