The Art of Agile Development

Principles in Practice

These universal design principles provide good guidance, but they don’t help with specific languages or platforms. That’s why you need design principles for specific languages, such as Martin’s list of the principles of object-oriented class design.^[66] Unfortunately, when you take universal design principles and turn them into specific design advice, you lose something important: context. Every design decision occurs in the context of the whole design—the problem domain, other design decisions, the time schedule, other team members’ capabilities, etc.

Context makes every piece of specific design advice suspect. Yes, you should listen to it—there’s a lot of wisdom out there—but exercise healthy skepticism. Ask yourself, “When is this not true?” and “What is the author assuming?”

Consider the simple and popular “instance variables must be private” design rule. As one of the most widely repeated design rules, it often gets applied without real thought. That’s a shame because without context, the rule is meaningless and easily misused.

It’s true that instance variables should often be private, but if you want to understand the rule and when to break it, ask why. Why make instance variables private? One reason is that private variables enforce encapsulation. But why should anyone care about encapsulation?

The real reason private variables (and encapsulation) are good is that they help enforce decoupling. Decoupled code is good, right? Not always. Appropriately decoupled ...