Design Patterns and OO Principles

So I see alot of value in design patterns in software development.  It just intuitively makes sense that as developers we run into similar problems over and over again which have similar solutions or patterns.  For those not familiar with design patterns, I’d suggest Heads-First Design Patterns as a good introduction to them—it has a Java focus, but most of what it talks about is just good object-oriented programming.

However, I have definitely seen the over-use of patterns or the applying of patterns too soon.  This tends to create un-needed flexibility and un-needed loose coupling.  Basically code that won’t change alot is abstracted and made very easy to change.   Clearly work is wasted when this happens.

My take is that often patterns are most useful as a language for communicating a design with other developers.  Sure, sometimes you can identify the need for a design pattern just from requirements rather than from code, but often you guess wrong if you try to do that.

My preferred approach is interative Test-Driven Development.  Along the way I incrementally follow good object-oriented design principles ensuring that I don’t introduce abstraction until I need it.  This means interfaces and abstract classes usually aren’t created until a refactoring step.  Oftentimes while doing this I will find that by virtue of following these OO concepts I have produced a solution that is a design pattern.

 What basic OO principles am I referring to?

1.   The DRY (Don’t Repeat Yourself) Principle 

2.  The Open/Closed Principle

3.  The Dependency Inversion Principle

4.  The Law of Demeter

5.  Favor Composition Over Inheritance

6.  Separation of Concerns

7.  Single Responsibility Principle

This basic approach to development, unit-testing, and design that I use is my interpretation of what the author of Refactoring to Patterns was saying.

I plan on doing a series of additional posts talking about each of the above principles in turn.