Quotes About Design

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.

Don't refer to volatile concrete classes. Refer to abstract interfaces instead. This rule applies in all languages, whether statically or dynamically typed. It also puts severe constraints on the creation of objects and generally enforces the use of Abstract Factories.

Don't override concrete functions. Concrete functions often require source code dependencies. When you override those functions, you do not eliminate those dependencies—indeed, you inherit them. To manage those dependencies, you should make the function abstract and create multiple implementations.

In general output arguments should be avoided. If your function must change the state of something, have it change the state of its owning object.

This means that the UI and the database can be plugins to the business rules. It means that the source code of the business rules never mentions the UI or the database.

If its dependencies are inverted, it has an OO design. If its dependencies are not inverted, it has a procedural design.

It is far more common to fight your way through terrible software designs than it is to enjoy the pleasure of working with a good one.

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.

Why does good code rot so quickly into bad code? We have lots of explanations for it. We complain that the requirements changed in ways that thwart the original design. We bemoan the schedules that were too tight to do things right. We blather about stupid managers and intolerant customers and useless marketing types and telephone sanitizers. But the fault, dear Dilbert, is not in our stars, but in ourselves. We are unprofessional.

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.

If only we could pull this off one more time. If only we could just say we were done with implementation. But we can't, because the thing about implementation is that is actually has to be done. Analysis and design are not binary deliverables. They do not have unambiguous completion criteria. There's no real way to know that you are done with them. So we might as well be done on time.

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.

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.

CRP says that classes that are not tightly bound to each other with class relationships should not be in the same component.

It is the perversity of software that a module that you have designed to be easy to change can be made difficult to change by someone else simply hanging a dependency upon it.

Analysis and design are not binary deliverables. They do not have unambiguous completion criteria. There's no real way to know that you are done with them.

THE STABLE ABSTRACTIONS PRINCIPLE A component should be as abstract as it is stable.

OCP: The Open-Closed Principle Bertrand Meyer made this principle famous in the 1980s. The gist is that for software systems to be easy to change, they must be designed to allow the behavior of those systems to be changed by adding new code, rather than changing existing code.

Regardless of how they are eventually deployed, well-designed components always retain the ability to be independently deployable and, therefore, independently developable.

A good architect maximizes the number of decisions not made.

software artifact should be open for extension but closed for modification.

ISP: The Interface Segregation Principle This principle advises software designers to avoid depending on things that they don't use.

So, when and why should we use UML? Diagrams are most useful for communicating with others and for helping you work out design problems.