These phrases sum up my approach to object-oriented design: empowerment, outside-In design and instance-oriented design.
Recall one of the best definitions of a software object: an empowered data structure, hiding behind, and being useful through, a message-accepting interface. This definition stresses what many developers only pay lip service to: that the most important aspect of an object is its interface. So that’s where we should start when designing objects.
Start at the outside of an object. This is the set of messages that it accepts. Notice how we are talking about an object; not a class. You need to get to know your objects before you have the evidence as to the classes that make (and perhaps type) them. When you know the outside of your object instances, you can start thinking about the type system. In languages like Java you can start thinking about the interfaces. In C++ you can start thinking about the pABCs (the purely abstract base classes).
When you have some idea as to the interfaces of the object types and some ideas as to how the object instances will collaborate (messages emphasized again), you can move on to designing the methods (member functions) that support the interface. From there you can move on to the other, less public methods. And on to the instance variables (data members). That’s outside-in design.
Notice, however, that many, many people design inside-out. They start by thinking about the data — instance variables or data members — and let them determine the methods and the interface. You end up with a poor object. You end up with an object with nothing but get_ and set_ methods. You end up with an overly-complex and thinly-disguised data structure. You end up not using the power of an object-oriented language. You end up doing something you could have done in C or Pascal; and much more straightforwardly at that.
Outside-in design produces empowered objects. Objects that add value to the data they happen to store.
Notice how the CRC* technique encourages a lot of what I’m saying. How do you start with messages? Well that’s exactly what drives a CRC workshop. Where do the designs for the methods come from. The collaboration of a CRC workshop.
*Class (although I’d rather say type), responsibility, collaboration