Afterword

Responsibilities, dependencies, interfaces, ducks, inheritance, behavior sharing, composition, and testing—you’ve learned it all. You’ve immersed yourself in a world of objects, and if this book has achieved its goal, you think differently about objects now than when you first began.

Chapter 1, Object-Oriented Design, stated that object-oriented design is about managing dependencies; that statement is still true but it’s just one truth about design. A deeper truth is that there is a way in which all objects are identical, regardless of whether they represent entire applications, major subsystems, individual classes, or simple methods. A single object never stands alone; applications consist of objects that are related to one another. Like a key and its lock, a hand and its glove, or a call and its response objects are defined, not by what they do, but by the messages that pass between them. Object-oriented design is fractal; the central problem is to define an extensible way for objects to communicate, and at every level of magnification this problem looks the same.

This book is full of rules about how to write code—rules for managing dependencies and creating interfaces. Now that you know these rules you can bend them to your own purposes. The tensions inherent in design mean that these rules are meant to be broken; learning to break them well is a designer’s greatest strength.

The tenets of design are tools and with practice they will come naturally into your hand, allowing you to create changeable applications that serve their purpose and bring you joy. Your applications will not be perfect but do not be discouraged. Perfection is elusive, perhaps even unreachable; this should not impede your desire to achieve it. Persist. Practice. Experiment. Imagine. Do your best work, and all else will follow.