interfaces vs abstract classes

Pulagara Murali

abstract classes provides all facilities over interfaces except multiple inheritance.
But in when ever providing additional functionalities it is risky process in interfaces. why should we go for interfaces? give me any one reply please?

7 Replies

Know the answer? Post it — somebody with the same question will find it here.

Suthish Nair15y ago
Murali, check Our recommended articles section on right side for more informations. Also, change your signature to small font.
0
Pulagara Murali15y ago
Than you for giving response
0
Pulagara Murali15y ago
Than you for giving the reply
0
Pulagara Murali15y ago
Than You for giving the Response;

murali.
0
Krishna Garad15y ago
Other than Interfaces support team development. Like interfaces contain only Declaration and not implementation. means we can declare methods in Interface and actual implemantation is going in classes. it's nothing but one of the team development. Interfaces have one drawback again If in future have some modification and 1000's of classes implementing that interface then we have to modify that 1000's of classes also. One compramize solution for this problem is declare one another interface and ask to other classes to implement that.
0
Vulpes15y ago
Apart from multiple inheritance, I can think of only one thing that you can do with interfaces which you can't do with abstract classes, namely you can implement them 'explicitly'. For example:

interface IFace
{
   void MyMethod();
}

class MyClass: IFace
{
   // explicit interface implementation
   void IFace.MyMethod()
   {
   Console.WriteLine("Hello from MyMethod");
   }
}

When you do this, MyMethod() is effectively hidden from users of MyClass who cannot access it using a MyClass reference; they can only access it via an IFace reference:

MyClass mc = new MyClass();
mc.MyMethod(); // compiler error
((IFace)mc).MyMethod(); // works fine

In a sense, IFace.MyMethod() is both private and public :)

Explicit interface implementation can be useful for removing clutter from a class's public interface and is used extensively in the .NET Framework itself.
0
Jaganathan Bantheswaran15y ago
Hi murli,
Interface:
-- If your child classes should all implement a certain group of methods/functionalities but each of the child classes is free to provide its own implementation then use interfaces.
For e.g. if you are implementing a class hierarchy for vehicles implement an interface called Vehicle which has properties like Colour MaxSpeed etc. and methods like Drive(). All child classes like Car Scooter AirPlane SolarCar etc. should derive from this base interface but provide a seperate implementation of the methods and properties exposed by Vehicle.
-- If you want your child classes to implement multiple unrelated functionalities in short multiple inheritance use interfaces.
For e.g. if you are implementing a class called SpaceShip that has to have functionalities from a Vehicle as well as that from a UFO then make both Vehicle and UFO as interfaces and then create a class SpaceShip that implements both Vehicle and UFO .
Abstract Classes
-- When you have a requirement where your base class should provide default implementation of certain methods whereas other methods should be open to being overridden by child classes use abstract classes.
For e.g. again take the example of the Vehicle class above. If we want all classes deriving from Vehicle to implement the Drive() method in a fixed way whereas the other methods can be overridden by child classes. In such a scenario we implement the Vehicle class as an abstract class with an implementation of Drive while leave the other methods / properties as abstract so they could be overridden by child classes.
-- The purpose of an abstract class is to provide a common definition of a base class that multiple derived classes can share. For example a class library may define an abstract class that is used as a parameter to many of its functions and require programmers using that library to provide their own implementation of the class by creating a derived class.

0