Emergent Design Workshop I
IF IT WORKS FOR ONE IT WILL WORK FOR MANY
In Emergent Design the order of increments is proportionately relevant to the effort it takes to deliver a functionality. One of the patterns for choosing the next increment involves cases where the same operation can be iteratively performed on a collection of objects.
Let's take the example of performing reservations for a hotel management system. The first step to consider is verifying room availability for a certain period of time, inserting client information, payment operations and delivering a reservation code.
By working incrementally we can start with a simple case of a hotel with only one room. Let's focus on the dynamic that Room requires. In the case of a hotel with a single room, the code is quite simple:
// hotel::availableRooms(...) if( _room.isAvailable(...) ) result.addRoom(_room);
Note that the system can at most give us only one room, considering that _room is in fact one Room :-).
My tests lead me to verify the number of available rooms...
// hotel::availableRooms() Collection result = new Collection(); if( _room.isAvailable() ) result->addRoom(_room); return result;
Obviously the maximum number is equal to 1.
What is the next step? Consider a case where the hotel has more rooms? Or continue with other increments? But why?
If it works for one, it will work for many. I know for sure that to consider the real case of a hotel with many rooms I will have to add another iterator. The easiest solution would be an external iterator. Just add a for...it's easy.
//hotel::availableRooms(...) Collection result = new Collection(); foreach(... if( _room.isAvailable(...) ) result->addRoom(_room); return result;
Is it worth it to do it now?
The answer is no. The code with for is easily replaceable: all we need to do is to wrap up our line in a iterative mechanism. But at the same time this increases the complexity of the legibility and use of the code and it could increase the complexity of the management of test combinations as well.
In truth, the introduction of an iterative mechanism at this time complicates the introduction of new increments. In other words, managing a number of rooms doesn't simplify the introduction of search periods, reservations, etc. I will keep inserting new increments that are independent of the collection of rooms for as long as I can, putting off the moment when I will introduce my iteration on the collection. After I have added periods and reservations to a single room I could find myself with code like this:
// hotel::availableRoomsIn(aPeriod) Collection result = new Collection(); if( _room.isAvailableIn(aPeriod) ) result->addRoom(_room);return result;
and decide to apply the external iterative mechanism (with the for in the hotel code) or an internal iterative mechanism to protect the self-same iterative mechanism.
//hotel::availableRoomsIn(aPeriod) return _rooms.availableRoomsIn(aPeriod);
If it works for one, it will work for many is intended as a critique of the next step being defined as the easiest step to take. Not always! We need to make a distinction between easy and simple.
