Prefactoring

2.3. What's in a Name?

Names are important, not just for the code but also for requirements and analysis. If you don't know what you're talking about, it's hard to design for it.

Sam described how he wants to keep track of the CDs. He also desired a catalog of all the CDs that he has for rent.

"So, what is a CD?" I asked Sam.

He paused for a moment and looked at me with a questioning expression on his face. He must have thought I was crazy. "You know, one of those round things you put in a CD player," he said.

"So, when you said you want a CD catalog, do you mean you want an entry in it for every round thing you have in your store?" I asked.

He paused again. "No, I want only one for each title, regardless of how many copies I have in the store."

I suggested, "So, let's decide to use two terms, one for the CD title and one for the CD copy. This way we minimize the opportunity for misunderstanding. What do you want to call each thing?"

"Now I see what you mean," he replied. "What do you suggest?"

I replied, "Let's call the title a CDRelease, and the other a CDDisc. We could use the name CDTitle, but that would start to get confusing when we talk about the title of a CDTitle. To clarify what we mean even further, we can describe each term with a sentence:

"Now is it possible that a CD which a customer would be looking for would be related to two different UPCs?" I asked.

"It's possible," he said. "But I don't think we need to worry about that. One would usually have the term ...