I was just browsing MSDN Magazine (online, i'm trying to save trees LOL) and ran across a new column titled "Patterns in Practice" which looks promising!
"This is the first installment of a new MSDN® Magazine column on software design fundamentals. My marching orders are to discuss design patterns and principles in a manner that isn't bound to a specific tool or lifecycle methodology. In other words, my plan is to talk about the bedrock knowledge that can lead you to better designs in any technology or project. "
For any developer who wants to get better at their job (you DO want to improve don't you??), common patterns and best practice can only help lead you into the 'pit of success'.
Single Responsibility Principle
On the first release of a product our team just completed, one section of code violates the Single Responsibility Principle in a BIG way. We will refactor it during the next release, but it would be great to spend that refactoring time on something else (new features, better perf, more unit tests....).
The Chain of Responsibility Pattern
I actually implemented this pattern in a web service to do querying/filtering in a financial application. e.g. I want to find a particular fund based on criteria which were specified dynamically at runtime (per query by the user). The web service used other services and did not have a direct connection to a SQL Database (so appending where clause conditions wouldn't work). The Chain really worked nice because I could dynamically construct a chain based on the input criteria, then run funds through the chain. As soon as a fund failed a criteria, the code could stop looking...if it got to the end of the chain, it passed! I was really pleased with the implementation and it turned out really clean.
Liskov Substitution Principle (LSP)
If you Google LSP, you'll get a ton of results. The ObjectMentor PDF is an excellent read and Ward Cunningham's Wiki is always top-notch content. I think of LSP as just programming to an abstraction instead of an implementation. e.g. in .NET, when you write a method that returns a collection, do you return ArrayList (an implementation), or do you return one of the abstractions IEnumerable, ICollection, IList?
I'm hoping for great things out of the Patterns in Practice column. It is one thing for a developer to learn a grammar or syntax of a language, but to become a better developer/engineer, applying solid programming principles is essential!
cheers
jk
Subscribe