2 From mental model to skeleton code

 

This chapter covers

  • Creating skeletons for task, worker, manager, and scheduler components
  • Identifying the states of a task
  • Using an interface to support different types of schedulers
  • Writing a test program to verify that the code will compile and run

Once I have a mental model for a project, I like to translate that model into skeleton code. I do this quite frequently in my day job. It’s similar to how carpenters frame a house: they define the exterior walls and interior rooms with two-by-fours and add trusses to give the roof a shape. This frame isn’t the finished product, but it marks the boundaries of the structure, allowing others to come along and add details later in the construction.

In the same way, skeleton code provides the general shape and contours of the system I want to build. The final product may not conform exactly to this skeleton code. Bits and pieces may change, new pieces may be added or removed, and that’s okay. This typically allows me to start thinking about the implementation in a concrete way without getting too deep into the weeds just yet.

If we look again at our mental model (figure 2.1), where should we start? You can see immediately that the three most obvious components are the manager, worker, and scheduler. The foundation of each of these components, however, is the task, so let’s start with it.

Figure 2.1 The Cube mental model shows the manager, worker, and scheduler as the major components of the system.
02-01

2.1 The task skeleton

2.2 The worker skeleton

2.3 The manager skeleton

2.4 The scheduler skeleton

2.5 Other skeletons

2.6 Taking our skeletons for a spin

Summary

sitemap