DevExpress Newsletter 40: Message from the CTO

I’m in the DevExpress offices in Glendale this week, and it’s back to the videos again since I can just walk into our studio and be recorded. To celebrate I thought I’d go over the SOLID object-oriented design/programming principles over this and the next four newsletters; principles first set out in their current form by Robert Martin.

The S in SOLID - Single Responsibility Principle

It seems amazing to me that I've been developing with object-oriented design and programming for some twenty-odd years. I well remember when I started doing so and the only worries I seemed to have were in getting the syntax right and wondering whether a method had to be virtual or not.

Over the two decades since then we've all become rather better at writing object-oriented code, not just me. I thought I'd discuss a well-recognized set of principles that have helped many people become better object-oriented programmers: the SOLID principles, where SOLID is an acronym with each of the five letters denoting a separate principle. These principles were first described in their current form by Robert Martin, also known as Uncle Bob.

Today we'll look at the S in SOLID: the Single Responsibility Principle.

This perhaps is the most difficult principle in the SOLID collection to grasp. Here's how Uncle Bob puts it: There should never be more than one reason for a class to change.

Let's take a look at an example from my own code.

  class TreePainter {
      void DrawRoot(...);
      void DrawChildren(...);
      void DrawRightSubTree(...);
      void DrawLeftSubTree(...);
      void PaintNode(...);
      void PaintEdge(...);
      void PaintData(...);
  }  

A while back I was investigating red-black trees and I wrote a tree painter class to render a simple binary tree to the screen. It had methods that recursively navigated the tree being drawn (these are called Draw such-and-such) and it had methods that drew the edges and the nodes themselves (these are called Paint such-and-such). In my original code these were all named Draw such-and-such, just to make the distinction even harder to spot.

Very nice it was too, until the day when I wanted to use the same code for drawing a tree using a different graphics library. Suddenly the mix of tree navigation and node/edge drawing became a liability: the tree navigation code didn't need to change but the drawing code did.

In essence, my tree painter class did not conform the the Single Responsibility Principle. It did two entirely separate things: navigation and painting. When the latter area of responsibility changed, the whole class was compromised, despite the fact the navigation was the same.

The solution was to break out the node/edge painting from the tree navigation and make them separate classes. In fact, this separation of responsibilities made it easier when I modified the node painting logic to work with red-black tree nodes, which was yet another vector of change.

All is not a bed of roses though. The problem with the Single Responsibility Principle is that you may make your code more complex and decomposed than you ordinarily would, all for some future eventuality that may never come. If, for example, I'd never needed to use some other graphics context or needed to render red-black trees, my original code would still be working just fine today.

You can watch the video here.

With all this principle (and the next four to be published in subsequent newsletters) I’ve found it pretty hard to find examples in my own code to illustrate the “before” picture. I think that, once you get used to the SOLID principles, you automatically (unconsciously?) switch into using them all the time and so your own code will be better designed and decoupled. This example I showed here was essentially an early cut at the code: I decoupled it fairly early on as you’ll see if you read the articles I wrote.

If you want to read the series of articles I wrote on red-black trees, start here.

For Uncle Bob’s chapter on the Single Responsibility Principle, click here for the PDF.

Free DevExpress Products - Get Your Copy Today