Patterns in Practice - The Open Closed Principle

When I started working as a programmer, I was fascinated with design patterns. Coding with patterns made my code looks elegant. When documenting, you just needed to point out what patterns you used and things would be very self-explanatory. But latter, I found, few recruiters here would care what design patterns I had applied in my software. Rather, they would be more interested in how broad and how deep I know about certain softwares, like databases, servers, operating systems, etc. To me, that implies product knowledge, not design knowledge, is more valuable to them. Given such a job market and I only have 24 hours a day, how much time should I invest in product knowledge and design knowledge?

So when I find an article on design patterns, I keep wondering if I should spend time on it. It's true that applying design patterns in my program would make it more flexible, but I haven't been rewarded financially for knowing these. To the contrary, based on what I have observed, knowing more about database or network infrastructure would be appreciated and possibly rewarded with a higher salary, even if I am a programmer, not a DBA or network administrator. Bosses and users don't care how I design software as long as it works as requested and no one reads documents. Having complained about that, still, I am going to summarize 2 MSDN articles on design patterns I have read recently. Why? For me, the temptation of writing elegant codes is difficult to resist.

Patterns in Practice - The Open Closed Principle

If you want your code easy to extend and robust to changes, consider applying the Open Closed Principle in your program. According to the author, it means that an application is structured in such a way that it's easy to enhance with minimal changes to existing code. Sounds appealing, but how? There are several patterns you can apply.

First, the author suggested that we should follow Single Responsibility Principle. That is, each class should be designed with some 'specialized' responsibility, for example, dividing business logic and data access responsibilities into separate classes. Then, a change in data access would not affect business logic classes.

Second, if there is lots of conditional logic in your program, consider using Chain of Responsibility Pattern. Then, when more conditions need to be handled, you only need to add additional logic in separate classes with minimal changes to exiting code.

Third, if you keep changing the interface of some class because you need to access/manipulate its states/variables, consider Double Dispath Pattern.

Fourth, if you access a class through its interface or abstract classes, then you follow Liskov Substitution Principle. The benefit is you can easily swap out the class with other implementation, and results in minimal changes to existing code.

Design Patterns - Model View Presenter

According to the article, the MVP architecture looks like the graph on the right. Presentation separates UI from the service. UI depends on Presentation and knows nothing about Service. Presentation depends on Service and know nothings about how data are retrieved and persisted. The pattern makes your service and presentation reusable.

This is also a good article on how to write an ASP.NET application in a test-driven way. The author showed us that by applying MVP pattern and NMock2 framework, your web applications are testable.

Recently, I start using CAB to develop winform applications. This article really helps to brush up my knowledge about MVP pattern, as the pattern is used heavily in CAB.

Further reading: Everything You Wanted To Know About MVC and MVP But Were Afraid To Ask