0

I am asp.net programmer.i have read the articles of abstract class and interface and i know how to implement it also.but can anybody explain me practically i.e. by referring project scenario where to use abstract class and where to use interface?

I need a very practical or real world project example, so that i can implement it in my project very efficiently?

Thanks in advanced.

  • possible duplicate of [When to use an interface instead of an abstract class and vice versa?](http://stackoverflow.com/questions/479142/when-to-use-an-interface-instead-of-an-abstract-class-and-vice-versa) – Ofer Zelig May 10 '12 at 10:31

3 Answers3

0

I can't give you a practical example straightaway but let me explain the fundamental difference between both things with small examples:

An abstract class is part of a hierarchical structure of classes. That means they are used for inheritance. Interfaces have nothing to do with inheritance. An abstract class means you cannot instantiate it, and all members (fields, methods and constructors) are inherited by subclasses. An interface can only define methods to be implemented.

You should use an abstract class where you have a hierarchical structure that makes sense:

A vehicle can be an abstract class to car and boat, if you only want actual cars and boats to be instantiated. The vehicle can have a maximumSpeed field, which is then inherited. An interface can not define this field.

You should use an interface when you only need the methods. Suppose you are writing a program that interacts with these vehicles ("drive them"), but does not care about the state of these objects, you can define an interface vehicle with a method drive() so that the program can drive all boats and cars, without knowing what they really are.

Finally, a class can implement multiple interfaces. Another example to show the difference, if you can picture your object in real life, think how you would interact with it. Suppose a coffeemaker, it has an on/off buttons. An "abstract coffee machine" does not really make sense. All you need to know is that there is an setOn() and setOff() method.

MarioDS
  • 12,895
  • 15
  • 65
  • 121
0

I personally like to use interfaces when I have to define a characteristic or an ability of an object regardless of what the object is.

In a "real life" example figure out to have 2 classes, Person and Mones (my nick name :D), and 1 interface, IGuitarPlayer. So, Mones inherits from Person, and if Mones has the ability to play the guitar it implements the IGuitarPlayer interface.

Mones
  • 543
  • 1
  • 6
  • 15
0

Since examples from projects depend on the domain, which you have to understand first to be able to understand the example, I will abstract it with a cooking example.

Suppose we want to be able to cook pasta with different sauces: we want to handle pasta independently of its sauce in our source code. A first approach could be that of defining an interface IPasta with a method Cook:

public interface IPasta
{
    void Cook();
}

Our client code can then cook the pasta independently from the implementation of it: tomato sauce, pesto sauce? You name it, we can cook it:

...
IPasta pasta = GetPasta();
pasta.Cook();
...

Thinking about the problem more carefully, though, we find out that cooking pasta is always the same process, excluding the point where we want to prepare the sauce.

This means that we have a base algorithm for pasta that we can implement independently from any sauce: boil the water, prepare a sauce, take the pasta out of the pot and merge it with the sauce.

public abstract class Pasta
{
    public void Cook()
    {
        BoilWater();
        PrepareSauce();
        ...
    }

    protected abstract void PrepareSauce();

    private void BoilWater()
    {
        // Boil some water
    }
}

public class PastaWithPestoSauce
{
    protected override void PrepareSauce()
    {
        // Prepare pesto sauce
    }
}

And our clients will use it like this:

...
Pasta pasta = GetPasta();
pasta.Cook();
...

So we still have an interface, not in C# sense but in the generic sense of a well known public behavior (the public method Cook of the abstract class), but we also managed to spare some code.

Filippo Pensalfini
  • 1,714
  • 12
  • 16