This chapter is from the book
This chapter is from the book
This chapter is from the book
Characterizing Candidates
Before eliminating any possibility, consider how a candidate might work and how it relates to others. It is best to consider a candidate in a larger context. We can characterize candidates according to their
Work habits
Relationships with others
Common obligations
Location within an application architecture
Abstraction level
To explore a candidate’s work habits, ask, “What does it do, and how does it fit in?” Take one point of view—from the outside looking in. This is the same view a peer or client would take. Speculate about what services it might offer or how it might affect others. Think about these things, but don’t assign responsibilities just yet. Ask whether the object is self-contained, working on its own initiative, or directed by others. Will it be constantly busy? Or will it need to be prodded into action? Is it an important, central character, or is it somewhere on the periphery? Ask what each candidate might do and be. If you haven’t any idea, dig in and look for its potential value. If you are undecided, spend a few minutes speculating how it might fit into its neighborhood and about the nature of its role:
We think of an Account as an information holder. So we do not think of it adjusting its balance on its own—it is probably changed by outside requests (both online banking transactions and other account activity). An Account knows its balance and transaction history. An account doesn’t manage its customer, so it doesn’t have much of a structuring role, but it is associated with its customers (does it need to know its customer, or does its customer know about it?). It isn’t obvious how backend banking transactions that affect an account’s status will be controlled (will an Account be involved in delegating this work or not?) —so we are uncertain how much work it will actually do. We’ll defer thinking through these issues until we develop a more detailed blueprint for our application’s control architecture.
CRC cards, as invented by Ward Cunningham and Kent Beck, were originally used to teach object-oriented concepts. They have far broader applicability than as teaching aids. They can help you think about and link candidates.