General Structure

J. W. Rider

October 2004

Coming to grips with the concept of structure has proved tedious for many a beginning programmer. It seems beginners likes to hit their heads against a brick wall of structure. It must feel good when they stop, but it doesn’t really help them understand what structure is all about. For starters, we have to undo a lot of the fuzziness that we have learned to associate with the term structure outside of the programming environment.

Structure is not a “pattern,” nor is it an “order,” nor even a “plan.” We do need patterns and orders and plans with software engineering, but not one of these require structuring our source code. All of our software had patterns, orders and plans long before the concept of structured programming (SP) was widespread. As we learn more about structure, it might seem that any kind of pattern, order or plan results in structure, but it is important to separate the structure from the other concepts and see how they relate to one another.

Structure does not mean that “everything is put in its place.” Yes, everything does need to be put in its place, but programmers were putting things in their places before SP.

Nor is structure simply the opposite of “random” or “chaotic.” However, structure does tend to make things less random and less chaotic.

Structure does not even mean “understandable.” It is all too easy to have structured code that goes beyond the capacity of mere mortals to fathom. However, structuring does allow source code to remain understandable far beyond the size and complexity where unstructured versions have lost all comprehension.

One of the problems is that structure occurs in degrees. In programming, we often say that code is either structured or unstructured. This might give you the impression that somehow structure is an absolute, binary (two-valued) feature. In general, some things can be more or less structured than other things.

Consider a pile of bricks. It might look completely chaotic and unstructured, but there has to be some kind of consistency in place, or we would not even be able to think of the collection as a “pile.” (It really doesn’t take structure to think of a collection as a single unit; it just takes modular cohesion, which goes beyond the scope of this story.) There is even some usefulness to the otherwise unstructured pile. We could build any number of barriers or towers of quite arbitrary size given enough bricks. How many bricks would it take? Well, that’s part of where the “unstructured-ness” arises. Because of the number of ways that the bricks may touch one another, we can never be quite sure how many bricks are in place or where the voids and weaknesses might be. Not only is the pile unsightly; even minor environmental vibrations can cause the entire pile to shift in a totally unexpected manner, with potentially catastrophic results.

A stack of bricks provides (a lot!) more structure. In a pile, the bricks could touch one another in any fashion whatsoever. When we stack bricks, we arrange individual bricks so that the touching faces of any two adjacent bricks are parallel. There are only a few ways in which this can be done. In one case, we align the ends of the two bricks with one another (“orthogonal tiling”). The other way is to overlap the two adjacent bricks (“hexagonal tiling”). In practice, we can only do this in one direction, and this has any one brick resting on top of two lower bricks. Both kinds of structuring would work to build a stack. Both kinds of structuring would convert the pile of bricks into a more compact and manageable unit. Stacks look much tidier than piles. Nor are stacks as likely to topple over at the slightest provocation. However, for building exceptionally strong and enduring barriers and towers, stacks are still not structured enough.

A wall of bricks requires yet more structure. While there were still a couple of ways to put bricks together in a stack, a wall, we are only going to select the strongest form, hexagonal tiling, where the bricks overlap. So would we ever use the other orthogonal tiling approach? Well, sure, we could, but you could relatively quickly show that you could ALWAYS replace any orthogonal wall with an equivalent hexagonal wall, and the hexagonal wall is ALWAYS going to be stronger. Consequently, most any modern brickwork always exhibits the “brick wall” structure internally. Out of all the possible ways to put the bricks together, only the “best” way is used and all other ways are neglected. This is the nature of “structured” bricklaying.

Of course, we say we build “structures” with bricks. True, but the underlying pattern of the brickwork is going to remain the same. Structure doesn’t have anything to do with the walls or towers we construct with bricks; it has to do with limiting the number of ways in which any two adjacent bricks are allowed to touch.

As a concept, structure constrains the ways in which we can group individual things together; not in the kinds of groupings or sets that we can have; nor in the kinds of collections that we can build. Structuring in brickwork results in the ubiquitous brick wall pattern so easily recognized world-wide. Structuring in programs means that of all the ways in which we can have one statement be executed after another, we are only going to allow a limited number of patterns to exist. There are just so many ways in which statements are going to be permitted to go together. All other patterns are prohibited.