Should objects implement interfaces?

Question

I personally do not have objects that implement interfaces. For the Task class, I would not have ITask , which had only the same properties as on it.

I saw how this was done several times, so I wonder where this advice came from and what benefits you will get from it.

If you use ORM, the argument that says “I can change access to data” does not matter, so why do this?

UPDATE:
A good point was made in the comments on INotifyPropertyChanged . It was not my business, but I am talking about something like this:

 public interface ITask { int Id { get; set; } string Description { get; set; } } public class Task : ITask { public int Id { get; set; } public string Description { get; set; } } 

Answer 1

I went this way once (interfaces for value objects). It was a royal back pain, I recommended against it. Common arguments for this are:

Tantalizing: These are objects of value. Nothing to taunt. In addition, the mockery ends in more pain than writing a builder (in Java) or using named arguments in C #.

Readonly Views: I have to admit that I still prefer to do something immutable by default, only making it mutable if absolutely necessary.

Hidden functionality: Actually, the area has covered this for me.

Answer 2

The main advantage of this is that it is a way to expose your entity to read-only (until your interface exposes setters, of course).

Answer 3

We do quite a bit of unit testing and often want to mock that we don't test. Although I don’t like it, we ended up using interfaces everywhere because it makes it much easier to mock things.

In theory, most of the mocking frameworks can also mock normal classes, but in practice this has caused us problems because we sometimes do smart things with reflection, and the type of mocking class is not the same as the original. So:

 var myTask = MyIoCProvider.Get<Task>(); var taskType = typeof(myTask); 

It was unpredictable. Pay attention to:

 var myTask = MyIoCProvider.Get<ITask>(); var taskType = typeof(myTask); 

Gives you as a taskType, which is definitely derived from ITask.

Thus, the interfaces just give us a way to make our system more prototyped.

Answer 4

If you thought in terms of using DomainEvents, than data structures such as a task you really need to implement an interface

 public interface IDomainEvent { Guid EventId { get; } Guid TriggeredByEvent { get; } DateTime Created { get; } } public class OrderCancelledEvent : IDomainEvent { Guid EventId { get; set; } Guid TriggeredByEvent { get; set; } DateTime Created { get; set; } // And now for the specific bit int OrderId { get; set; } } 

Or similarly, if you have a common level of data access that may be required for the standard IEntity base class, but I would not have an interface for each type if it is just a data structure, as you describe in your post.

When you process domain objects that really expose behavior, you might want to have an interface for unit testing.