Posts Tagged ‘Barbara Liskov’

Layering, Balancing, And The Number Seven

January 27, 2014 Leave a comment

Having recently watched a newer incarnation of Barbara Liskov‘s terrific Turing award acceptance speech on, “The Power Of Abstraction“, I started doodling on my visio canvas to see where it would take me. Somehow, I wanted to explore how the use of abstraction imbues power to its wielders.

The figure below attempts to represent 3 different software designs that can result from the analysis of a given set of requirements (how the requirements came to be “given” in the first place is a whole ‘nother issue).

On the left, we have a seven class solution candidate (C1….. C7 ) organized as three layers of abstraction. On the right, we have a three class flat solution (FC1, FC2, FC3) that implements the same functionality (e.g. FC1 encapsulates the functionality of C1 + C4 + C7). For dramatic contrast, we have a fugly, single-class, monolith in the middle with all the solution functionality entombed within the MC1 class sarcophagus.

Flat Vs Tiered

So, what advantage, if any, does the three tier, abstract design give stakeholders over the two, flat, down-to-earth designs? Depending on the requirements specifics, it may offer up no advantage and might actually be the worst candidate in terms of code-ability, understandability, and maintainability. There are more “parts” and more inter-part interfaces. It may be overkill to transform the requirements into 3 layers of abstraction before (or during?) coding.

However, as a system to be coded gets larger and more complex, the intelligent use of abstract vertical layering and horizontally balancing can speed up system development and decrease maintenance costs via increased readability and understandability from multiple viewing angles. For large systems, conceptual “chunking“, both vertically in the form of layering and horizontally in the form of balancing is a winning strategy; especially when coupled with Miller’s magic number 7 (no more than 7 +/- 2 abstract elements within a given layer and no more than 7 +/- 2 abstract layers in the stack). Relatively speaking, the smaller, bounded parts can be doled out to team members more easily and integration will be less painful.

Note that doing some just-enough “pre-planning” in terms of layering/balancing the system’s structure/behavior seems to fly in the face of TDD – where you sprinkle a bunch of user stories from the backlog onto a group of programmers and have them start writing tests so that the design can miraculously emerge. But, as the saying goes: “whatever floats your boat“.



April 12, 2013 Leave a comment

Objects of subtypes should behave like those of supertypes if used via supertype methods. – Barbara Liskov

Having learned the “Liskov Substitution Principle” as an object-oriented design aid many years ago, I was delighted to discover this video of Ms. Liskov accepting her Turing award in 2009: Barbara Liskov Lecture Video – A.M. Turing Award Winner.

If you don’t have the time to watch the hour long lecture by this extraordinary lady, but you’re curious to know more about Ms. Liskov, here are my notes:

  • She “accidentally” entered programming.
  • She created the CLU and ARGUS programming languages.
  • Let’s face it, in systems we write programs in C & C++ because efficiency really matters“.
  • She was surprised that her paper on sub-types took off and her name became acronym-ized: “LSP”.
  • She’s not a fan of DSLs or AOP because “readability is more important than writeability“.
  • Abstract types, via encapsulation, were a boon to “reasoning about correctness“: understanding where you are in the code and how you got there.
  • While creating CLU, she didn’t care about inheritance because it breaks encapsulation and makes “reasoning about correctness” more difficult. She simply used composition and called the methods of child objects via delegation.
  • Since she is a practitioner, she stayed away from theoretical work, e.g. polymorphic lambda calculus.



%d bloggers like this: