Interface and abstract class real time example in project.

First, An abstract class with all abstract methods is the same as an interface. An interface has only abstract methods by default, but an abstract class can have both abstract as well as non-abstract methods.

Now, come to the real-world use cases

1. Standardization of vocabulary

suppose, there are 5 developers in a team and they can interchange their work, which means anyone can start working on any given module, and all 5 of you can work on the same module.

Now, the problem is, we all have our own style of naming a method, for example, I use getEmployee(), my friend use GetEmployee(), while the other developer use ReadEmployee(). This will create a mess, so we declare an interface, that forces developers to not use their own naming conventions rather implement the methods which are present in the interface.

public Interface IEmployeeBL
{
IEnumerable GetEmployees();
}

2. To Achieve a high level of abstraction

we never point to the concrete implementation of a class, we always use interface, and thus the real implementation is always hidden from the UI (controller/ code-behind)

public HomeController: Controller
{
private IEmployee _empBl;
public HomeController(IEmployeeBL empbl)
{
_empBl=empbl;
}
}

3. My favorite and real use case (Loose coupling between layers)

see, these are 2 implementations of the DataAccess layer, in the first implementation I have used EF, and on the other, I have used Dapper.

public Interface IDAL
{
void Save(Employee emp);
Employee GetById(int Id);
}
public Class EFDAL: IDAL
{
MyDbContext _db= new MyDBContext();
public void Save(Employee emp)
{
db.Employees.Save(emp);
db.SaveChanges();
}
......... other methods implementations.....
}
public Class EFDAL: IDAL
{
public void Save(Employee emp)
{
string sql = "Employee_Insert";
using (var connection = My.ConnectionFactory())
{
connection.Execute(sql,
new {Name= emp.Name, Salary= emp.Salary},
commandType: CommandType.StoredProcedure);
}
}
......... other methods implementations.....
}

now, I can easily switch between implementations without having any tight dependency on any of the implementations using Interface IDAL.

so, the use cases are infinite, but at the center, there is just one thing, it is polymorphism, Polymorphism is the King, I usually say there is no OOP without polymorphism, at run time we change the behavior using interface because polymorphism allows us to do that.

public Class EmployeeBL
{
private IDAL _dal;
public EmployeeBL(IDAL dal)
{
_dal=dal;
}
public void SaveEmployee(Employee emp)
{
_dal.Save(emp);
}
}

2 Replies

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

Sachin Singh5y ago
Accepted answer
First, An abstract class with all abstract methods is the same as an interface. An interface has only abstract methods by default, but an abstract class can have both abstract as well as non-abstract methods.

Now, come to the real-world use cases
1. Standardization of vocabulary
suppose, there are 5 developers in a team and they can interchange their work, which means anyone can start working on any given module, and all 5 of you can work on the same module.
Now, the problem is, we all have our own style of naming a method, for example, I use getEmployee(), my friend use GetEmployee(), while the other developer use ReadEmployee(). This will create a mess, so we declare an interface, that forces developers to not use their own naming conventions rather implement the methods which are present in the interface.
public Interface IEmployeeBL
{
IEnumerable GetEmployees();
}
2. To Achieve a high level of abstraction
we never point to the concrete implementation of a class, we always use interface, and thus the real implementation is always hidden from the UI (controller/ code-behind)
public HomeController: Controller
{

private IEmployee _empBl;
public HomeController(IEmployeeBL empbl)
{
_empBl=empbl;
}

}
3. My favorite and real use case (Loose coupling between layers)
see, these are 2 implementations of the DataAccess layer, in the first implementation I have used EF, and on the other, I have used Dapper.
public Interface IDAL
{
void Save(Employee emp);
Employee GetById(int Id);

}

public Class EFDAL: IDAL
{
MyDbContext _db= new MyDBContext();
public void Save(Employee emp)
{
db.Employees.Save(emp);
db.SaveChanges();
}
......... other methods implementations.....

}

public Class EFDAL: IDAL
{

public void Save(Employee emp)
{
string sql = "Employee_Insert";

using (var connection = My.ConnectionFactory())
{
    connection.Execute(sql,
        new {Name= emp.Name, Salary= emp.Salary},
        commandType: CommandType.StoredProcedure);


}
}
......... other methods implementations.....

}
now, I can easily switch between implementations without having any tight dependency on any of the implementations using Interface IDAL.
so, the use cases are infinite, but at the center, there is just one thing, it is polymorphism, Polymorphism is the King, I usually say there is no OOP without polymorphism, at run time we change the behavior using interface because polymorphism allows us to do that.
public Class EmployeeBL
{
private IDAL _dal;
public EmployeeBL(IDAL dal)
{
_dal=dal;
}

public void SaveEmployee(Employee emp)
{
_dal.Save(emp);
}
}
mayur pandit5y ago
Thank's Sachin