Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I've been trying to learn Java and trying to really understand it and how it works. I was able to understood what an interface was (or so I think). I've also seen some examples with them... BUT I haven't been able to understand how some interfaces have methods that you implement, and they already come with some kind of functionality... aren't you supposed to write that functionality every time you implement that method?
To give some kind of example, there's LibGDX, a very well-known library for game developing in Java. Your application class has to implement a interface that has methods like "render()". When you write your application you put all the stuff related to rendering in the "render()" method... but how does it knows what to do with that, if it's just an interface which only defines the name and return type of render()?
Sorry for my english, and thank you.
EDIT: Thanks for your answers, yes I am kind of new in this... so well I get confused, you've been really helpful!.
Interfaces
Think of an interface as a collection of abstract methods. So this special class may be implemented inside my other classes. So that it inherits it's methods.
Think of it as a child class signing a contract with this parent class and promising that it will follow the same behavior as the interface. OTHERWISE, it'll have to declare itself as an abstract class(That's a whole other question to tackle).
In Java we are not allowed to extend multiple classes(as opposed to C#) in order to keep things simple. We are however, allowed to implement as many interfaces as we need.
To give you an example, what do Apples, Oranges, Blueberries have in common? They are all fruit, thus to 'force' them to have the same characteristics I create a Fruit interface, like so:
interface Fruit {
public void name();
public void colour();
}
And then implement them in my Apple class:
public class Apple implements Fruit{
public void name(){
System.out.println("Apple");
}
public void colour(){
System.out.println("Red");
}
}
So that Apple.java is forced to use the name() and colour() method and thus we will never come across an Apple object which doesn't have both name and colour!
Hope to have cleared it up
Also, I do recommend checking - Tutorials Point
As they post rather clear tutorials. For future reference, I highly recommend you search on StackOverflow for answers prior to posting your question as it will lead to alot of negative votes!
Interfaces can definitely be challenging concept to understand. Sometimes you need to know in advance that some method will exist on a given type. LIke in your case the LibGDX has a render method. The LibGDX at some point needs to call a render method but LibGDX doesn't know how that method is implemented, it just knows that it needs to call render. So, they say please implement this interface and tell us how to render. Then when we get around to calling the render() we will make sure that it gets called at the right time and invokes your code.
Perhaps this could be said another way. Sometimes when you use other software they do lots of work for you. At some point though you have to find a way to hook into the service that they provide. By implementing that interface you provide an implementation for the render() and they are nice enough to call it for you at the right time so that the rendering can take place.
Interfaces allow for polymorphism. Essentially, the LibGDX can call the render() on anything that implements their interface. Because you have implemented their interface their code know knows that a render() must exist on the class. The reason that this is polymorphic is because many different codebases will implement the interface and provide their own custom implementation of render and again LibGDX will happily invoke their method and run their implementation of that method.
Hope that helps!
Using your example, when your class implements an interface, the framework knows an instance of your class has a render() method, so the framework can call it when it needs to.
The framework doesn't need to know (or care) what class the instance is, and especially what super classes it may be inherited from. Nor does it care what the method does.
Further, referring to objects in the most abstract way is best practice, and in java an interface is the most abstract type (because it puts no restriction on class hierarchy) - see
Liskov substitution principle for more on this concept.
This arrangement gives great flexibility to how you may implement your code.
It doesn't. An interface is simply a contract. To Java, this means that if a concrete Object exists which implements that interface, it will have implementations of the methods defined in the contract.
A simple example should help demonstrate:
ExampleInterface.java
public interface ExampleInterface {
int operation(int a, int b);
}
ExampleAddition.java - implements the interface using addition as the operation.
public class ExampleAddition implements ExampleInterface {
#Override
public int operation(int a, int b) {
return a+b;
}
}
ExampleSubtraction.java - implements the interface using subtraction as the operation.
public class ExampleSubtraction implements ExampleInterface {
#Override
public int operation(int a, int b) {
return a-b;
}
}
ExampleMain.java - Contains anonymous inner class which uses multiplication as the operation.
public class ExampleMain {
public static void main(String[] args) {
ExampleInterface first = new ExampleAddition();
ExampleInterface second = new ExampleSubtraction();
ExampleInterface third = new ExampleInterface() {
#Override
public int operation(int a, int b) {
return a*b;
}
};
System.out.println(first.operation(10,5));
System.out.println(second.operation(10,5));
System.out.println(third.operation(10,5));
}
}
So what's the point of all this? Well the point is that all interface implementations are interchangeable, and you can use whichever you fancy. Now clearly in this example it's not particularly useful. It's more useful if you have for instance a data access object, and you want to use different technologies to access your data layer. You might want to have a hibernate implementation in production, and plain old JDBC implementation for local development, and a Mockito version for testing. This can all be done, because they share a common interface, they are effectively drop-in replacements for each other. In libGDX however I suspect there will only ever be one implementation, but it still must comply to the same contract. This let's them write a game loop that works independently of your concrete implementation.
Related
Interfaces are great from a flexibility standpoint. But in case, where an interface is used by a large number of clients. Adding new methods to the interface while keeping the old mehtods intact will break all clients' code as new methods won't be present in clients. As shown below:
public interface CustomInterface {
public void method1();
}
public class CustomImplementation implements CustomInterface {
#Override
public void method1() {
System.out.println("This is method1");
}
}
If at some point later in time, we add another method to this interface all clients' code will break.
public interface CustomInterface {
public void method1();
public void method2();
}
To avoid this we have to explicitly implement new methods in all clients' code.
So I think of interfaces and this scenario as following:
Interfaces once written are like carving in stone. They are rarely supposed, and expected to change. And if they do, they come with a huge cost(rewriting the whole code) which programmers should be ready for.
In continuation with the point above, Is it possible to write interfaces that can stand the test of time?
How such a scenario is handled in interfaces where you expect additional functionality in future? That is anticipating change in the contract by which all clients are binded.
EDIT: Default method is indeed a nice addition to Java Interfaces which a lot of people have mentioned in their answers. But my question was more in the context of code design. And how forcing method implementation on the client is an intrinsic character of an interface. But this contract between an interface and a client seems fragile as functionality will eventually evolve.
One solution to this problem was introduced in Java 8 in the form of default methods in interfaces. It allowed to add new methods to existing Java SE interfaces without breaking existing code, since it supplied default implementation to all the new methods.
For example, the Iterable interface, which is widely used (it's a super interface of the Collection interface) was added two new default methods - default void forEach(Consumer<? super T> action) and default Spliterator<T> spliterator().
public interface CustomInterface {
public void method1();
}
public interface CustomInterface2 extends CustomInterface {
public void meathod2();
}
Other than default method you can use inheritance property as show above by which new interface will have all previous method along with new methods and use this interface in your required situation.
Java 8 has introduced default implementation for methods. These implementations reside in the interface. If a new method with a default implementation is created in an interface that is already implemented by many classes, there is no need to modify all the classes, but only the ones that we want to have a different implementation for the newly defined method than the default one.
Now, what about older Java versions? Here we can have another interface that extends the first one. After that, classes that we want to implement the newly-declared method will be changed to implement the new interface. As shown below.
public interface IFirst {
void method1();
}
public class ClassOne implements IFirst() {
public void method1();
}
public class ClassTwo implements IFirst() {
public void method1();
}
Now, we want method2() declared, but it should only be implemented by ClassOne.
public interface ISecond extends iFirst {
void method2();
}
public class ClassOne implements ISecond() {
public void method1();
public void method2();
}
public class ClassTwo implements IFirst() {
public void method1();
}
This approach will be ok in most cases, but it does have downsides as well. For example, we want method3() (and only that one) for ClassTwo. We will need a new interface IThird. If later we will want to add method4() that should be implemented by both ClassOne and ClassTwo, we will need to modify (but not ClassThree that also implemented IFirst) we will need to change both ISecond and IThird.
There rarely is a "magic bullet" when it comes to programming. In the case of interfaces, it is best if they don't change. This isn't always the case in real-life situations. That is why it is advised that interfaces offer just "the contract" (must-have functionality) and when possible use abstract classes.
A future interface change shouldn't break anything that has been working -- if it does, it's a different interface. (It may deprecate things, though, and a full cycle after deprecation it may be acceptable to say that throwing an Unimplemented exception is acceptable.)
To add things to an interface, the cleanest answer is to derive a new interface from it. That will allow using objects implementing the new behaviors with code expecting the old ones, while letting the user declare appropriately and/or typecast to get access to the new features. It's a bit annoying since it may require instanceof tests, but it's the most robust approach, and it's the one you'll see in many industry standards.
Interfaces are contracts between the developer and clients, so you're right - they are carved in stone and should not be changed. Therefore, an interface should expose (= demand) only the basic functionality that's absolutely required from a class.
Take the List interface for example. There are many implementations of lists in Java, many of which evolve over time (better under-the-hood algorithms, improved memory storage), but the basic "concept" of a list - add an item, search for an item, remove an item - should not and will not ever change.
So, to your question: Instead of writing interfaces which classes implement, you can use abstract classes. Interfaces are basically purely-abstract classes, in the sense that they do not provide any built-in functionality. However, one can add new, non-abstract methods to an abstract class that clients will not be required to implement (override).
Take this abstract class (= interface) for example:
abstract class BaseQueue {
abstract public Object pop();
abstract public void push(Object o);
abstract public int length();
public void clearEven() {};
}
public class MyQueue extends BaseQueue {
#Override
public Object pop() { ... }
...
}
Just like in interfaces, every class that extends BaseQueue is contractually bound to implement the abstract methods. The clearEven() method, however, is not an abstract method (and already comes with an empty implementation), so the client is not forced to implement it, or even use it.
That means that you can leverage the power of abstract classes in Java in order to create non-contractually-binding methods. You can add other methods to the base class in the future as much as you like, provided that they are not abstract methods.
I think your question is more about design and techniques, so java8 answers are a bit misleading. This problem was known long before java8, so there are some other solutions for it.
First, there are no absolutely chargeless ways to solve a problem. The size of inconviniences that come from interface evolving depends on how the library is used and how deliberate your design is.
1) No techniques will help, if you designed an interface and forgot to include a mandatory method in it. Plan your design better and try to anticipate how clients will use your interfaces.
Example: Imagine Machine interface that has turnOn() method but misses turnOff() method. Introducing a new method with default empty implementation in java8 will prevent compilation errors but will not really help, because calling a method will have no effect. Providing working implementation is sometimes impossible because interface has no fields and state.
2) Different implementations usually have things in common. Don't be afraid to keep common logic in parent class. Inherit your library classes from this parent class. This will enforce library clients to inherit their own implementations from your parent class as well. Now you can make small changes to the interface without breaking everything.
Example: You decided to include isTurnedOn() method to your interface. With a basic class, you can write a default method implementation that would make sence. Classes that were not inherited from parent class still need to provide their own method implementations, but since method is not mandatory, it will be easy for them.
3) Upgrading the functionality is usually achieved by extending the interfaces. There's no reason to force library clients to implement a bunch of new methods because they may not need them.
Example: You decided to add stayIdle() method to your interface. It makes sence for classes in your library, but not for custom client classes. Since this functionality is new, it's better to create a new interface that will extend Machine and use it when it's needed.
This question already has answers here:
Interfaces in Java - what are they for? [duplicate]
(9 answers)
Closed 9 years ago.
Let's say you have an interface
public interface Change {
void updateUser();
void deleteUser();
void helpUser();
}
I've read that interfaces are Java's way to implement multiple inheritance. You implement an interface, then you have access to its methods. What I don't understand is, the methods don't have any body in the interface, so you need to give them a body in your class. So if you an interface is implemented by more than one class, you need to give the method a body in more than one class. Why is this better than just having individual methods in your classes, and not implementing an interface?
My professor in college once gave a great anecdote to describe polymorphism and encapsulation. It went like this.
Does anyone here know how a soda machine works? (Cue confused glances about why we'd even talk about this.) No? Let me tell you.
You drop in your change, and inside the machine is a little monkey who counts all your change to make sure you put in enough money. When you press the button for your soda, a little light comes on telling the monkey which button you pressed, and if you entered the right amount of change, he grabs your choice and throws it into the little hole for you to grab your soda.
This is the concept of encapsulation. We hide the implementation of the soda machine. Unless it's got one of those fancy, clear windows to let you see the inside, you honestly have no idea how it really works. All you know is that you put in some cash, you press a button, and if you put in enough, you get your drink.
To add to that, you know how to use a soda machine's interface, so therefore as long as the machine's interface follows the usual soda machine interface, you can use it. This is called the interface contract. The machine can be bringing the drinks from Antarctica on a conveyor belt for all you care, as long as you get your drink, it's cold, and you get change back.
Polymorphism is the idea that when you use the soda machine interface, it could be doing different things. This is why encapsulation and polymorphism are closely related. In polymorphism, all you know is that you're using a SodaMachine implementation, which can be changed, and as a result, different things can be done behind the scenes. This leads to the driving concept of polymorphism, which is the ability of one object, the SodaMachine, to actually act as both a MonkeySodaMachine and a ConveyorSodaMachine depending on the machine actually behind the interface.
Probably not word-for-word, but close enough. Essentially it boils down to two concepts: polymorphism and encapsulation. Let me know if you want clarification.
Why is this better than just having individual methods in your classes, and not implementing an interface?
Because if a class C implements an interface I, you can use a C whenever an I is expected. If you do not implement the interface, you could not do this (even if you provided all of the appropriate methods as mandated by the interface):
interface I {
void foo();
}
class C1 implements I {
public void foo() {
System.out.println("C1");
}
}
class C2 { // C2 has a 'foo' method, but does not implement I
public void foo() {
System.out.println("C2");
}
}
...
class Test {
public static void main(String[] args) {
I eye1 = new C1(); // works
I eye2 = new C2(); // error!
}
}
It separates what the caller expects from the implementation. You have a pure set of methods you can call without any knowledge of the implementation. In fact some libraries like JMS and JDBC provide interfaces without any implementations.
This separation means you don't need to know the class of any actual implementation.
An interface allows you to guarantee that certain methods exist and return the required types. When the compiler knows this, it can use that assumption to work with unknown classes as if they had certain known behavior. For example, the comparable interface guarantees that an implementing class will be able to compareTo() some similar object and will return an int.
This means that you can compare anything that implements this interface - so you can sort anything that is Comparable instead of writing one method to sort Strings and another to sort Integers and another to sort LabelledBoxesOfBooks
The interface essentially guarentees that all the methods that inherit it will have its methods, so that you can safely call a method in the interface for anything that inherits it.
It makes it easier to define APIs using interfaces, so that all concrete implementations of the interfaces provide the expected methods in each class.
It also provides a way to implement multiple inheritance, which is not possible (in Java) with straight class inheritance.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
Let's say we have two classes, Tiger and Aeroplane.
One thing in common for these two types is the Speed. I know that it would be illogical to create a superclass ClassWithSpeed and then derive subclasses Aeroplane and Tiger from it.
Instead, it is better to create an interface that contains the method speed() and then implement it in Aeroplane and Tiger. I get that. But, we can do the same thing without interfaces. We could define method speed() in Aeroplane and method speed() in Tiger.
The only (maybe very big) flaw it would be that we couldn't "reach" the objects of Tiger and Aeroplane through an interface reference.
I am beginner in Java and OOP, and I would be very grateful if someone explained to me the role of interfaces.
Cheers!
It's:
public int howFast(Airplane airplane) {
return airplane.speed();
}
public int howFast(Tiger tiger) {
return tiger.speed();
}
public int howFast(Rocket rocket) {
return rocket.speed();
}
public int howFast(ThingThatHasntBeenInventedYet thingx) {
// wait... what? HOW IS THIS POSSIBLE?!
return thingx.speed();
}
...
vs
public int howFast(Mover mover) {
return mover.speed();
}
Now, imagine having to go back and change all those howFast functions in the future.
Interface or no, each class will have to implement or inherit the speed() method. An interface lets you use those disparate classes more easily, because they've each promised to behave in a certain way. You'll call speed(), and they'll return an int, so you don't have to write separate methods for every possible class.
When you find you need to handle speed differently because of a breakthrough in relativistic physics, you only need to update the methods that call speed(). When your great-granddaughter writes a class for HyperIntelligentMonkeyFish, she doesn't have to disassemble your ancient binary and make changes so that your code can monitor and control her mutant army. She needs only declare that HyperIntelligentMonkeyFish implements Mover.
Interfaces allow Java, since it is statically typed, to work around multiple inheritance limitations to the degree felt worthwhile by the language designers.
In a dynamic language (like Python, Ruby, etc.) you can just call the speed method on any arbitrary object and discover at runtime if it is there or not.
Java, on the other hand, is statically typed, which means the compiler has to agree that the method will be there ahead of time. The only way to do that on classes that don't share common ancestry, and may only have Object in common, is an interface.
Since objects can implement an arbitrary number of interfaces, this means you get the goodness of multiple inheritance (a single object that can pose as multiple different objects for different methods) without the downside (of conflicting implementations in the two super classes).
With Java 8, the designers of the language concluded that interfaces without any implementation was overly restrictive (they didn't like my solution I guess ;-)), so they allow for a default implementation, thus expanding the multi-inheritance options of interfaces, while still trying to avoid the conflicting implementation problem via a complex set of precedence rules so that there is an unambiguous default implementation to execute.
I am trying to explain the advantage of interface with the following example-
suppose you have another class where you need to use the tiger or AeroPlane as parameter. So by using interface you can call using
someObject.someMethod(ClassWithSpeed)
but if you dont use interface you can use
someObject.someMethod(Tiger)
someObject.someMethod(AeroPlane)
Now what should you do? Your probable answer will be like, "I will use two overloaded method".
This is okay so far, But
Say you need to add more options (say car, cycle, rabbit, tortoise.... 100 others). So what will you do to make the change of your existing code?? you will need to change a lots of things..
The overall example above has only one purpose. That is to say
"we need interface to create a better, reusable and properly object oriented
design"
N.B.
if you are sure the program is too small and you will never need to change them then I think it is okay to implement without interface
Defining an interface allows you to define methods that work not only on Aeroplane and Tiger, but also other classes that share the same interface.
For example, say your interface is IObjectWithSpeed. Then you can define a method like this -- in a single class that operates on IObjectWithSpeed objects.
public double calculateSecondsToTravel( IObjectWithSpeed obj, double distance ) {
return distance / obj.getSpeed();
}
Interfaces allow us to satisfy the open/closed principle - open for extension, but closed for modification. The single implementation of the method above doesn't need to be modified as new classes are defined that implement IObjectWithSpeed.
I want go into much theoretical details but will try to explain using this example.
Consider JDBC API. It is API used to deal with database related options in the Java. Now, there are so many databases in the industry. How would one write drivers for that? Well, the quick and dirty approach may be write own implementation using our own classes and API.
But think from the programmer's perspective. Will they start learning DATABASE DRIVER's API while using different database? The answer is NO.
So what is the solution to the problem ? Just have a well defined API which anyone can extend for his own implementation.
In JDBC API, there are some Interfaces which are Connection, ResultSet, PreparedStatement, Statement etc. Now each database vendor will implement the interface and will write his own implementation for that. Result ? : Reduced effort from the developer and easy understandability.
Now, what this custom implementation might consisting of ? It's simple. They do what, take ResultSet interface for example and implement it and in whatever method the ResultSet is gettting returned, return THE CLASS THAT IMPLEMENTS ResultSet interface like this
ResultSet rs=new ResultSetImpl(); //this is what they are doing internally.
So interface are like contracts. They define what your class is able to do and they give your application flexibility. You can create your own APIs using interfaces properly.
Hope this helps you.
An interface is not simply a method signature.
It is a type that represents a contract. The contract is the thing, not the method signatures. When a class implements an interface, it is because there is a contract for a shared behavior that the class has an interest in implementing as a type. That contract is implemented via the specified members which are usually method bodies but may also include static final fields.
It may be true that a tiger and an aeroplane both could be expressed as a type with a common behavior implemented through speed() ... and if so, then the interface represents the contract for expressing that behavior.
Aside from being descriptive for those classes' functionality, methods of an interface could be used without any knowledge about the classes implementing it, even for classes that were not yet defined.
So for example, if you'd need a class Transport that computes say efficient routes, it could be given a class that implements ClassWithSpeed as a parameter and use its method speed() for computing what it needs. This way you could use it with our class Aeroplane, but also with any class we define later, say Boat. Java will take care that if you want to use a class as a parameter to Transport it will implement ClassWithSpeed, and that any class implementing ClassWithSpeed implements the method speed() so that it can be used.
The interface (as a language construct) is used by the compiler to prove that the method call is valid and allows you to have dependent classes interact with the implementing class while having the least possible knowledge about the implementing class.
This is a very wide question to give a simple answer. I can recommend a book Interface Oriented Design: With Patterns. It explains all power of interfaces. And why we should not avoid them.
Have you tried using composition instead?, if I want 2 dissimilar classes to inherit the same abilities I use a class which takes an object of the type its working with by using abstract classes and checking the instances. Interfaces are useful for forcing methods to be including in the class but don't require any implementation or for 2 teams of coders to work on different coding areas.
Class Tiger {
public MovingEntity mover;
public Tiger(){
mover.speed=30;
mover.directionX=-1;
mover.move(mover);
}
}
Class Plane {
public MovingEntity mover;
public Plane(){
mover.speed=500;
mover.directionX=-1;
mover.move(mover);
}
Abstract Class Moverable(){
private int xPos;
private int yPos;
private int directionX;
private int directionY;
private int speed;
Class MovingEntity extends Moverable {
public void move(Moverable m){
if(m instanceof Tiger){
xPos+=directionX*speed;
yPos+=directionY*speed;
}else if(m instanceof Plane){
xPos+=directionX*speed;
yPos+=directionY*speed;
}
}
On language level, the only use of interfaces is, like you mentioned, to be able to refer to different classes in a common way. On people level, however, the picture looks different: IMO Java is strong when used in big projects where the design and the implementation are done by separate people, often from separate companies. Now, instead of writing a specification on a Word document, the system architects can create a bunch of classes that implementers can then directly insert in their IDEs and start working on them.
In other words it is more convenient instead of declaring that "Class X implements methods Y and Z in order for it to be used for purpose A, just to say that "Class X implements interface A"
Because creating interface gives you Polymorphism, across all those classes i.e. Tiger and Aeroplane.
You can extend from an (abstract or concrete) class when the base class's functionality is going to be the core of your child class's functionality as well.
You use interfaces when you want to add an augmented functionality to your class in addition to its core functionality. So using interfaces would give you Polymorphism even when its not your class's core functionality (because you've entered a contract by implementing the interface). This is a huge advantage over creating a speed() method with each class.
I know that it is the purpose of the interface and the class can be declared abstract to escape from it.
But is there any use for implementing all the methods that we declare in an interface? will that not increase the weight and complexity of the code if we keep on defining all the methods even it is not relevant for that class? why it is designed so?
The idea of an interface in Java is very much like a contract (and perhaps seen in retrospect this should have been the name of the concept)
The idea is that the class implementing the interface solemnly promises to provide all the things listed in the contract so that any use of a class implementing the interface is guaranteed to have that functionality available.
In my experience this facility is one of the things that makes it possible to build cathedrals in Java.
What you are critizing is exactly the goal interface achieve.
If you don't want to implement an interface, don't declare your class implementing it.
will that not increase the weight and complexity of the code if we
keep on defining all the methods even it is not relevant for that
class?
When you program against an interface, you want the concrete object behind it to implement all its methods. If your concrete object doesn't need or cannot implement all interface method you probably have a design issue to fix.
When any piece of code receives an instance of an interface without knowing what class is behind it, that piece of code should be assured of the ability to call any method in an interface. This is what makes an interface a contract between the callers and the providers of the functionality. The only way to achieve that is to require all non-abstract classes implementing the interface to provide implementations for all its functions.
There are two general ways to deal with the need to not implement some of the functionality:
Adding a tester method and an implementation that throws UnsupportedOperationException, and
Splitting your interface as needed into parts so that all method of a part could be implemented.
Here is an example of the first approach:
public interface WithOptionalMehtods {
void Optional1();
void Optional2();
boolean implementsOptional1();
boolean implementsOptional2();
}
public class Impl implements WithOptionalMehtods {
public void Optional1() {
System.out.println("Optional1");
}
public void Optional2() {
throw new UnsupportedOperationException();
}
public boolean implementsOptional1() {
return true;
}
public boolean implementsOptional2() {
return false;
}
}
Here is an example of the second approach:
public interface Part1 {
void Optional1();
}
public interface Part2 {
void Optional2();
}
public Impl implements Part1 {
public void Optional1() {
System.out.println("Optional1");
}
}
will that not increase the weight and complexity of the code if we
keep on defining all the methods even it is not relevant for that
class?
Yes you are right it will. That is why it is best practice in your coding to follow the Interface Segregation Principle which recommends not to force clients to implement interfaces that they don't use. So you should never have one "fat" interface with many methods but many small interfaces grouping methods, each group serving a specific behavior or sub-module.
This way clients of an interface implement only the needed methods without ever being forced into implementing methods they don't need.
It may depend on Liskov Substitution Principle
So, having A implements B means that you can use A when B is needed and, to make it work without problems, A must have at least the same methods of B.
Please keep in mind that mine is not a "proper" answer, as it's not based on official sources!
When implementing an Interface,we may not need to define all the method declared in the Interface.We can define the some methods,that we don't need,With nothing inside the body.
Closed. This question is opinion-based. It is not currently accepting answers.
Closed 4 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Let's say I wanted to define an interface which represents a call to a remote service. Now, the call to the remote service generally returns something, but might also include input parameters. Suppose that an implementing class will typically only implement one service method. Given the above information, is the following a poor design (it doesn't quite feel right):
public interface IExecutesService<A,B>
{
public A executeService();
public A executeService(B inputParameter);
}
Now, let's say that I implement this interface with a class that executes a remote service with an input parameter:
public class ServiceA implements IExecutesService<String,String>
{
public String executeService()
{
//This service call should not be executed by this class
throw new IllegalStateException("This method should not be called for this class...blabla");
}
public String executeService(String inputParameter)
{
//execute some service
}
I have two questions regarding the above:
Is the use of a generic interface (IExecutesService<A,B>) good in the case where you want to provide subclasses which require different input parameters and return types for the interface methods?
How can I do the above better? I.e. I want to group my service executors under a common interface (IExecutesService); however, an implementing class will typically only implement one of the methods, and the use of an IllegalStateException feels really ugly. Also, the B type parameter in IExecutesService<A,B> will be redundant for an implementing class that calls a service without any input parameters. It also seems overkill creating two separate interfaces for the two different service calls.
Here's one suggestion:
public interface Service<T,U> {
T executeService(U... args);
}
public class MyService implements Service<String, Integer> {
#Override
public String executeService(Integer... args) {
// do stuff
return null;
}
}
Because of type erasure any class will only be able to implement one of these. This eliminates the redundant method at least.
It's not an unreasonable interface that you're proposing but I'm not 100% sure of what value it adds either. You might just want to use the standard Callable interface. It doesn't support arguments but that part of the interface has the least value (imho).
Here's another suggestion:
public interface Service<T> {
T execute();
}
using this simple interface you can pass arguments via constructor in the concrete service classes:
public class FooService implements Service<String> {
private final String input1;
private final int input2;
public FooService(String input1, int input2) {
this.input1 = input1;
this.input2 = input2;
}
#Override
public String execute() {
return String.format("'%s%d'", input1, input2);
}
}
I'd stay with two different interfaces.
You said that 'I want to group my service executors under a common interface... It also seems overkill creating two separate interfaces for the two different service calls... A class will only implement one of these interfaces'
It's not clear what is the reason to have a single interface then. If you want to use it as a marker, you can just exploit annotations instead.
Another point is that there is a possible case that your requirements change and method(s) with another signature appears at the interface. Of course it's possible to use Adapter pattern then but it would be rather strange to see that particular class implements interface with, say, three methods where two of them trow UnsupportedOperationException. It's possible that the forth method appears etc.
As an answer strictly in line with your question, I support cleytus's proposal.
You could also use a marker interface (with no method), say DistantCall, with several several sub-interfaces that have the precise signatures you want.
The general interface would serve to mark all of them, in case you want to write some generic code for all of them.
The number of specific interfaces can be reduced by using cleytus's generic signature.
Examples of 'reusable' interfaces:
public interface DistantCall {
}
public interface TUDistantCall<T,U> extends DistantCall {
T execute(U... us);
}
public interface UDistantCall<U> extends DistantCall {
void execute(U... us);
}
public interface TDistantCall<T> extends DistantCall {
T execute();
}
public interface TUVDistantCall<T, U, V> extends DistantCall {
T execute(U u, V... vs);
}
....
UPDATED in response to OP comment
I wasn't thinking of any instanceof in the calling. I was thinking your calling code knew what it was calling, and you just needed to assemble several distant call in a common interface for some generic code (for example, auditing all distant calls, for performance reasons).
In your question, I have seen no mention that the calling code is generic :-(
If so, I suggest you have only one interface, only one signature. Having several would only bring more complexity, for nothing.
However, you need to ask yourself some broader questions :
how you will ensure that caller and callee do communicate correctly?
That could be a follow-up on this question, or a different question...
If I understand correctly, you want to have one class implement multiple of those interfaces with different input/output parameters? This will not work in Java, because the generics are implemented via erasure.
The problem with the Java generics is that the generics are in fact nothing but compiler magic. At runtime, the classes do not keep any information about the types used for generic stuff (class type parameters, method type parameters, interface type parameters). Therefore, even though you could have overloads of specific methods, you cannot bind those to multiple interface implementations which differ in their generic type parameters only.
In general, I can see why you think that this code has a smell. However, in order to provide you with a better solution, it would be necessary to know a little more about your requirements. Why do you want to use a generic interface in the first place?