Code || VBA, .NET, SQL

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.