Principles and Patterns over Tools and Frameworks

It’s interesting to see what other developers value and/or what topics they are interested in regarding the development of software.  I’m going to start doing some internal presentations and live coding sessions at my company for my fellow consultants.  I’ve got a pretty long list of possible topics, but I offered up 2 topics today that pertain to some of the work I’m doing on my current project.

  1. Examples of how to apply some of the core OO principles (i.e. SRP, OCP) in a real world application and some of the patterns that complement them (i.e. Decorator, Proxy, CoR).
  2. Writing automated web tests using WatiN

Guess which one got the most response?  If you guessed #1, you must be working with folks who are passionate about writing clean, maintainable code, regardless of the technology.  Consider yourself blessed.  As for the rest of us, I’d venture to say #2 would usually be the most “popular” choice among developers.  At least that’s the response I’ve received so far. 

Of course, learning (and showing) a new automated web testing tool is very cool and can be very useful.  I really like the Watix line of web testing frameworks. 

But I see much more value in learning how to adhere to some of “uncle Bob’s” OOD principles (Robert Martin’s site seems to be down, so that link is from Matt Berther) and how patterns can help us along the way.  I see so many bugs that pop up in existing systems that would be so much easier to find and fix if just SRP alone was applied at some level in the code base.  And even more likely, many of those bugs probably wouldn’t have existed in the first place.  My recent experience has proven (once again) that the violation of SRP along with code duplication makes a fertile ground for those little “buggers” to grow.

<SRP tangent>

More and more, when folks ask me why I coded something a certain way, SRP has most likely influenced my decision.  I think SRP is one of the most important principles that developers should be applying when they are implementing new features and/or refactoring an existing code base.  The principle itself is very easy to learn. Code should only do one thing.  This can be applied as high up as the logical layer level all the way down to a single line of code.  How far you take it is answered in the usual “it depends” response.  The difficulty in applying this principle, on the other hand, can vary greatly depending on the code base and the comfort level of the team with other OO principles and the patterns that support them.

</SRP tangent>

Ok, I’m back.  So it sounds like I’m going to be doing the WatiN session first, but you better believe I’m going to be stressing the importance of writing good, clean code even for automated web tests.  They’re not going to get off that easy.  :)

This entry was posted in patterns, refactoring, tools. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

6 Responses to Principles and Patterns over Tools and Frameworks

  1. Good post Joey!

    I find in my experiences that after awhile of doing very forceful SRP, OCP and even DRY that it starts to become second nature. Now I enforce SRP and DRY without even really know that I’m doing it. It’s like as soon as I repeat a single line of code I automatically just refactor it without even really thinking about it.

    Now, I think it is difficult to get to this point and is why so many people write duplicated, monolithic code. There is a LONG period of time that you have to actively force yourself to code this way. It’s a very hard habit to get into, but once you are comfortable, it’s quick and easy.

    I myself always strive to learn more patterns and wrap my head around them. In my entire programming career, using patterns effeciently is hands down the hardest thing to get into the habit of. It still comes difficult for me at times.

    JP said in a screencast that I watched once something to the effect of “In the start you don’t use patterns at all. Then you try to actively make them fit into scenarios that they aren’t necessary. Finally you go back to the original way of not knowing that you are actually using them even though you are using them throughout your code in situations where they are useful.” This rings very true and I always think back to that because it is 100% accurate.

    Anyways, I’m rambling on. This is a good post and really got me thinking. I am considering doing a post about this. thanks!

  2. Interesting that you say SRP is your biggest influence. I have always said OCP personally. However, one thing I have started to notice more and more is that you can’t really do one without the other.

  3. joeyDotNet says:

    Exactly! I like to say SRP is what “enables” OCP to be achieved. :D

  4. Colin Jack says:

    Good post. Hope I’m not being too pedantic but SRP is really about a single reason for change though, which is slightly different to only doing one thing.

  5. @Colin,
    Yeah, perhaps I should have stuck to the standard wording regarding SRP. Although you could say that if a unit of code (be it a method, class, etc.) does NOT “just do one thing”, then it probably will have more than one reason to change, hence breaking SRP. Potaytoes, Potahtoes. :D