CodeDotNet

Software Design Patterns And Architecture

This is the second response to a LinkedIn Software Architecture group question, Develop classes using Abstractions or always program to an interface:

Are you seeing interfaces, but only one instance of the class, or only one class requiring the class implementing the interface? That sounds unnecessary. If you have multiple classes implementing the same interface, that sounds more appropriate. Interfaces are to some degree contracts, and they are there to force conformity to a minimum standard while allowing flexibility for the concrete implementations. Inheritance can provide the same restriction, but it is often too restrictive, leading to suggestions to prefer composition.

Abstraction is almost always better than concreteness. When I think of bad code, I imagine code that is coded for a specific instance and is inflexible. Granted, there are times, particularly for one-off scripting, where literalness is the correct choice, but when designing a system, particularly one that is expected to grow and change, abstraction is the better choice, the only issue is the quality of the abstractions. In VS, it is possible to extract an interface from a class, but this only makes concrete decisions seem abstract, when in fact, the concrete class could simply be the result of a series of decisions based on existing issues, with little abstraction involved.

Software Design Patterns And Architecture

This is a response to a LinkedIn Software Architecture group question, Develop classes using Abstractions or always program to an interface:

Personally, I find that starting with abstract ideas/plans are usually best for long-term development. When I have been driven to write overly concrete implementations, I have hated the resulting project's limited flexibility.

There might be several reasons for what you are seeing, some of which you have already mentioned:

• Foresight, in that someone was expecting changes or additions that are not currently evident
• Some technologies expect interfaces, e.g., MVP, WCF services, IOC...
• In reference to MVC: "...models strongly typed, minimized the code needed for the model since it's just an interface but also keeps anyone from accidentally pushing logic down into the model..."
• With the code analysis built into premium versions of Visual Studio give points for abstraction. I typically try to attain a high maintainability score, and abstraction, and interfaces provide that
• The person who started the design was enamored with something they had just read so created everything with interfaces. Subsequent developers maintained the 'pattern'
• The interfaces, depending on the IDE, might be afterthoughts, such that someone created a concrete implementation, then later right-clicked and generated an interface from it. Visual Studio (VS) lets you do this.