You are here

Bootstrapping Along

15 January, 2016 - 09:02
Available under Creative Commons-ShareAlike 4.0 International License. Download for free at

Let's take a look back at what we've done with a list so far:

  1. Created an invariant list interface with two variant concrete subclasses (Composite pattern) where any algorithms on the list where implemented as methods of the interface and subclasses (Interpreter pattern)
  2. Extracted the variant algorithms as visitors leaving behind an invariant "execute" method. Accessor methods for first and rest installed. The entire list structure now becomes invariant.
  3. Abstracted the creation of a list into an invariant factory interface with variant concrete subclass factories.
  4. Separated the list framework into an invariant hierarchy of interfaces and a variant implementation which was hidden inside of a variant factory class.

Is there something systematic going on here?

Notice that at every stage in our development of our current list framework, we have applied the same abstraction principles to the then current system to advance it to the next stage. Specifically, we have identified and separated the variant and invariant pieces of the system and defined abstract representations whenever needed.

This really tells us about some general characteristics of software development:

  • Software development is an iterative process. You never get the right answer the first time and you have to slowly "evolve" your code closer and closer to what you want.
  • Every time you change your code you learn something more and/or new about your system and/or problem. This is because every new formulation of your solution represents a new way, a new view as it were, on the problem and this new view highlights aspects you hadn't considered before.
  • The revision process is driven along by a repetitive application of the abstract decomposition techniques such as separating the variant and invariant.

Are we done with our list refinements? Will we ever be "done"? What do the above characteristics say about the way we should approach software development?

Also, now that we have managed to abstract structure, behavior and construction, is there anything left to abstract? Or is there one more piece to our abstraction puzzle (at least)?