In this second part of the Composed Method pattern, I talk about the Single Level of Abstraction Principle, or SLAP.
The Single Level of Abstraction Principle
Last time I talked about the Composed Method pattern; that is, writing small methods to enable ease of reading and understanding, and to help with emergent design.
The second rule for the Composed Method pattern was this: Keep all of the operations in a method at the same level of abstraction. Last time I glossed over this rule, but what does it mean?
In essence it's an aid to understanding the code in the method. If you mix low-level implementation with higher-level code, your brain has a more difficult time of reading and understanding it. You have to mentally switch from the low-level nuts and bolts to those higher-level concepts that abstract out other low-level implementations.
In essence, we are mixing in the "how" something is coded — the low-level code — with the "what" it does — the higher level concepts. It is far better for our understanding of what's going on to extract the low level code to a separate, very small method, name it well, and then use that in the original method, rather than keep the low level code mixed in.
This is known as the Single Level of Abstraction Principle, or SLAP.
Here's an example of a violation of SLAP from my own code.
public string Render() {
StringBuilder sb = new StringBuilder();
sb.AppendLine("<table id='jmbCalendar'>");
AddCalendarCaption(sb);
AddCalendarHeader(sb);
AddCalendarFooter(sb);
AddCalendarBody(sb);
sb.AppendLine("</table>");
return sb.ToString();
}
We're writing an HTML table that looks like a calendar. We create a new stringbuilder, add a line to it to start off the HTML table, and then we have a set of statements that build up the rest of the calendar by adding a caption, a header, a footer, the body. Finally we add the end tag for the table. Notice how the low-level code to add the begin and end tags clashes with the statements that build the content of the calendar: the levels of abstraction are different. You have to mentally switch from understanding how an HTML table is encoded to rather more abstract concepts of adding the various parts of the calendar. I should extract out a couple of one-line methods, called say StartCalendar and EndCalendar, and use those to comply to SLAP.
Using this principle, alongside our application of the Composed Method pattern, means that our code becomes even more legible, testable, and understandable. Our program correspondingly improves in quality and reliability.
So, why don't you apply SLAP to your code, along with Composed Method.
(You can see the video here.)
The other thing to note is that once you have applied SLAP, you’ll suddenly recognize other opportunities for refactoring and other classes that emerge from what you’ve already written. For example, once I apply SLAP to my code, it’ll turn out that I’m passing a stringbuilder instance to six methods. Why not create another class that has the stringbuilder as a private field? That would in fact hide the creation of the stringbuilder, which is pretty low-lever, you must admit. And so on.
The point is: without the application of SLAP, I would be constrained as to what prospects for cleaning up my code I could identify. With SLAP, I’m thinking at a higher level and can see refactorings and emergent design at that level.