Explain interfaces?

[Royal Summers]

I'm reading about Interfaces -- I've read several articles and I'm still not clear.

Can someone explain it in simple terms?

This is the latest article that I read: https://www.javatpoint.com/interface-in-java

I'm lost in the very beginning of the article where it states:

"The interface in Java is a mechanism to achieve abstraction. There can be only abstract methods in the Java interface, not method body. It is used to achieve abstraction and multiple inheritance in Java."

I understand Loose Coupling but clear on Interfaces make this happen.

[Junilu Lacar]

It's an abstraction in the sense that a car's steering wheel is an abstraction of what happens under the hood to affect the direction the car is going. You just know that turning this round thing to the left makes the car go left and turning it to the right makes the car go to the right. Center it and the car goes straight.

Likewise, the methods defined in an interface only define what you can do, not how it is to be done. It's up to the implementing class to provide the "how"  or the implementation. The interface just deals with intent, like wanting to turn or just go straight.

[Junilu Lacar]

Note that in newer versions of Java, interfaces are allowed to define default implementations for the methods defined in them. This facilitates adding new methods to existing interfaces while maintaining backwards compatibility with older code.

[Royal Summers]

Junilu -

If I'm understanding, Abstraction in this context sort of means that Interfaces aren't 'tied' to specific code?  Meaning that it can be used by other Objects and/or Programs?

I just found this:

"Interfaces are classes that define method signatures and rely on classes to implement the code inside of them."

"Methods inside of an interface are inherently public. This means the public access modifier is not required."

So, Interfaces are just a 'type' of Class?

[Royal Summers]

Please disregard this question as I have located an answer that helps me get a better understanding.

"Interfaces allow for multiple inheritances, whereas classes do not."


https://secretofjavaexpert.gr8.com/Secret of Becoming a Java Expert

[Campbell Ritchie]

Royal Summers wrote:. . . "Interfaces allow for multiple inheritances, whereas classes do not." . . .

Lots of people say that sort of thing, but it's imprecise. It is possible for a class to implement multiple interfaces, but the classical (pre‑Java8) interface had only abstract methods, so its implementing classes inherited only constants and empty methods. Even nowadays you can only regard constants and public default methods as having inherited implementations.

[Royal Summers]

Campbell -

Thanks for your input.  Being that I'm new, I'm looking for a simplistic answer and the one I found was the one that was clear and easy for me to understand even if imprecise.

i'll take imprecise if I can understand it over precise but I don't understand it.

Hope this makes sense.

Again, thanks.  I will attempt to understand your response.

[Campbell Ritchie]

Royal Summers wrote:. . . i'll take imprecise if I can understand it over precise but I don't understand it . . .

Hahahahahahahahaha! Yes, that does make sense, as long as you remember it is imprecise.

. . . thanks. . . .

That's a pleasure

Have you seen our FAQ?

[Royale Summers]

Campbell -

So, I have been researching and have a better understanding in that an Interface might be analogous to the relationship of Class and Object where the Class defines the Object.  So, if I'm on the right track with my analogy then an Interface is similar to a blueprint, outline, or Object that seeds the Class?

In my previous post (understanding), I stated about multiple inheritance is allowed using Interfaces whereas multiple inheritance isn't allowed for Classes.

You responded with:

"...It is possible for a class to implement multiple interfaces, ..."   I don't think that we were on the same page or I might have misunderstood your response but either way I am beginning to understand this construct a lot better now.  If you have any resources that you can point me to, it would be greatly appreciated!

Have a great day!

[Junilu Lacar]

I would stay away from the idea of multiple inheritance for now as it just adds unnecessary cognitive weight to understanding what an interface is.

Think of it like this: an interface is a definition of a set of qualities or capabilities. For example, “washable” is a quality of many different things. A car is washable. A shirt is washable. A blanket is washable. A dish is washable. So is a sink. These things are not what you would normally consider to be in a hierarchy of things because they are very different from each other. However, they do have a common property of being washable. So the “interface” here would be Washable and the objects/classes that have that characteristic all bring their own “flavor” of being Washable.

If you look at the java.lang.Iterable interface (https://docs.oracle.com/javase/8/docs/api/java/lang/Iterable.html) you’ll see a long list of known implementing classes, many of which belong to different class hierarchies.

[Tim Holloway]

An Interface is a contract. When you define a class (or Interface) and it implements an interface, that's making a promise that the class or interface will implement all the methods defined in that interface. Failing to do so will cause a compiler error.

There is a certain resemblance between Abstract classes and Interfaces, but there are also key differences. A class may elect to define multiple Interfaces, even interfaces with overlapping method definitions. But a class can only be based on a single sub-class, whether that subclass is Abstract or concrete. And only concrete classes may be instantiated, so an Abstract class always is a subclass of at least one class if it is to be instantiated at all.

You cannot instantiate Interfaces, only classes that implement Interfaces.

[Royale Summers]

Junliu -

Thanks for considering my cognitive well-being.    I think I got it now.

"Think of it like this: an interface is a definition of a set of qualities or capabilities."  This also describes what can be placed in a Class to be used by an Object so I wasn't understanding the difference but the concepts of Abstraction and Loose Coupling helped me understand much better.  Basically, it's just an external file (object) that is shared and houses Behaviors that can be shared.  I think I finally got it but please feel free to correct me if I'm mistaken.  I've taken classes on C and C++ so the topic of Inheritance doesn't totally confound me.  

As always, I appreciate your time and input.

[Royale Summers]

Tim -

After much reading on my own, I actually understood much of what you stated although I will re-read a couple of more times.  The term "implements" was missing from my coding vocabulary and now that I understand that many thing are becoming clearer such as overlapping Methods().  

Thanks for your time and input as well.  I have been researching the differences between interfaces and abstract classes.

Here's the explanation from my Bootcamp:

"Interfaces are classes that define method signatures and rely on classes to implement the code inside of them. It may be tempting to allow classes to inherit (extend) from the parent class and use @Override to change every method. However, this approach has fundamental issues of repeating oneself and the consequence of forgetting to override a critical method. Classes cannot implement some of the methods in the interface class but instead must implement all of them. One benefit of using Eclipse is that it will prompt (via an error message) to define a method if it is missing."

With the input that you guys are providing, it's starting to become clearer and more comprehensible.

Again, thanks!

[Royale Summers]

Junilu -

I just finished looking that the link you provided.  I've tried understanding similar Oracle pages.  I'm not there yet but thanks for sharing.

[Tim Holloway]

I was one of the first to work with C++ after it was made available for commercial licensing. The C++ language supports multiple inheritance and the platform I was working on at the time (the Commodore Amiga OS) had things which lent themselves to using multiple inheritance. But multiple inheritance was a mess. As the Bootcamp implies, it leads to all sorts of problems when the same method is implemented differently in two different parent classes. That's why the creators of Java deliberately chose to omit multiple inheritance. And gave us Interfaces as a consolation.

[Junilu Lacar]

Royale Summers wrote:
Here's the explanation from my Bootcamp:

"Interfaces are classes that define method signatures and rely on classes to implement the code inside of them. It may be tempting to allow classes to inherit (extend) from the parent class and use @Override to change every method. However, this approach has fundamental issues of repeating oneself and the consequence of forgetting to override a critical method. Classes cannot implement some of the methods in the interface class but instead must implement all of them. One benefit of using Eclipse is that it will prompt (via an error message) to define a method if it is missing."

Not a very good explanation, in my opinion.

First, this is confusing "Interfaces are classes" -- they are not, in fact, classes. See what the Java Tutorials say: https://docs.oracle.com/javase/tutorial/java/IandI/createinterface.html

Second, "that define method signatures and rely on classes to implement the code inside of them" is both incomplete and ambiguous. What does "them" in "inside of them" refer to? The classes? The interface? The method signatures?

Third, this: "and the consequence of forgetting to override a critical method" -- with the introduction of default methods, it's also possible to not explicitly override all the methods of an interface. This is not a class vs. interface problem, in my opinion. It's a "I don't test my code thoroughly enough, thus I make dumb mistakes" kind of problem.

One of the primary considerations for using an interface versus extending an existing class is that with the interface, you are not tied to a particular class hierarchy and the design you are creating around the functionality defined by the interface does not make it necessary to be tied to a particular class hierarchy. The commonality of objects that share an interface is the general contract for behavior -- this is what gives you greater abstraction and looser coupling (more about intent and less about implementation)

[Royale Summers]

Junilu -

I'm going to have to agree with your assessment of the definition, hence, the reason I'm here to better understand.  I checked out the link you provided, thanks.  It states that an Interface is a Reference Type , and that it's 'similar' to a Class.  That took  me on a new journey of understanding.  So, I found this link attempting to explain Reference Types…reference types…https://www.geeksforgeeks.org/types-references-java/
Your observation of what it says about the Method signature confused me to; again, the reason I'm here.
Your third observation of the definition made sense but the content was maybe just trying to share how wonderful Eclipse is and that there's nothing to worry about.
Thanks for the summation as I have also been researching design patterns (i.e., Behavioral, Creational, and Structural).
I appreciate all your input in assisting in my learning because I wish to become one of the best and that starts with an accurate and complete understanding of the concepts.

Very interesting how trying to learn one thing leads to learning something else.  I love it!

P.S.

I was thinking about purchasing the following book and would love to read your thoughts:  https://www.amazon.com/Beginning-Java-Objects-Concepts-Second/dp/1590594576/ref=sr_1_1?keywords=%22java+objects%22&qid=1575481273&s=books&sr=1-1

[Junilu Lacar]

I haven’t read the book but looking through the table of contents, it seems it covers the topics I would expect to see covered by a book that claims to be “object” oriented. So many books about Java gloss over the Object-Oriented Programming parts that people really need to learn to write good Java programs. This one, however, looks like it does focus more on OOP concepts.

[Royale Summers]

Junilu -

Okay, thanks.  I want to get the 'theory' down pat to ensure success with my 'application.'

[paul nisset]

One way to think of an interface is what you want to do.
A separate class then implements that interface to do the actual work.
One advantage is this separates the business logic from the technical aspects of what you are doing.
It is a cleaner way of looking code and an application.

Suppose you want to handle a user login and return a message if it is successful or not.  
Initially, you don't know what you want to do but you know the steps.
So you create an interface to make sure you have your steps right.

public interface Login{
 public String login(String username ,String password);
 private boolean validateUser(String username ,String password);
 private String response(boolean isValid);

}

Now you are happy with the steps so you go about trying to get it to work so you create a class that  uses those steps.

public LoginImpl implements Login{

  public String login(String username ,String password){
         boolean isValid validateUser(userName,password);

             return response(isValid);

  }
  private boolean validateUser(String username ,String password){
              //do some stuff
              return true; // or false!!!
  }
  private String response(boolean isValid){
          if (isValid==true)
             return "Good to go!";
          else 
             return "try again." ;
  }
}

So, I don't know how I want to validate the user but I'm able to code the rest of it based on the interface.
I can now create tests against the interface and I'm not bogged down with the implementation.
The tests should work regardless of the implementation .

Hope this helps.
Paul

[Royale Summers]

Paul -

Thank you with the coding example.  I think that it's finally making sense.  I was just reading this link regarding Abstraction: https://www.tutorialspoint.com/java/java_abstraction.htm

Are you are able to 'dumb it down" for me as to why you would use an Interface vs Abstract Class?

Thanks in advance for any light that you can shine...

[paul nisset]

Think of an Abstract Class as a partial implementation.

You might want to validate logins differently in  different applications but you like the rest of your implementation of the Login class so make the Login class Abstract and extend it .

This way you don't have to rewrite the the whole class.

public class SchoolLogin extends Login {
  @Override
  private boolean validateUser(String username ,String password){
       //Do some stuff
  }
} 

public class WorkLogin extends Login {
  @Override
  private boolean validateUser(String username ,String password){ 
       //do some different stuff
  }
} 

By the way ,there were a couple typos in my original answer. I've fixed them.

[Royale Summers]

Paul -

Thank you, thank you.

You just rinsed my windshield and I can see nothing but a clear road ahead.

I had been trying to understand the Override and finally thanks to your example researched one more time -- can you say, "Polymorphism!"

You guys are making learning fun...I was scared (no, a bit terrified) when I decided to embark on learning Java.  I still have a ways to go but now but "confidence is high!"

Again, thanks to everyone in moving my understanding to the next-level.

[sohail hussain]

Tim Holloway wrote:An Interface is a contract. When you define a class (or Interface) and it implements an interface, that's making a promise that the class or interface will implement all the methods defined in that interface. Failing to do so will cause a compiler error.

There is a certain resemblance between Abstract classes and Interfaces, but there are also key differences. A class may elect to define multiple Interfaces, even interfaces with overlapping method definitions. But a class can only be based on a single sub-class, whether that subclass is Abstract or concrete. And only concrete classes may be instantiated, so an Abstract class always is a subclass of at least one class if it is to be instantiated at all.

You cannot instantiate Interfaces, only classes that implement Interfaces.

excellent explanation tim

[Junilu Lacar]

Tim Holloway wrote:And only concrete classes may be instantiated, so an Abstract class always is a subclass of at least one class if it is to be instantiated at all.

One nit to pick about that statement though: I think Tim meant to write either "so an Abstract class always is a superclass of at least one class..."  or "so an Abstract class always is subclassed/extended by at least one class..."

[sohail hussain]

Junilu Lacar wrote:

Tim Holloway wrote:And only concrete classes may be instantiated, so an Abstract class always is a subclass of at least one class if it is to be instantiated at all.

One nit to pick about that statement though: I think Tim meant to write either "so an Abstract class always is a superclass of at least one class..."  or "so an Abstract class always is subclassed/extended by at least one class..."

yes that's cool, but abstract class can be subclass to interface also

[Junilu Lacar]

sohail hussain wrote:yes that's cool, but abstract class can be subclass to interface also

Oh, really? Can you cite any official documentation that says so? As far as I know, a subclass always extends its superclass. A class can't extend an interface, it can only implement it.

Also, the context for Tim's statement was "if it is to be instantiated at all" meaning if you are to instantiate an Abstract class at all, it has to be through a concrete subclass of that Abstract class. That is, the Abstract class is the superclass of the concrete class you're instantiating. I don't see how your additional comment is relevant to that.

[sohail hussain]

Junilu Lacar wrote:

sohail hussain wrote:yes that's cool, but abstract class can be subclass to interface also

Oh, really? Can you cite any official documentation that says so? As far as I know, a subclass always extends its superclass. A class can't extend an interface, it can only implement it.

Also, the context for Tim's statement was "if it is to be instantiated at all" meaning if you are to instantiate an Abstract class at all, it has to be through a concrete subclass of that Abstract class. That is, the Abstract class is the superclass of the concrete class you're instantiating. I don't see how your additional comment is relevant to that.

I have this in my assignment ,if abstract class implements interface is it not enough to say that abstract class is subclass to interface or if any class may be abstract or concrete class implements is it not subclass. any suggestion,  
interface IA
{
int doit();
}
interface IB
{
int doit();
}
abstract class combined implements IA, IB
{
}

[Campbell Ritchie]

It is a subtype of that interface.

[Junilu Lacar]

sohail hussain wrote:if abstract class implements interface is it not enough to say that abstract class is subclass to interface or if any class may be abstract or concrete class implements is it not subclass

It is incorrect to say an abstract class as a subclass of an interface it implements. As Campbell pointed out, the correct word to use is subtype. There's a big difference.