This chapter is from the book
This chapter is from the book
This chapter is from the book
Looking for Objects and Roles, and then Classes
The first candidates to look for should represent important things: concepts, machinery, and mechanisms. Typically these kinds of candidates are smart—they do things. They may know things, too, but they perform actions based on what they know. Initially, think very concretely. Abstraction will come later, after you see more concrete objects and understand their relationships to others. To start, identify distinct objects that have clear roles. Next, decide what candidates should know and do (their responsibilities) and whom they work with (their collaborators).
Then, thinking more abstractly, you can turn to identifying aspects that are common to a number of candidates. Shift your focus from thinking about objects and their individual roles to deciding what objects have in common. Only after you’ve made decisions about common responsibilities that are shared by different candidates can you define common roles. We deem our objects and roles candidates until their value has been proven. Only then do we decide how they will be realized as classes and interfaces.
When you transition from candidates to classes and interfaces, you have options. You can employ inheritance, abstraction, interfaces, and collaborations to construct a well-factored, flexible design. You will specify abstract and concrete classes as well as interfaces. An abstract class provides a partial implementation of responsibilities. It leaves subclasses with the obligation to implement specific responsibilities. A concrete class provides a complete implementation. An interface specifies responsibilities more precisely as method signatures but leaves their implementation open. Any class can implement an interface, regardless of its position in any class inheritance hierarchy.
Abstract and concrete classes are the building blocks we use to specify an implementation. Declaring interfaces is one means to make it more flexible and extensible. A reusable role is best specified as an interface that can be implemented by one or more classes.