This chapter is from the book
This chapter is from the book
This chapter is from the book
Defend Candidates and Look for Others
For a candidate to stay in the running, you should be able to state why it is worth keeping, along with any ideas you want to explore:
“A user accesses accounts to transfer funds, make payments, or view transaction history.” In the next breath you can add, “Accounts contain information that enables a customer to perform financial transactions. Accounts know how to describe themselves; they know and adjust their balance; they are affected by different financial transactions; they know their transaction history. Are there any other candidates we should be identifying to support accounts in their role?”
By taking short side excursions to look for more candidates, you will come back with a better sense of whether you are on target. You can find more candidates by looking for ways to support and complement the ones you’ve already found:
Marvin Minsky theorizes about the many agents working at different levels during problem solving. Most people don’t forget that they are packing a suitcase to go on a trip when they stop to fill a toiletry bag. Side excursions are a normal part of problem solving.
Potential candidates that complement and support Account:
AccountHistory—A record of transactions against an account
FinancialTransaction—An operation applied to one or more accounts. A service provider could represent each type of transaction that affects an account. There are multiple types of transactions that we support with our online banking application. What’s the difference between a transaction that affects an account’s balance, and an inquiry into some aspect of an account such as its balance, history, or activation status? How should we model each inquiry?
You are always free to decide all your candidates stink, toss them, and start over. At the beginning this is cheap and relatively painless. Defend candidates on their merits, and don’t protect them from close scrutiny.
Searching can go on for quite a while if you are full of ideas. Stop when you feel you are looking too far afield. You need enough candidates so that you can compare and contrast them and to seed your further design work. There isn’t any magic number. The more you know about a problem, the more candidates you are likely to invent in a first pass. Fifty candidates may seem like a lot, but it’s not an unreasonable number. Twenty is OK, too. You find candidates in bursts as you consider your design’s themes. It’s pretty common for candidates to support more than one theme. All this means is that your objects fit into and support more than one central concern.
Stop brainstorming candidates when you run out of energy. Then review how these candidates might collectively support the responsibilities implied by a theme. When you think you have enough candidates, review them once more for their merit.
Keep any candidate and put it on the “A” list, for acceptable, when you can
Give it a good name
Define it
Stereotype it
See that it might be used in support of a particular use case
See that it is an important architectural element
Assign it one or two initial responsibilities
Understand how other objects view it
See that it is important
Differentiate it from similar candidates
Discard a candidate when it
Has responsibilities that overlap with those of other candidates that you like better
Seems vague
Appears to be outside your system’s boundaries
Doesn’t add value
Seems insignificant or too clever or too much for what you need to accomplish
You may still be uncertain about some candidates. Put these on the “D,” or deferred, list to revisit later. For now, keep them in the running. The best way to make more progress is to design how these objects will work together. The very next step we’ll take is to assign each candidate specific responsibilities. And during that activity, we will come up with more candidates and reshape those we’ve already found.