interface Block{
void printblock();
}
interface Block2{
void printblock();
}
class Impl2 implements Block,Block2{
#Override
public void printblock() {
// TODO Auto-generated method stub
System.out.println("Impl2");
}
}
public class Import
{
public static void main(String[] args) {
new Impl2().printblock();
}
}
Now please say me which printblock method is implementing by the class Import.Its implementing Block interface or Block2 interface?
Interface is just a contract and in your case there are two different interfaces vouching that that a class has a method implemented with a particular signature so it doesn't matter which interface the method belongs to.
As both interface have same method signature both method will be implemented by Impl2 class as a one method. Impl2 class is implementing a method printblock() with the same signature both interfaces has.So you can say that Imlp2 is implementing method of both the interfaces.
When you are writing
new Impl2().printblock();
It doesnt matter what Interface the method printblock is part of.
If you write something like
Block block1 = new Impl2();
block1.printlblock(); or similarly block2.printblock().
Here now both are valid statements and since both have the same method definition, same method will be executed. Interesting thing is because their definition is same its not possible to implement same method definitions in two different ways(though you want it differently for each of them)
Your question has already been answered here
Syntactically, an interface doesn't really mean anything other than the fact that some method of a certain name exists.
Semantically, however, the power of interfaces is that they form a "guarantee" of an implementation of some method to be in accordance with the behavior described by the interface itself. That is, by choosing to implement Block or Block2, you are contracting yourself to their behavioral expectations (specifically, containing their method).
In your example, the fact that your class implements both Block and Block2 is an explicit statement that you are implementing both of them--don't be confused by the fact that their method names are the same! The syntax only tells you that the method EXISTS in Impl2. What's more important is what behaviors Block and Block2 define/expect.
For example, if you had two interfaces called List and Set, and wanted one data structure to be able to represent both semantically, you may have a size() method that is the same for both, and thus it implements both List.size() and Set.size().
Of course, interfaces are also very easy to abuse if you are not careful with semantics. You would have big issues implementing both List and Set if they defined the same add() method, because by definition, the List.add() behavior allows duplicates, and Set.add() does not. So there is a trap here--you may think you can implement both interfaces based on similarities in some methods, but it turns out they define fundamentally different behaviors in other methods.
In general, it seems to me like any time you are implementing two interfaces at the same time with the same method, something is wrong with the class design. Perhaps what you really wanted to do was combine shared behavior into a superinterface, and implement that. It would be a much stronger construct since you would be explicitly defining the shared portions of the interfaces, and wouldn't run into implementation issues with the distinct portions.
Related
I want to know of a situation where I could implement cascading.operation.Buffer, cascading.operation.Function and perform operation on tuples.
public class Hello extends BaseOperation implements Buffer, Function {
}
I am not sure if the above class will work or not.
If it works then which operate method will be called?
Any practical scenarios where I should implement it? Any Performance issues?
The interfaces you are talking about are:
cascading.operation.Buffer<C>
cascading.operation.Function<C>
They indeed both have an operate() method, but the methods have different parameter signatures, more specifically:
void operate(FlowProcess flowProcess,BufferCall<C>bufferCall)
for Buffer
void operate(FlowProcess flowProcess,FunctionCall<C>functionCall) for Function
The common superinterface of those two (i.e. Operation<C>) that is used in BaseOperation<C> class has nothing to do with operate() method, as it's only defined in the subinterfaces.
So to answer which operate() method will be called:
Depends on the type of second parameter that's passed to the method.
Can Someone Explain how the methods of interface used in classes?
Note: My Doubt is "Methods are already defined in Class then why we should implement it ? "
For Example :
interface printable{
void print();
}
class A implements printable{
public void print(){System.out.println("Hello");}
public static void main(String args[]){
A obj = new A();
obj.print();
}
}
why print() is declared in interface??
You define a method by giving its implementation. They are the same thing, so you are right that once you define a method, you don't also need to implement it.
An interface declares that anything implementing this interface will defined those methods. This is part of the contract for interfaces. This allows you to call any method of an interface knowing than any concrete implementation will have such a method.
BTW In Java 8, it will support virtual extensions which means an interface can give a default implementation. This has to be defined in terms of other methods provided by the interface.
An Interface is a contract that all classes that implement it, should have a definition for the methods specified in the interface. An interface does not define the method body as such.
An interface defines a set of method which must be implemented. It says nothing on how they are implemented. This is where the class definition comes in, since it defines how these methods are implemented.
Thus, when you call a class which implements a particular interface, then you know, for sure, that you will find whatever set of methods the interface defines.
Interfaces are usually handy when you need to expose some endpoints to your application, without the need to expose the logic.
EDIT: As per your example, the printable interface defines what behaviour should a class which implements it expose, in this case print.
This will allow you to do something along the lines of printable p = new A(); p.print();.
Assuming you have something which yields an object which implements the printable interface, then, whoever is calling that method will not need to bother what is the actual implementation of the print method. The interface makes sure that whatever you are returning, will contain an implementation of that method.
#NarutoUzumaki
Welcome to Stack overflow!
I agree with Chris. You can replace the doSomething method with eat() method to get a better understanding. A dog may eat something different than a cat and to a giraffe.
Its up to you how you implement the eat method, and when using it create a reference of the interface Animal and point it to the instance of Dog, Cat or Giraffe which ever eat method you want to use. This makes your class design very extensible.
Hope you get a clear idea now.
Generally Interface based Programming is recommended, Because of the following reasons
1)Interface means rule , you should follow those rules while implementing those methods in Implemented class.
2) Dependency is less between classes while instancing your implemented class then call your methods from another class or some where.
3) You can publish your interface details only no need to disclose the implemented details of your methods to out side the world.
Defining an interface is the difference between:
public void doSomething(Dog d)
{
d.doSomething();
}
public void doSomething(Cat c)
{
c.doSomething();
}
public void doSomething(Giraffe g)
{
g.doSomething();
}
and
public void doSomething(Animal a)
{
a.doSomething();
}
Why?
Well, if all the classes just implement their own methods, there's no common reference between them. However, if they all implement the method from a common interface, they can be referred to by the same reference type; in this case Animal.
I have seen in many libraries like Spring which use a lot of interfaces with single methods in them like BeanNameAware, etc.
And the implementer class will implement many interfaces with single methods.
In what scenarios does it make sense to keep single method interfaces? Is it done to avoid making one single interface bulky for example ResultSet? Or is there some design standard which advocates the use of these type of interfaces?
With Java 8, keeping the single method interface is quite useful, since single method interfaces will allow the usage of closures and "function pointers". So, whenever your code is written against a single method interface, the client code may hand in a closure or a method (which must have a compatible signature to the method declared in the single method interface) instead of having to create an anonymous class. In contrast, if you make one interface with more than one method, the client code will not have that possibility. It must always use a class that implements all methods of the interface.
So as a common guideline, one can say: If a class that only exposes a single method to the client code might be useful to some client, then using a single method interface for that method is a good idea. A counter example to this is the Iterator interface: Here, it would not be useful having only a next() method without a hasNext() method. Since having a class that only implements one of these methods is no use, splitting this interface is not a good idea here.
Example:
interface SingleMethod{ //The single method interface
void foo(int i);
}
class X implements SingleMethod { //A class implementing it (and probably other ones)
void foo(int i){...}
}
class Y { //An unrelated class that has methods with matching signature
void bar(int i){...}
static void bar2(int i){...}
}
class Framework{ // A framework that uses the interface
//Takes a single method object and does something with it
//(probably invoking the method)
void consume(SingleMethod m){...}
}
class Client{ //Client code that uses the framework
Framework f = ...;
X x = new X();
Y y = new Y();
f.consume(x); //Fine, also in Java 7
//Java 8
//ALL these calls are only possible since SingleMethod has only ONE method!
f.consume(y::bar); //Simply hand in a method. Object y is bound implicitly
f.consume(Y::bar2); //Static methods are fine, too
f.consume(i -> { System.out.println(i); }) //lambda expression. Super concise.
// the above could even be more concise
// presenting all the beauty of the recent Java changes
f.consume(System.out::println)
//This is the only way if the interface has MORE THAN ONE method:
//Calling Y.bar2 Without that closure stuff (super verbose)
f.consume(new SingleMethod(){
#Override void foo(int i){ Y.bar2(i); }
});
}
Interfaces with only one (or few) methods is the key to the highly useful Strategy pattern, which is "some design standard which advocates the use of these type of interfaces".
Another common scenario is when you want a callback. Foo calls Bar as an asynchronous task, and when Bar is finished with something, the result is sent back to Foo using a callback -- which can be an interface containing only one method. (An example of this is the many listeners in Android, Event Listeners in Swing...)
Also, if you have two classes that are tightly coupled with one another (let's call them Foo and Bar). Foo uses nearly all of Bar's methods, but Bar only needs some a few of those from Foo. Foo can implement FooInterface which is then sent to Bar. Now the coupling is looser, because Bar only knows about the FooInterface, but does not care about the other methods the implementing class contains.
In what scenarios does it make sense to keep single method interfaces?
In such a scenarios when you need an interface with only one method.
Interfaces are used to encapsulate a common behavior of several classes. So if you have several places in your code where you need to call only limited set of class methods, it's time to introduce an interface. The number of methods depends on what exactly do you need to call. Sometimes you need one method, sometimes two or more, sometimes you don't need methods at all. What matters is that you can separate behavior from implementation.
Favor Composition over Inheritance tutorial of Head First Design Pattern book recommends this approach to add functionality dynamically to a class. Let's take below case:
public interface Quackable {
public void quack();
}
public class Quacks implements Quackable {
public void quack(){
//quack behavior
}
}
public class DontQuack implements Quackable {
public void quack(){
//dont quack
}
}
public class QuackableDuck{
Quackable quack; //add behavior dynamicall
}
So QuackableDuck class can add feature dynamically.
quack = new Quacks();
//or
quack = new DontQuack();
So similarly you can add multiple behavior to the class dynamically.
You create interfaces not according to the number of methods in it but to define behaviour expected by components of your systems to deliver a single responsibility to their neighbors. If you follow this simple principle/rule, you might or might not end up with single method interfaces, depending on the responsibility you are defining. I like to keep tests stupid simple and the application very flexible so I usually have many of those
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.
HI
I have a question If interface has got four methods,and I like to implement only two methods, how this could be achieved?
Can any explain is that possible or should I go for implementing all the methods.
You can't "partially" implement an interface without declaring the implementing class abstract, thereby requiring that some subclass provide the remaining implementation. The reason for this is that an interface is a contract, and implementing it declares "I provide the behavior specified by the interface". Some other code is going to use your class via the declared interface and will expect the methods to be there.
If you know the use case does not use the other two methods you can implement them by throwing OperationNotSupported. Whether this is valid or not very much depends on the interface and the user. If the interface can legitimately be partially implemented this way it would be a code smell that the interface is poorly designed and perhaps should have been two interfaces.
You may also be able "implement" the interface by doing nothing, though this is usually only proper for "listener" or "callback" implementations.
In short, it all depends.
If you control the design of the interface, simply split it in two. One interface specifies the two only some implementations implement, and one interface specifies the other two (or inherits the first two and adds more, your choice)
You can make the implementing class abstract and implement two of the 4 methods from the interface.
I think #sateesh 's answer is the one closer to solving your problem. Let me elaborate on it. First of all, it is imperative that any class implementing an interface should provide definitions for all of its methods. But in some cases the user may find no use for a majority of the methods in the interface save for one or two. Consider the following interface having 6 abstract methods:
public interface HugeInterface {
void a();
void b();
void c();
void d();
void e();
void f();
}
Suppose your code finds use for the method 'c()' only and you wish to provide implementation details for only the method 'c()'. You can create a new class HugeInterfaceAdapter in a separate file which implements all the methods of the interface HugeInterface like shown below:
public class HugeInterfaceAdapter implements HugeInterface {
public void a() {}
public void b() {}
public void c() {}
public void d() {}
public void e() {}
public void f() {}
}
Note that you need not provide any actual implementation code for any of the methods. Now comes the interesting part. Yes, your class in which the need to implement a huge interface arose in the first place.
public class MyClass {
HugeInterfaceAdapter mySmallInterface = new HugeInterfaceAdapter() {
#Override
public void c() {
//Your class-specific interface implementation code here.
}
};
}
Now you can use the reference variable mySmallInterface in all the places where a HugeInterface is expected. This may seem a little hackish but I may say that it is endorsed officially by Java and classes like MouseAdapter bears testimony to this fact.
It's not possible.
You can implement all four methods, but the two you don't need should throw an UnsupportedOperationException.
If you want a concrete class which is implementing this interface, then it is not possible to have unimplemented methods, but if you make have abstract class implementing this interface then you can leave any number of methods as you want to be unimplemented.
As other answers mention you cannot have a concrete class implementing only some of the methods of the interface it implements. If you have no control over the interface your class is extending, you can think of having Adapter classes.
The abstract Adapter class can provide dummy implementation for the methods of an interface and the client classes can
extend the Adapter class. (Of course the disadvantage is that you cannot extend more than one class)
This is common practice with GUI programming (using Swing) where the event listener class
might not be interested in implementing all methods specified by the EventListener interface. For example
take a look at the java.awt.event.MouseListener interface and and the corresponding adapter class java.awt.event.MouseAdapter.