Quotes About Structure

Every house is built after a plan of its own: one looks in, another looks out; one is tall, another broad; and they are so irregular in height and outline that they seem as if they were all getting up out of bed at different hours in the morning, some not being yet quite up, while others are yawning and stretching themselves.

A good speech has a beginning, a middle and an end, the best example being, "I love you."

If it doesn't work horizontally as prose... it probably won't work any better vertically pretending to be poetry.

The true professional knows that delivering function at the expense of structure is a fool's errand. It is the structure of your code that allows it to be flexible. If you compromise the structure, you compromise the future.

It is not enough for code to work. Code that works is often badly broken. Programmers who satisfy themselves with merely working code are behaving unprofessionally. They may fear that they don't have time to improve the structure and design of their code, but I disagree. Nothing has a more profound and long-term degrading effect upon a development project than bad code.

Software has two types of value: the value of its behavior and the value of its structure. The second of these is the greater of the two because it is this value that makes software soft.

The only way to prove that your software is easy to change is to make easy changes to it. And when you find that the changes aren't as easy as you thought, you refine the design so that the next change is easier. When do you make these easy changes? All the time! Every time you look at a module you make small, lightweight changes to it to improve its structure.

OO imposes discipline on indirect transfer of control.

Structured programming is discipline imposed upon direct transfer of control.

Objects hide their data behind abstractions and expose functions that operate on that data. Data structure expose their data and have no meaningful functions.

Software architecture is the art of drawing lines that I call boundaries. Those boundaries separate software elements from one another, and restrict those on one side from knowing about those on the other.

When classes lose cohesion, split them!

The architecture of a system is defined by a set of software components and the boundaries that separate them.

The component structure cannot be designed from the top down. It is not one of the first things about the system that is designed, but rather evolves as the system grows and changes.

One of the best ways to ruin a program is to make massive changes to its structure in the name of improvement. Some programs never recover from such "improvements." The problem is that it's very hard to get the program working the same way it worked before the "improvement.

In fact, component dependency diagrams have very little do to with describing the function of the application. Instead, they are a map to the buildability and maintainability of the application.

If we tried to design the component dependency structure before we designed any classes, we would likely fail rather badly. We would not know much about common closure, we would be unaware of any reusable elements, and we would almost certainly create components that produced dependency cycles.

if the bricks aren't well made, the architecture of the building doesn't matter much.

SRP: The Single Responsibility Principle An active corollary to Conway's law: The best structure for a software system is heavily influenced by the social structure of the organization that uses it so that each software module has one, and only one, reason to change.

The architecture of a software system is the shape given to that system by those who build it. The form of that shape is in the division of that system into components, the arrangement of those components, and the ways in which those components communicate with each other.

software has two types of value: the value of its behavior and the value of its structure.

Architects separate functionality based on how, why, and when it changes, and then organize that separated functionality into a hierarchy of components.

The goal of the architect is to create a shape for the system that recognizes policy as the most essential element of the system while making the details irrelevant to that policy. This allows decisions about those details to be delayed and deferred.

But then closely related concepts should not be separated into different files unless you have a very good reason. Indeed, this is one of the reasons that protected variables should be avoided.