Difference between Interface and Abstract class in terms of Decoupling?

Question

As we know there are basically two important difference between Interface and Abstract class.

1. We can have function definitions in abstract class. This is advantageous when we want to add a function in a class without need to track down it's all implementations.

2. We can have multiple interface implementation.

I just came to know that we can differentiate between them in terms of Decoupling?

Your comments...

Also if you can you provide a very basic link that explains the Decoupling for Interface and Abstract class ?

We normally use Business Logic Layer, Data Access Layer(contains abstract functions) and DataAccess.SqlServer Layer. Right? Despite of the fact that we aware of the Business needs, why are we creating Data Access Layer(contains abstract functions), Why can't Business Logic layer directly access DataAccess.SqlServer Layer?

Answer 1

Decoupling

In programming and design, this is generally the act of making code which is re-usable with as few dependencies as possible.

Factory Pattern In This Context

When using the Factory Pattern, you have a centralized factory which can create objects without necessarily defining them itself. That would be up to the object's definition.

Abstract and Interface

Interface

Defining an interface is best practice, as it allows for a light weight type to be used for inference, and also provides a blueprint which all inheriting classes must abide by. For example, IDisposable must implement the Dispose method. Note that this is decoupled from the interface, as each class inheriting IDisposable will define its own function of the Dispose method.

Abstract

Abstract is similar to interface in that it is used for inheritance and inference, but it contains definitions which all classes will inherit. Something to the extent of every automobile will have an engine so a good abstract class for automobile could include a predefined set of methods for an engine.

Edit

Explanation

Here you will see a simple example of inheritance using an interface and an abstract class. The decoupling occurs when the interface is inherited by an abstract class and then it's methods are customized. This allows for a class to inherit the abstract class and still have the same type as the interface. The advantage is that the class inheriting the abstract class can be used when the expected type is the original interface.

Decoupling

That advantage allows for any implementation to be used which conforms to the expected interface. As such, many different overloads can be written and passed in. Here is an example of one.

Example

Interface Definition

public interface IReady
{
    bool ComputeReadiness();
}

Inheritance

public abstract class WidgetExample : IReady
{
    public int WidgetCount { get; set; }
    public int WidgetTarget { get; set; }
    public bool WidgetsReady { get; set; }

    public WidgetExample()
    {
        WidgetCount = 3;
        WidgetTarget = 45;
    }

    public bool ComputeReadiness()
    {
        if (WidgetCount < WidgetTarget)
        {
            WidgetsReady = false;
        }
        return WidgetsReady;
    }
}


public class Foo : WidgetExample
{
    public Foo()
    {
        this.WidgetTarget = 2;
    }
}

public class Bar : IReady
{
    public bool ComputeReadiness()
    {
        return true;
    }
}

Decoupling

public class UsesIReady
{
    public bool Start { get; set; }
    public List<string> WidgetNames { get; set; }

    //Here is the decoupling. Note that any object passed
    //in with type IReady will be accepted in this method
    public void BeginWork(IReady readiness)
    {
        if (readiness.ComputeReadiness())
        {
            Start = true;
            Work();
        }
    }

    private void Work()
    {
        foreach( var name in WidgetNames )
        {
            //todo: build name
        }
    }
}

Polymorphism

public class Main
{
    public Main()
    {
        //Notice that either one of these implementations 
        //is accepted by BeginWork

        //Foo uses the abstract class
        IReady example = new Foo();
        UsesIReady workExample = new UsesIReady();
        workExample.BeginWork(example);

        //Bar uses the interface
        IReady sample = new Bar();
        UsesIReady workSample = new UsesIReady();
        workSample.BeginWork(sample);
    }
}

Answer 2

I've been looking through the answers, and they all seem a little complicated for the question. So here is my (hopefully) simpler answer.

• Interface should be used when none of the implementation details are available to the current scope of the code.
• Abstracts should be used when some of the implementation details are available to you
• And, for completeness, when all of the implementation details are available you should be using classes.

In terms of decoupling, while I somewhat agree with Shelakel, for the purposes of this question, and stating fully decoupled design practices, I would suggest the following:

• Always use Interfaces to define external behaviour.
• When you have some of the implementation details available, use abstract classes to define them, but implement the interfaces on the abstract classes, and inherit from those classes in turn.

This ensures that later if you need to change some obscure implementation detail in a new implementation you are able to do so without modifying the existing abstract class, and are also able to group different implementation types into different abstract classes.

EDIT: I forgot to include the link :) http://www.codeproject.com/Articles/11155/Abstract-Class-versus-Interface