what are the use of interfaces and diffrences with respect to inheritance

Wh开发者_运维技巧at are the major advantages of interfaces in designing application and the differences with respect to inheritance. can any body provide me with the brief example.

Objects define their interaction with the outside world through the methods that they expose. Methods form the object's interface with the outside world; the buttons on the front of your television set, for example, are the interface between you and the electrical wiring on the other side of its plastic casing. You press the "power" button to turn the television on and off. In its most common form, an interface is a group of related methods with empty bodies.

A bicycle's behavior, if specified as an interface, might appear as follows:

interface IBicycle {

       void changeCadence(int newValue);   // wheel revolutions per minute

       void changeGear(int newValue);

       void speedUp(int increment);

       void applyBrakes(int decrement);
}

To implement this interface, the name of your class would change (to a particular brand of bicycle, for example, such as ACMEBicycle), and you'd use the implements keyword in the class declaration:

class ACMEBicycle : IBicycle {

   // remainder of this class implemented as before

}

Implementing an interface allows a class to become more formal about the behavior it promises to provide. Interfaces form a contract between the class and the outside world, and this contract is enforced at build time by the compiler. If your class claims to implement an interface, all methods defined by that interface must appear in its source code before the class will successfully compile.

You can find more details also checking difference between Interface and Class.

The only differences between interfaces and classes is:

• Interfaces cannot have implementation
• Classes can only be singly inherited

Interfaces are best used in places where:

• Multiple class shared functionality on a conceptual level, but do not actually share code.
• Where there is a hard separation between provider and user of a class, when the provider does not wish to share any details of the class itself. (This does not necessarily mean secrecy --- In WCF, the user & provider of a class may be separated by the internet; the user would need to have the interface to access the remote object)

An advantage of using interfaces is that you can use mocked objects during your unit tests.
E.g. When a method requires a DbConnection instance, you have to provide it - which can be very difficult within a small test. But when it requires a IDbConnection you can provide a mockup.
There is a tag "mocking" on SO.

Interfaces are used extensively in many advanced design patterns. Especially if the application design uses any sort of Dependency Injection or Inversion of Control.

For instance, a plug-in (add-on) model typically uses interfaces to define the plugin. There will be an interop library (DLL), strictly versioned, which defines the interfaces that can/should/must be implemented by any plug-ins to be consumed by the app.

The application project references the interop library, which allows it to consume any classes that implement those interfaces, without requiring direct references to the actual classes.

The concrete implementations of the plug-ins reference the interop library so that the classes in it can implement the required interfaces. The app has no direct knowledge of the plug-in library, and the plug-in library has no direct knowledge of the app. The can only potentially communicate through the interop interfaces.

In the plug-in scenario, it's common for the app to have a designated folder where plug-ins are located. At run-time, it scans the folder for assemblies, scans each assembly for classes/structs, examines each class/struct for known (interop) interfaces, and dynamically loads whatever matching plug-ins it finds by interface. Depending on the mechanism, each plug-in is usually added to a menu somewhere so that it can be used by the end user.

In this model, plug-ins can be updated without having to recompile the app, and the app can be updated without having to recompile the plug-ins. As long as the interop library version/signature doesn't change, the app itself or individual plug-ins can be updated/modified/fixed independently without having to redistribute the whole kit-n-kaboodle.

Also, 3rd parties that are going to develop plug-ins for your app only have to focus on implementing specific interfaces from your interop, without having to be concerned with the specifics of how your app consumes them.

Icognito has a good answer (which I upvoted). I only wanted to add the following:

An Interface defines method signatures that any implementing object must have. It enables your code to call methods on those objects without knowing anything else about it.

A class defines method signatures and may define method bodies and properties. A class may implement an Interface. This gives you the ability to keep both data and the manipulation code together.

Icognito's remote example was actually better than the bicycle. A TV might have an Interface like:

interface ITelevision {
  void TogglePower();
  void ChangeChannel( Int32 channel);
}

A couple of objects that might deal with that interface would be one or more TV objects and a Remote object like:

class SonyTelevision: ITelevision {
  public void TogglePower {
    //Perform the operation to turn the TV on or off
  }
  public void ChangeChannel (Int32 channel) {
    // Perform the operation of changing the channel
  }
}

class ToshibaTelevision: ITelevision {
  public void TogglePower {
    //Perform the operation to turn the TV on or off
  }
  public void ChangeChannel (Int32 channel) {
    // Perform the operation of changing the channel
  }
}

class Remote {
  private _television : Object; // here we don't care what kind of TV it is.

  public void ToggleTvPower {
    ITelevision tv = _television as ITelevision;
    tv.TogglePower();
  }
}

In the above, both the Sony and Toshiba manufacturer might have their own class hierarchy for the TV's. However, they both implement the common ITelevision interface which makes coding against those classes MUCH easier.

Note also that an interface means that implementation is left up to the implementing class. At the end of the day as long as everyone implements ITelevision the any remote will be able to control any TV. Even future ones...

A final note: Abstract classes are similar to Interfaces in that abstract classes require descendants to provide the method bodies. However, because a class may only inherit from a single parent class whereas a class may implement as many interfaces as you want.