When should one use interfaces?

2019-01-03 05:53发布

I know that an interface does not have a body just a method definition. But when should I use interfaces? If I provide someone a set of interfaces with no body, why would they feel a need to write the function body? Would they be better off writing their own abstract class with abstract methods in it.

Edited:

I guess the use of Interfaces is more when you are a part of a team. Suppose Team A writes a code for something and they wanted to see if a call to a method. with name getRecords(), is done or not. This will help Team B to write the body of the interface provided to them and Team B has to keep the method name similar so that code of Team A runs.

Just a thought. I might be wrong. I think Interfaces have no use for a single developer.

Edited:

Thanks all for the answers. With what you all have replied, I think Interfaces have more use when you are making something like API?

标签: oop interface
19条回答
beautiful°
2楼-- · 2019-01-03 06:17

Let us assume I have class FoodEstablishment, now I want to do simple CRUD operation, so how do I do it? I define an interface for service, but why?

public interface IFoodEstablishmentService
{
    Task<int> AddAsync(FoodEstablishment oFoodEstablishment);
    FoodEstablishment SelectByFoodEstablishmentId(long id);
    Task<int> UpdateAsync(FoodEstablishment oFoodEstablishment);
    Task<int> DeleteAsync(FoodEstablishment oFoodEstablishment);
}

Then I will implement that contract or interface for that particular service

public class FoodEstablishmentService : IFoodEstablishmentService
{
    public async Task<int> AddAsync(FoodEstablishment oFoodEstablishment)
    {
       // Insert Operation
        return result;
    }

    public FoodEstablishment SelectByFoodEstablishmentId(long id)
    {
        // Select Logic
        return oFoodEstablishment;
    }

    public async Task<int> UpdateAsync(FoodEstablishment oFoodEstablishment)
    {
        // Update Logic
        return result;
    }

    public async Task<int> DeleteAsync(FoodEstablishment oFoodEstablishment)
    {
        // Delete Logic
        return result;
    }

}

So in my main program or where I wish to use Service, I will do

IFoodEstablishmentService oFoodEstablishmentService =  new FoodEstablishmentService();
FoodEstablishment oFoodEstablishment = // Input might be from views;
oFoodEstablishmentService.AddAsync(oFoodEstablishment);

So till now it seems like an extra step, when we could have directly done

FoodEstablishmentService oFoodEstablishmentService =  new FoodEstablishmentService();
FoodEstablishment oFoodEstablishment = // Input might be from views;
oFoodEstablishmentService.AddAsync(oFoodEstablishment);

But wait what if I might need to pass my insert logic through queue rather than directly to server, wait for insert operation to complete and then return result, rather pass on queue and then the queue worker handles those operation, might not be best idea to queue insert but yes definitely good for interface example :-). So now what I do is, create another class FoodEstablishment implementing same contract IFoodEstablishment.

public class FoodEstablishmentQueueService : IFoodEstablishmentService
{
    public async Task<int> AddAsync(FoodEstablishment oFoodEstablishment)
    {
       // Insert Queue Operation
        return result;
    }

    public FoodEstablishment SelectByFoodEstablishmentId(long id)
    {
        // Select Queue Logic
        return oFoodEstablishment;
    }

    public async Task<int> UpdateAsync(FoodEstablishment oFoodEstablishment)
    {
        // Update Queue Logic
        return result;
    }

    public async Task<int> DeleteAsync(FoodEstablishment oFoodEstablishment)
    {
        // Delete Queue Logic
        return result;
    }
}

So now if I want to use the queue version, I would just do

IFoodEstablishmentService oFoodEstablishmentService =  new FoodEstablishmentQueueService();
FoodEstablishment oFoodEstablishment = // Input might be from views;
oFoodEstablishmentService.AddAsync(oFoodEstablishment);

We could do that with the older way using class but that bounds the class instantiation with a particular class which is kind of rigid to extension, now FoodEstablishmentQueueService can do other things too, create another method until the contract is valid so interface is contact for consistency, Imaging one guy doing the normal version and other doing the queue version or someone doing cache version, there might be problems regarding signature unless its pre-specified about the working contract and people don't end up cross checking everything.

Similarly, let consider other simple example of using predefined types like IEnumerable. Suppose I pass a list of FoodEstablishment collection and return custom sorted list

public FoodEstablishment[] SortFoodEstablishment(FoodEstablishment[] list)
{
    foreach(var oFoodEstablishment in list)
    {
    // some logic
    }
    return sortedList;
}

So we will use it this way

FoodEstablishment[] list = new FoodEstablishment[]{ //some values }
var listSorted = oFoodEstablishmentService.SortFoodEstablishment(list);

But what if we send list instead of array

List<FoodEstablishment> list = //some values;
var listSorted = oFoodEstablishmentService.SortFoodEstablishment(list);

We will get error, because its strict implementation using class so instead we use IEnumerable<> which is implemented by List and that basically removes dependency from List to Interface

public IEnumerable<FoodEstablishment> SortFoodEstablishment(IEnumerable<FoodEstablishment> list)
{
    foreach(var oFoodEstablishment in list)
    {
    // some logic
    }
    return sortedList;
}

So usually implementation hugely depends on situation

查看更多
登录 后发表回答