It is a promise of code. Doesn't that just sound horrible. When I first heard that I was about to promise the book a lighter. But you have to work with it to really understand it.
Lest say you define an Interface that promises roughly 10 methods. Basically some getting and setting methods. Then you implement that interface in different classes. Class A works with a Database. Class B works with .txt data. Class C is a GUI class. Class D is something else (work with me here, I am streching my imagination as it is..).
So basically class A would look like: public class A implements myInter{.....} and all the other ones would be somewhat similar. (sure maybe some extends and further implements, but you get the idea.)
Now suppose you are in class C somewhere and you want to use an instance of the interface? What? It is an interface we can't do that! Yes we can. All that is needed is to return one of the implementing classes as an instance of that interface. So in effect class C can access class A but call it the inteface name. And if you happen to be anticipating dynamic events that could work to your advantage. ie a method in Class T that has the interface as a parameter. Then classes A,B,or C could be passed in. The methods available would only be those defined in the Interface, but with good planning those would be anticipated.
How is that for some good ol' rambling?
Tom
Main Topics
Browse All Topics
by: m_onkey_boyPosted on 2002-03-07 at 00:51:12ID: 6846682
The interface is a contract between classes implementing the inteface and the client that uses them.
Here's an example:
Let's say that your application communicates with another server via XML transactions. You could write a class called XMLCommunicator that does this communication, and that works fine. Now suppose you add another server to your network that communicates with some sort of binary stream. You have to code another class to do this, say you call it BinaryCommunicator. This works, but now you have to re-code your main application to instantiate the correct class based on which server you want to talk to. Putting this logic in your main application is bad from a OO point of view, as well as a maintenance point of view.
A better solution would be to define an interface called Communicator with a single method called send(). Your XMLCommunicator and BinaryCommunicator both implement this interface. Now you can write a class called CommunicatorManager that has a method called getCommunicator(int nType). Here's how it looks:
public interface Communicator {
public void send();
}
public class CommunicatorManager {
public static final int XML = 0;
public static final int BINARY = 1;
public static Communicator getCommunicator (int nType) {
return (nType == XML) ? new XMLCommunicator() : new BinaryCommunicator();
}
}
public class MainApp {
public static void main (String[] args) {
Communicator c = CommunicatorManager.getCom
c.send();
}
}
--------------------------
This model abstracts your sending logic from your main application. To add more Communicators, all you have to do is implement the send() methos and add a few lines of code to CommunicatorManager without having to touch your main application. This hides how the message is sent from the main app, so it can keep it;s code clean.
--------------------------
The JDBC classes are a good example of interfaces at work. You can connect to mysql or sqlserver by changing two lines of code somewhere in your application to switch from one database to another, provided you have the JDBC implementations for each database. These databases behave entirely different, but your code doesn't need to know this because it is hidden behind the interfaces.