I know that an interface does not have a body just a method definition. But when should I use interfaces? If I provide someone a set of interfaces with no body, why would they feel a need to write the function body? Would they be better off writing their own abstract class with abstract methods in it.
I guess the use of Interfaces is more when you are a part of a team. Suppose Team A writes a code for something and they wanted to see if a call to a method. with name getRecords(), is done or not. This will help Team B to write the body of the interface provided to them and Team B has to keep the method name similar so that code of Team A runs.
Just a thought. I might be wrong. I think Interfaces have no use for a single developer.
Thanks all for the answers. With what you all have replied, I think Interfaces have more use when you are making something like API?
An interface can be used to define a contract behavior and it can also act as a contract between two systems to interact while an abstract class is mainly used to define default behavior for subclasses, it means that all child classes should have performed the same functionality.
Why do we use an Interface? It is used to achieve total abstraction. Since java does not support multiple inheritances in the case of class, by using an interface it can achieve multiple inheritances. It is also used to achieve loose coupling.
No, every class should not have an interface. It's overkill squared. You use an interface when you need to abstract what's done from how it's done, and you're certain that the implementation can change.
In Java, an interface specifies the behavior of a class by providing an abstract type. As one of Java's core concepts, abstraction, polymorphism, and multiple inheritance are supported through this technology. Interfaces are used in Java to achieve abstraction.
In languages such as Java and C# interfaces provide a means for a class to be have in a polymorphic manner. That is to say a class can satisfy more than one contract - it can behave as multiple different types, a class of one type can be substituted for another. In other languages this can also be provided by multiple inheritance, but there are various disadvantages to this approach. However, having a class behave as more than one type is not the most common motivation for using interfaces.
By programming to interfaces instead of classes you can also decouple your program from specific implementations. This makes it much easier to substitute one class implementation for another. This is particularly useful when writing unit tests where you may wish to swap some heavyweight class implementation with a lightweight mock object. If your program only expects an interface type, and both the heavyweight object and mock object implement said interface, then they are very easy to substitute.
Also, consider a simple Java example where I say have a program that displays pages of data on the screen. Initially I want it to get the data from a database or XML files. If I write my program so that it uses interfaces I can define an interface like so:
public interface PageDatasource { public List<Page> getPages(); }
And use it like so:
PageDatasource datasource = // insert concrete PageDatasource implementation here List<Pages> pages = datasource.getPages(); display(pages);
I can then write separate database and XML implementations that adhere to this interface:
public class DatabasePageDatasource implements PageDatasource { public List<Page> getPages() { // Database specific code } } public class XmlPageDatasource implements PageDatasource { public List<Page> getPages() { // XML specific code } }
Because I used an interface I can now use either implementation - Database or XML - interchangeably without having to change the parts of my program that ask for the page data. The XML and Database implementations likely do completely different things but all my program cares about is that the object supplying the page data implements the PageDatasource
interface.
Interface Real Life analogy:
Let say you want to Issue a Book from Library. What you will do:
1) Go to Library
2) Find the Book which interests you
3) Select the Book
4) Go to Librarian Desk to request them to Issue the Book.
Now here Librarian is an Interface, which means you are not interested in who the hell is Librarian, you are only interested in that person sitting on Librarian desk(is the person who agreed to a contract to act as Librarian, which means that person agreed to implement all the behaviors of Librarian)
So let say: Behavior of Librarian are:
1) Issue book
2) Re-Issue Book
3) Return Book.
the person who is designated as Librarian (which means agreed to adapt the above three behaviors), must implement the behaviors in his own way.
Let say PersonA wants to play a part of Librarian, then he needs to adapt the above 3 Behaviors. We as Client don't care how he is performing his Librarian behaviors, we are only interested in that personA is Librarian and he abides to perform the Librarian tasks.
Therefore what you will do, is Reference by Interface[go to Librarian Desk(which will leads you to persons acting as Librarian)] and let say in Future one person left the Librarian post, then as client it won't affect you if you have approached the Librarian desk, instead of specific person acting as Librarian.So code to Interface instead of Concreteness is beneficial.
class PersonA implements Librarian { public void IssueBook(){...} public void ReIssueBook(){...} public void ReturnBook(){...} //Other person related tasks... }
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With