Geek Answers Handbook

Do you define an interface for each public class in your domain model? Pros and cons?

Do you implement an interface for each open class in your domain model? Advantages and disadvantages?

Update. If the repository interfaces and domain model classes are defined in separate assemblies, will there be a cyclic dependency if we do not define interfaces for each domain class.

+4
source share
9 answers

No.

Cons.

  • Noise code.
  • More for the record.
  • YAGNI.
+13
source

You should define interfaces for dependencies between layers, and not for each class. Thus, your service level should depend on the repository interface, and your presentation level should depend on the service interface. In the past, there are not many hard rules, and then use them where it makes sense.

Common sense is a good part of any good design.

+7
source

Interfaces can be used to make code more expressive by specifying the name of the role the class plays in a particular situation. One class can play more than one role. For example, when a person interacts with Cat, Cat may have a Pet interface, while when a mouse interacts with Cat, Cat may have a Predator interface.

You can find Mock Roles, not objects that are relevant and interesting.

+2
source

No. Only the interface that you need at that time. If you try to think too far, your code will become complex and overwhelming. After some time, programmers will interfere with the interfaces, because it is too difficult to get through everything to find out what is needed. Everything that is done for the sake of business will lead to disaster.

0
source

In my opinion, this is too much. Only my 2 cents ...

0
source

No, I do not do this ... Why do you need to do this if it is not necessary at the moment?

If in the future it should turn out that it is necessary (all of these “indicate” that it is YAGNI), you can perform an “extract interface” - refactoring.
(The modern IDE makes this very easy).

0
source

I can do this in my next Asp.Net project.

My reason is that in the current project we have to store some additional state associated with the user interface somewhere. If we used interfaces for the classes of the domain model, we could directly subclass the entity class directly in the user management subclass and replace our own class that had this additional state.

I know it seems dirty. I would like to have something consistent with the Java Seam framework with conversation mechanisms.

0
source

It depends on the type of project. If you are writing an API that will be heavily reused (for example, the Sharepoint API wrapper), I would be more inclined towards this.

For other projects that will not be reused so much, and by default, I would not emphasize the presence of an interface for each public class. Instead, I will focus on having layers connected using well-designed interfaces.

0
source

In terms of immutability, you can consider installing interfaces on your domain objects:

In most places in your code, you want your objects to be immutable so that you can guarantee that they will not be changed - in this case you will work with a data access object that returns an interface, ensuring that your domain object cannot be changed.

If you write some kind of administrative page in which the user finishes editing the domain object, you will need to parse the setters - your data access object will have to return MutableDomainObject objects (either a class or a sub-interface).

Having said that, I agree with the YAGNI philosophy outlined above - if you do not need to guarantee invariability at the moment, at the moment you should not invest in it. It should not be too difficult to decompose interfaces at a later date.

0
source

More articles:


All Articles