What is the interface?

[Ritesh Pareek]

Hi all,
I am not very clear with concept of interface.My confusions are about following things i.e.
1. Interface is used to implement multiple inheritance( i dont think so)
2. Interface is a contract, so that we can implement integrity at architator level(seems to be)
As we see in design pattrens we implement interface to build design constructs.
thanks

[Greg Charles]

You have a pretty good grasp of it. Interfaces define what an object can do for you, rather than defining how it does it. That can be helpful for reducing dependencies. Maybe you are performing some calculations, and you call a method in your object to do that work. Suddenly you get access to a supercomputer in Estonia (it could happen) and you want to take advantage of its capabilities. If your program used an interface to access the object, you could implement a class with the same interface that would send the data over to the supercomputer and return the results. The rest of your program wouldn't have to know that anything changed.

Java doesn't not allow multiple inheritance, but you can do something similar with interfaces. Let's say you have a Horse class and a Donkey class and you want to implement a Mule class that combines the two. Well, you can't do it. However, if you have Horse and Donkey interfaces, you can create a class that implements both of them. Then you can cast your Mule to a Horse, or to a Donkey and either will work.

Finally, Java interfaces can be used as markers. The most popular example of this is java.io.Serializable. It doesn't contain any methods to implement, but it tells the JVM that the author of the class says it's OK for the internal values to be converted to a serial form for sending over a network or saving to a file or database (which is a possible security issue for sensitive data).

[Rahul Jadaun]

I'll put in my 2 cents :
I won't call it multiple inheritance. Multiple behaviour is more apt. Its like you can inherit from only one class(like 'Car' inherits from 'Vehicle') but can implement different behaviours (like Sporty, Spacious, Economical).
Yes, an interface is a contract. Its a blueprint of what the implementing class should do. The implementing class has to have the same methods as described in the blueprint and must return the same objects as the methods declare.

Its like the called class sits down with the calling class and says - 'We have had enough fights before. From now on, lets just decide on the behaviour you need from me. I'll implement it any which way I want but I am not letting you see how I do it!'
And the calling class says - 'Yeah.. who cares how you do it as long as you exactly do whatever behaviour we agree upon'

Benefits and Uses are :
1. Loose coupling : The code that calls an interface method, does not need to know anything about the implementation.
2. Runtime polymorphism : You can decide at runtime which implementation you want to send. Its all the same to the calling code.
3. Interfaces are also used as markers to denote certain type of behaviour.

[Ritesh Pareek]

Thanks Greg Charles and Rahul Jadaun.


@Greg

That can be helpful for reducing dependencies

@Rahul

Loose coupling : The code that calls an interface method, does not need to know anything about the implementation.

Interfaces are also used as markers to denote certain type of behaviour.

Want more on marker(Anyway i am posting new thread on fourm )
Can you please elaborate it more? It seems both points indicating same concept.

@All

Please consider following architecture for model layer:

1. MyPojoClass implements MyPojoIfc
2. MyDaoClass implements MyDaoIfc
and there is one more in-between layer called Manager Layer

3. MyManagerClass implements MyManagerIfc

Now while using we are doing it like this

MyManagerIfc myManagerObj = MyManager.getInstance(); // Will call all methods of DAO
MyPojoIfc myPojoObj = myManagerObj.getDaoMethodViaManager();//

here calling of manager method is a kind of proxy calling.

If you can explain me the purpose and concept of above design(specially the role of interfaces here and putting an extra layer of manager)

Thanks & Regards

Ritesh PAreek

[Istvan Kovacs]

Ritesh Pareek wrote:
Want more on marker

Interfaces that do not define any methods (such as Serializable, Cloneable) can still be used in instanceof checks. For example, Object's protected clone() method will perform such a check, and throw and Exception if it's invoked on a method that does not implement Cloneable (similar logic can be found in the serialization mechanism). By implementing the marker interface, the developer claims that he has done his homework (made sure Object's clone() is safe to invoke, or that all non-transient fields the class are Serializable).

Ritesh Pareek wrote:
@All

Please consider following architecture for model layer:

class MyPojoClass implements MyPojoIfc
class MyDaoClass implements MyDaoIfc
// and there is one more in-between layer called Manager Layer

class MyManagerClass implements MyManagerIfc

Now while using we are doing it like this

MyManagerIfc myManagerObj = MyManager.getInstance(); // Will call all methods of DAO 
MyPojoIfc myPojoObj = myManagerObj.getDaoMethodViaManager();//

here calling of manager method is a kind of proxy calling.

If you can explain me the purpose and concept of above design(specially the role of interfaces here and putting an extra layer of manager)

The returned POJO may be wrapped in a dynamic proxy that can record changes to its properties via setter methods, so SQL to save it in the database can be generated based on those calls. Therefore, the object returned by myManagerObj.getDaoMethodViaManager(); may not be an instance of the class but a proxy using the same interface.

MyManagerIfc myManagerObj = MyManager.getInstance(); 

I think this is pretty much useless in this form. Interaces are nice to isolate the contract from the implementation. With dependency injection, it would be possible to plug in any kind of manager (e.g. for production you have the real class, for testing, you can have something based on an in-memory collection). However, wiring it up like this means that although you use the interface, you fix the reference to an actual class. Either of these would be better in that aspect:

public class Foo
{
	private final MyManagerIfc myManager;
	
	// constructor injection
	public Foo(MyManagerIfc manager)
	{
		myManager = manager;
	}
}

or

public class Foo
{
	private MyManagerIfc myManager;
	
	// setter injection
	public setManager(MyManagerIfc manager)
	{
		myManager = manager;
	}
}

Dependency injection frameworks will support both; when testing, you don't need to rely on the framework, you can simply instantiate your dummy manager and pass it to your object via the constructor or the setter.

You may sometimes still use the interface to make your code easier to change:

public class Foo
{
	// use interface but initialise with concrete class
	private final Collection<String> myNames = new ArrayList<String>();
	
	public Collection<String> getNames()
	{
		return Collections.unmodifiableCollection(myNames);
	}
}

public class FooUser
{
	private Foo myFoo;
	
	public FooUser(Foo foo)
	{
		myFoo = foo;
	}
	
	public int getNameCount()
	{
		return myFoo.getNames().size();
	}
}

Here FooUser does not depend on what exact type of Collection you use in Foo. If you decide you want your names ordered alphabetically instead of keeping insertion order, you could simply replace

	private final Collection<String> myNames = new ArrayList<String>();

with

	private final Collection<String> myNames = new TreeSet<String>();

and keep everything else unchanged. Consider this with exposing ArrayList in Foo's interface, and also expecting an ArrayList in FooUser - you'd have to modify Foo at several places, and modify FooUser, too.

[Ritesh Pareek]

@Istvan Kovacs

Thanks for valuable explanations. Got a way to study more and will come back again

Thanks all

[Robby Robinson]

Think of an as contact that say in order to be Type A the implementing class must provide these thing. it works as a type definition that is not tide an hierarchy.
A furniture catalog

many types furniture each available in many materials you don't to create materials classes for type of furniture , so you create
interfaces for material type then every concrete implementation Of furniture would implement the appropriate interface

Interface are also good for runtime binding.

creating a killer bots program all the abilities not common to bots, you want define in an interface



The are also the comer stone of refactoring to learn read read interface orientated Design