"The only way you can coast is downhill"
- anonymous
1.0 Motivation
As you look over the specifications for TextFinder and
its parts: TextSearch, DirNav,
CmdlnParser, and Executive & Display,
you may be puzzled by some of its structure like DirEvent and SearchEvent. Here, we explore
design structure alternatives and think about how they apply to TextFinder.
Look back at the TextFinder Implementation structure. In these
Bites we will be exploring why this structure makes sense for this project.
TextFinder is unique in that it is relatively small, has understandable operations, but still presents
a number of opportunities to explore design variations. One particularly relevant feature is its
display of output, as shown in Figure 1. That displays a tiny bit of implementation and a good look
at its output, as provided by my solution for the TextFinder BuildOn project.
For each of the parts: TextSearch, DirNav, CmdlnParser, and Executive & Display, there is code
in the Rust BuildOn repository,
with brief discussions in the BuildOn Repo Doc.
Figure 1. TextFinder Execution
Large software systems may be composed of hundreds of thousands, even millions, of lines of source code. Much more than any
developer can understand completely. In order to use and maintain these systems a developer needs to have some way of
understanding their properties and expected operations.
Most often we factor systems into components that are small enough to be well understood and visualize the complete system
as couplings of these smaller components. Often the components themselves may be decomposed into fundamental parts.
An abstraction consists of a set of components with specified responsibilities and usually one or more diagrams That
illustrate ownership and usage relationships between components. That's what we will see here.
One of the things that drives the design structure of TextFinder is the output as shown in Figure 1. Depending
on where we start in a directory tree, the output may be very large and may take a significant amount of time
to generate. If we do all the processing before displaying any output the user may have a very unsatisfying
experience. Is the program still running? What kinds of output am I going to get? I'm bored. Please
amuse me.
This leads us to a design structure that provides users with continuous output as the search process
unfolds. You can see how that works by cloning and building
Rust Textfinder.
We will step through five alternatives for a simpler program, line counter, with a structure that
displays output continuously.
We chose to use the line count process because it is small enough that we can easily see how
the structures come to gether and operate. Exactly the same ideas apply to TextFinder.
2. Application Structure
The design alternatives summarized in the Design Bites repository documentation
are explored with discussion and code in the following Bites.
They are progressively more flexible, eventually resulting in reusable components, but also increasingly
complex. Where you settle in these alternatives is determined by design context. Is this a
one-of-a-kind project that you want to finish quickly or is it
heading for production code that will be maintained by more than one developer?