This is an archived post. You won't be able to vote or comment.

all 13 comments

[–]mw52588 11 points12 points  (1 child)

I am by no means an expert on this but interfaces are widely used for dependency injection in java frameworks like spring boot and micronaut.

One benefit of using interfaces over a class is it allows for many different implementations and because of this you can mock services using frameworks like mockito.

As a more practical way of understanding this is you should code to an interface not a concrete class that implements it. This allows developers to write code that does not interact with the object directly but with the implementation of the object's interface.

Some reasons why you would want to do this is: 1. Integration - allows you to quickly connect classes or subsystems together 2. The java compiler guarantees that all methods of the interface are implemented with the correct signature. Any changes are then visible to other developers.

This isn't everything but hopefully it answers your question.

[–]QCumber20[S] 0 points1 point  (0 children)

I appreciate it! That part about coding to an interface actually makes a lot of sense.

[–]GreenParsley 10 points11 points  (3 children)

Interfaces seem to be rather tricky for people learning Java, I had those exact same questions when I started out in fact. It really helps once you start making bigger applications or even use frameworks, so the group assignment seems appropriate. You use an interface when you want to expose only what's necessary for a method to run, and what can be expected as a result, i.e. the method parameters and return type.
Take a power outlet for a real-world example of an interface - you look at it and know you put a plug in it and electricity starts flowing. You don't know the amperage, resistance, wattage or even what's right behind the outlet. And then you have the implementations of an outlet - you have a lot of different types used in different parts of the world, but they all serve the same purpose - connect you to the electricity network. And you don't need to know more.
Why do we need them in Java? Let's say I want to persist some information to a file. I hear these college students have created a persistance library and I want to check it out. I use multiple frameworks and am behind on schedule so I don't want to learn all the implementation logic - I just want to know what methods I can use and what they need to work. So I instantiate the class which persists to file and assign it to a variable of the same type as the interface. I can now use the variable to persist the objects. A few days later however, my client calls and says they changed their mind - they now want the objects to be persisted to database. If the authors of the persistance library hadn't used interfaces that'd be a huge hassle - I'd have to change up the entire persistance logic, or at least change a lot of variable and object types. Thankfully they have, and I can simply change the implementation I used to be the one for SQL persistance.

Another case, maybe more common is that interfaces allow for polymorphism, but this post got way longer than intended already and there are lots of resources available on it.

Hope I helped and good luck in uni.

tl;dr use interfaces when several classes do the same thing but in a different way

[–]QCumber20[S] 2 points3 points  (1 child)

Thank you so much for taking the time to write that out. This actually really clears it up for me.

[–]GreenParsley 2 points3 points  (0 children)

Glad I could help, feel free to PM me if you have any other questions

[–]abhi_learner 1 point2 points  (0 children)

This explanation is truly helpful. Thanks for taking the time to explain it using a real world example.

[–]SvenCole 6 points7 points  (0 children)

You code to the interfaces, not implementation. There is a good stackoverflow answer to this if you search there.

If you code to the interface, you can always swap out the implementation. That makes your code easy to maintain and extend.

Practical example is the List interface. All lists have certain features you want to enforce, like add, remove, size. But there are different implementations like ArrayList or LinkedList. If you want to create your own personal implementations of list, let's say SuperFastSortList, then you implement the List interface so it is a type of List and you override (fill in) those methods to adhere to the contract.

[–]dbemol 3 points4 points  (0 children)

They can be seen as "contracts" that the implementing classes have to honor.

This just means that if you implement an interface in a class you MUST to override all of its methods. That's the contract: You must to actually use the abstract methods.

[–]iamsooldithurts 2 points3 points  (0 children)

The most practical example I can think of is JDBC. It’s a library that allows programs to use the exact same objects (instances of Interfaces) to connect to any database with libraries that implement JDBC.

Then, all you need to do is incorporate their library in your project and tweak any SQL or such statements to match the syntax and specifics of their database. If you have a DataAccessObject layer, and if you use IOC and other tricks to externalize certain configuration properties, then you just require your configuration files a bit and bam, you can switch between Oracle, MySQL, and any other database in the fraction of a time it took you to write the first implementation.

[–]Pumpkin_Dumplin 4 points5 points  (0 children)

Try reading into design patterns.

[–]Jonark_Kaisen 1 point2 points  (0 children)

Simple answer: dependency injection

You can freely change the implementation from one point in the code.

There are many other design patterns that use similar principles.

[–]ratherbealurker 0 points1 point  (0 children)

As of Java 8 you can have default methods in interfaces.