Today was nPlus1‘s sixth ever architecture summit. This summit was held in Indianapolis, IN and addressed the SOLID principles. The presenters were Mike Wood and Dan Rigsby.
The SOLID principles were originally defined by Robert Martin as a set of guidelines for writing better code. As with any guidelines, these are not steadfast rules that must always be followed but proper application of these principles can make code more maintainable, flexible, and readable. There is a plethora of information about these principles so rather than going into detail about each of them this article just includes a brief description of each one.
Dependency Inversion Principle (DIP)
a.) Both higher and lower level objects should be based on abstractions.
b.) Abstractions should not depend on details. Details should depend upon abstractions.
One argument against using some of these principles is that following them will result in more code. Some may argue that having more classes and interfaces will ultimately make the system too difficult to understand. The counterpoint to these arguments is that there are no more moving parts in a system with many small pieces than a system with a few large ones. That is, if it’s doing the same thing it should be no more or less difficult to understand. The trade-off to more code is a system that is more accepting of change when (not if) it comes.
This is part of a four part series of notes I took at Indy Code Camp on May 16, 2009. This year’s Code Camp consisted of five tracks each with five sessions. Track topics were SharePoint, SilverLight and WPF, Data Access, MIX highlights, and best practices. These notes are from the sessions I attended.
These notes are in no way intended to replace attending one of these talks if you have the chance.
Care About Your Craft: Adventures in the Art of Software Development
Design by Contract – TDD can actually force us to do this
Avoid programming by coincidence – Understand how and why something works
Don’t be a plumber – Chances are good that someone else has had to save the same technical problem so there might already be a framework that can be used and let you focus on the actual business problem at hand
Justify technology use – Don’t use a technology just because it’s new, use it because it better solves the problem
You Ain’t Gonna Need It (YAGNI)
Don’t waste time building features that might be used
Quality is not an accident – build it into everything starting with requirements