Part 6: Summing Up

And at last I come to the end of this marathon! Maybe you have stuck with me - more likely not :D But in either case I hope I will have sharpened up your appreciation of design-by-abstraction. I reckon it is the dominant form of design but rarely explained in any depth. With luck this article will have done it some justice.

In comparing the two design strategies, a couple of caveats are required. Firstly, picking on Uncle Bob Martin pedagogical example of the word wrap problem is not intended to make a serious academic point. Bob Martin is evidently a skillful practitioner and a masterful communicator. I chose the example because he supplied a detailed description that could reasonably read as incremental design, specifically design-by-induction, that I thought could be used to highlight the pros and cons of that design strategy.

Secondly, my maintainability analysis is (necessarily) highly subjective and although I have tried to keep an objective tone throughout, it should probably be read as illustrative of the pros and cons that I foresee rather than anything more meaningful.

The comparison illustrates that design-by-induction, with serial local modifications, does not push us towards globally efficient or elegant solutions. Nor does it create independent plans that can be put of for discussion and review. So design-by-induction probably needs to be coupled with design-by-abstraction to provide a roadmap for design choices. On the other hand, it does not need a great deal of prior knowledge and by sticking with executable prototypes allows the designer to converse with the lay customer in domain terms.

By contrast design-by-abstraction leans very heavily on prior, formal knowledge of previously successful software designs, inaccessible to the layman. By parameterising our solutions to these design problems we can turn these solutions into reusable components or (in less modern jargon) libraries. Parameterisation is software engineering's best attempt to directly support generalisation and specialisation.

The reuse of well-studied successes means that design-by-abstraction is cognitively efficient and develops very good ("sweet spot") initial solutions that are accurate, efficient and maintainable.

This article emphasised the key role that representation shifts play in design-by-abstraction, enabling the designer to quickly make viable but distant matches between the problem and known design solutions. This is critical to the strategy because the failure to find a match blocks this strategy completely.

Representation shifts are a form of problem decomposition and are typically implemented in the final solution by wrapper classes. In object oriented programming languages this can create a confusing proliferation of classes which have similar motivations but different presentations.

Design-by-abstraction has strong and deep connections with other design concepts such as software reusability and top-down/bottom-up design. Software reusability refers to the attempt to implement parameterised design solutions, which would make design-by-abstraction even more powerful. Top-down design refers to design-by-decomposition in which we focus on the "plumbing" between undefined solution islands. Bottom-up design refers to design-by-composition where we sharply define solution "islands" and defer the plumbing until later.

Design-by-abstraction looks like top-down design when applied to a solution "island" because the representational shifts take on the role of the "plumbing". When applied to a large-scale design, design-by-abstraction tends to look like bottom-up design because of the search for identifiable solutions. In my view, "top-down" and "bottom-up" are not design strategies but emergent properties of design strategies.

Stephen Leach, Bristol, April 2011


Back to Part 5 - Up to Contents