14.1. The Second Store

Sam comes in and tells me he is opening his second store in the near future and he wants the system to be ready when that occurs.

I ask the leading question, "Are these two stores, or one store in two places?"

Sam stares at me with "the look."

He is already familiar with the reasons behind my strange questions. "What's the difference?" he asks.

"In the case of two stores, the system is almost ready to go now," I replied.

"And in the other case?" he queried.

"Then I've got some questions for you to answer."

"It sounds like the first case will cost less," he noted. "But go ahead with your questions."

"I wrote down the assumptions I made in the first system and the design decisions that were relevant to those assumptions. The assumptions are hard to decipher from the code itself, so I kept them as a separate document."

I continued , "A CDDisc was either in the store or not in the store. If it was not in the store and not part of a Rental, it was assumed lost. There was nowhere else for the Rental to go, except to be lost and never returned (like Charlie on the MTA). If CDDiscs were rented in only one store and were returned to that store, we could stop here."

"I like stopping; it is definitely cheaper. But what happens if I let them return a CDDisc to another store?" asked Sam.

"It makes things a little harder," I said. "Currently, when a customer returns a CDDisc to the store and the PhysicalID is entered into the system, the system might respond that the PhysicalID was not found. If that is the case, the staff has been instructed to enter the number manually. The assumption is that the scanner cannot read the bar code. If there is still no match, the CDDisc is set aside. At that point, the assumption is that the label is completely mucked up.

"With a set of stores, if there is no match, the system must determine to which other store the CDDisc belongs," I continued. "With only two stores, the staff can assume that an unmatched CDDisc belongs to the other store. With three stores we can determine which store by the easy way or the less easy way."

"The easy always costs less, right?" Sam asked.

"Yes, but it doesn't always give you flexibility for the future," I replied. "With multiple stores, there are two alternatives to how to store the data. One alternative is that the CDDiscCollection contains the CDDiscs in all stores and the RentalCollection contains the Rentals for all stores. The other is that there are separate CDDiscCollections and RentalCollections for each store. With the former, we're dealing with a central server and networks. With the latter, we just need to add an interface that allows us to query another store to see if a PhysicalID is part of their CDDiscCollection. This is the easy way."

"Let's go with the latter," Sam stated emphatically.

"What about availability? Do you want the catalog search to show availability of a CDDisc in another store?" I asked.

"That sounds good to me," he replied.

"Think About the Big Picture" is an appropriate guideline to use when deciding how to proceed. Adding a central server provides a good deal of future expansion possibilities. For example, Sam could easily add all-store reports , instead of having each store prepare its own. If Sam's plans involved more features that suggested a central database solution, now would be a good time to implement the capability. A central server does have the disadvantage that a store with network difficulties cannot process rentals.

Sam has not indicated other needs that might favor a central solution. So Tim and I decide to create a peer-to-peer solution. Each store will query the other stores for information. The interface that each store's system provides to the other stores looks like this:

 interface StoreServiceProvider         Boolean is_physical_id_in_cddisc_collection(PhysicalID physical_id)         Boolean show_availability_of_CD_release(UPCCode upc_code) 

is_physical_id_in_cddisc_collection( ) is a wordy name for a method. It is almost as long as the logic in the method. It just calls the find_by_physical_id( ) method in CDDiscCollection and returns TRue or false . The show_availability_of_CD_release( ) method returns true if a CDDisc is available for the CDRelease .

When Tim and I sit down to discuss multiple stores, we realize we missed an abstraction in the first release: the Store . This abstraction contains the data relative to a location ("Clump Data So That There Is Less to Think About "):

 class Store         CommonString name         Address address         PhoneNumber phone_number 

Since we have multiple stores, we have a StoreCollection that contains all the Store s:

 class StoreCollection         Store where_is_physical_id_in_cddisc_collection(PhysicalID physical_id)         Store[] show_availability_of_CD_release(UPCCode upc_code)         Store[] find_all_stores( ) 

StoreCollection knows how many Store s there are. The method show_availability_of_CD_release( ) queries each Store to find where a CDDisc belongs, by calling the is_physical_id_in_cddisc_collection( ) method in the StoreServiceProvider for each Store . Likewise, the show_availability_of_CD_release( ) method calls show_availability_of_CD_release( ) in the StoreServiceProvider for each Store .