Chapter 22. Beneficially Relating Elements
What is software design? I’m not a fan of starting with definitions, but we’re hardly starting by now. You’ve seen examples of what I mean by design. You’ve seen how individual decisions chain together to achieve larger goals. You’ve seen the first glimpses of what I mean by “software design is an exercise in human relationships.” Now I can say what I mean by “software design”: beneficially relating elements.
That’s not many words for a big concept. Each word must be carrying substantial weight. Let’s pick them apart and then put them back together.
Elements
Substantial structures have parts.
Organelle → organ → organism.
Atoms → molecules → crystals.
In our world: tokens → expressions → statements → functions → objects/modules → systems.
Elements have boundaries. You know where they start and end.
Elements contain subelements. In our world we like to have homogeneous hierarchies (à la Composite pattern). Natural hierarchies, like previous examples, are not homogeneous. Contained subelements differ from the container. (I’m not sure this point is terribly important, but I like to keep it in mind—someday I’ll write a truly philosophical book about software design as a natural process.)
Relating
Okay, so we have a hierarchy of elements. Those elements exist in relation to each other. One function calls another. The functions are the elements. “Calls/called by” is the relationship. In the natural world, we have relationships like “eats,” ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access