In this go round, we’ll look at the questions related to Design Patterns…
Design Patterns
The question was “When you hear the term ‘Design Patterns’ what comes to mind?”.
A majority of people did get that GOF = Gang of Four = Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides the authors of the book “Design Patterns: Elements of Reusable Object-Oriented Software”, which describes recurring solutions to common problems in software design. Thick and meaty, it’s highly regarded and worth reading if you have the time and inclination. Martin Fowler’s site also has heaps of good info, and you’re not chopping down trees to read it. However you slice it, using patters will make you a better developer, so dig in.
Pattern Adoption
I guess this one has a call to action for someone to setup a community site to document and evolve some geospatial patterns.
If people are interested, I can stand up a wiki at ArcDeveloper.net, but someone else will need to push this forward as I’ve got a full plate.
Model View Pattern Use
“Rate your use of Model View * Patterns” was the question.
For those not familiar with MV* – this refers to a whole family of patterns, related to the Model-View-Controller pattern (Model View Presenter, Supervising Controller, Passive View), and the main intent of these is to separate business logic, user interface and data communications. Use of these patterns are helpful/ critical in enabling robust unit testing. I’ll be writing more about patterns and unit testing in the coming months, but Martin Fowler has a (burly) overview of these patterns. You can also check out the ASP.NET MVC stuff to get the Microsoft take on this, or check out MonoRail, which is part of the Castle Project. And for a change of pace, you could check out Ruby on Rails which is rooted in this pattern.
Inversion of Control & Dependency Injection
Ok, this is really maxing out the pattern / architecture geek factor, but it’s worth asking simply because this is another one of those patterns which enable unit testing.
So, with nearly 75% not knowing what this is… succinctly put, Inversion of Control and Dependency Injection patterns allow you to decouple classes from each other. This allows you to test things independently, which is critical if you want to have good test coverage. I had a series of posts partially written about this while at Sanborn, but I did not get them all polished off before leaving, and since I don’t have access to the source code anymore, I’ll need to look for opportunities to show some of this. For what it’s worth, the ArcDeveloper.net projects both use the Castle Windsor IOC container.
Ok, I’ll leave it here for now. Next time I’ll finish it up with a look at Build Processes, Unit Testing, Refactoring, API Documentation and some choice comments.
