Do you implement an interface for every public class in your domain model? Pros and Cons?
Update: If Repositories interfaces and domain model classes are defined in separate assemblies, wouldn't there be circular dependency if we do not define interfaces for every domain class.
No. Only interface what you need at the time. If you try and think ahead too far soon, your code will become complex and unmaintainable. In a little while, programmers will ditch the interfaces becuase its too difficult to wade through all of them to figure out what is needed. Anything done for the sake of doing will lead to disaster.
No, I don't do it ... Why would you do it, if it is not necessary at the moment being ?
If it should turn out in the future, that it should be necessary (al those 'shoulds' indicate that it is a YAGNI), you can perform an 'extract interface'-refactoring.
(Modern IDE's make it very easy to do so).
I might do it in my next Asp.Net project.
My reason is that we in the current project needed somewhere to store some extra state that were related to the UI. If we had used interfaces for the domain model classes we could right in the user control code subclasses the entity class and replaced with our own class that had that extra state.
I know, it seems kind of dirty. I'd love to have something along the lines of Java's Seam framework with the conversation mechanisms.
You should define interfaces for dependencies between layers, not for every class. So your Service layer should depend on a repository interface, and your presentation layer should depend on a service interface. Past that, there aren't many hard and fast rules, other then use them where it makes sense.
Common sense is a good part of any good design.
It depends on the type of project. If you are writing an API that will be heavily reused (such as a Sharepoint API wrapper), I would lean more towards doing this.
For other projects that will not be reused as heavily, and by default, I would not stress having an interface for every public class. I would instead concentrate on having layers linked using well-designed interfaces.
From the perspective of immutability you might consider putting interfaces on your domain objects:
In most places in your code you'll want your objects to be immutable, so that you can guarantee they won't be changed - in this case you'd work with a data access object of some kind that returns the interface, ensuring that your domain object can't be altered.
If you are writing an admin page of some sort where the user will end up editing the domain object, you'll need to expose setters - your data access object will need to return 'MutableDomainObject' instanaces (either a class or a sub-interface).
Having said that, I agree with the YAGNI philosophy expressed above - if you don't need to guarantee immutability at the moment, it may not be worth investing in this at the moment. It shouldn't be too difficult to factor out interfaces at a later date.
Interfaces can be used to make the code more expressive by giving a name to the role a class is playing in a particular situation. A single class may play more than one role. For example when a Man is interacting with a Cat, the Cat might have a Pet interface, whereas when a Mouse is interacting with a Cat, the Cat might have a Predator interface.
You might find Mock Roles, not Objects a relevant and interesting read.