interface

[Priya_Aggarwal]

why do we need interfaces in java?,if the functions are to be defined in implementing class only then why declare these in an interface first?????????

[Alex Edwards]

why do we need interfaces in java?,if the functions are to be defined in implementing class only then why declare these in an interface first?????????

There needs to be some kind of simple commonality between classes.

An interface allows for many benefits via the implementation of the Object Model and how objects communicate with each other, encapsulate other objects, and additional inherit information from existing classes.

For example, suppose I have an Expert System that was incredibly difficult for developers to produce. It issues commands on a Module object--

ExpertSystem es = ExpertSystem.getCurrentSystem(); // get the current ExpertSystem

es.startModule(); // executes the Module object

// inside the Module class

void start(ExpertSystem ex){

       // perform operations for the given ExpertSystem

}

--however, what if an improved Module is produced, and the ExpertSystem needs to use it, but the improved Module does not have the same implementations as the one the ExpertSystem is used to using?--

Module2 nextModule = new Module2(); // doesn't share the same data as a regular Module

// ExpertSystem cannot use the new Module!

--Now this is a pain... we have a new Module and we can't even use it with the existing system!

Fortunately, knowing that the System can use Modules is a convenient thing. What we can do is treat Module's the System is used to as the abstraction.

Let's pretend Module is a class--

class Module{

      public void start(ExpertSystem ex){
          // perform operations for ExpertSystem     
      }

}

--ok, this is nice.. but unfortunately we need Module2 to be recognized by the ExpertSystem as an existing Module. We could try to extend from Module--

class NextModule extends Module{

}

-- but now we are ignoring the new Module that was supplied to us! We need the behavior or Module for the new Module called Module2.

It would be nice if we could inherit from 2 classes, but there's a strict rule in the Java language specification! You can only extend from one class!

Not only that, but Module2 unfortunately extends from other existing classes! So even if we wanted to alter Module2 to be like a regular Module, we wouldn't be able to!

What are our options then??

Luckily there are ways around this!

The complicated way would be to encapsulate the new Module2 in an implementation that the ExpertSystem recognizes and still perform operations for Module2 objects.--

class NewModule extends Module{

        private Module2 m2; // the new Module we'd like to use somehow

        public NewModule(Module2 m2){
             this.m2 = m2;
        }

        @Override void start(ExpertSystem ex){
             m2.doOperation(ex, 0, new Object() ); // does some operation based on args
        }
}

--which is very handy. This demonstration reflects the Adapter Pattern, though most likely in a poor or misrepresented fashion.

However, even this can be overkill. If the ExpertSystem was programmed to manipulate commands on an interface instead, we wouldn't be limited to doing such painful encapsulating just to get the necessary behavior. For example, if the ExpertSystem issued commands on an interface object--

interface Module{

    public void start(ExpertSystem ex);

}

// inside the ExpertSystem

void startModule(){

      modObj.start(this);
 
}

-- then we could implement the Module interface and register the implementing class to the ExpertSystem as a Module with added behavior--

ModuleAdapter extends Module2 implements Module{

       public ModuleAdapter(){
       }

       @Override void start(ExpertSystem ex){
              this.doOperation(ex, 0, new Object() );
       }
}

-- this is a variation of the Adapter mentioned before. It's called a class Adapter, where ModuleAdapter acts as the connecter between the Module2 and Module interfaces (in a vague sense). Now ModuleAdapter can be treated not only as a Module object but a Module2 object as well. Notice that this is legal because we are still extending just one class.

It would be far far more convenient if we could alter Module2 (let's say we can), then we could do something like this--

class Module2 implements Module{
     // operations here
}

--and instead of having to make a new Adapter class, we can directly inherit the information and override it... though nicer looking, it can be more or less convenient depending on how many interface methods you must override.