Overall project structure

We are building this program on the overall pattern of Dependency Inversion. What does this mean? Let's try some simple language:

The programmers on this project should be able to make something — a component — for this project, and have it behave the way they want it to, without knowing anything about how their component will be used. This doesn't mean they don't have to make something that works; they do. But they don't have to know the details of the implementation.

Dependency Inversion: A Restaurant

Think about a kitchen with the following food providers:

• a deep-fryer
• a factory that makes prepared ingredients
• a delivery person who re-stocks food in the morning.

The deep-fryer fries food; that's all it does. The factory turns out cans of chopped tomatoes or packages of bow-tie pasta or any of a hundred ready-mades. The delivery person puts food in the refrigerators and shelves.

None of these components knows or cares how the chef makes the food. They are tuned, in their functions, to produce food that is useful to the chef, but only by design and not through any information-seeking.* They do their job. It is up to the chef to assemble the components into food.

None of this process is important to the customer, either. The customer does get to see a menu, but otherwise knows nothing about how the kitchen works. The customer works through the waiter, who is an adapter between the kitchen and the customer.

Now, note this carefully: If at some point the chef decides that she is going to make fish and chips using the pan rather than the deep fryer, and change the number of minutes it cooks, and sing to the fish and chips while making them, none of it matters to the customer or the waiter. If the restaurant installs a new system by which the waiter enters orders wirelessly instead of by writing on a paper ticket, none of it matters to the customer, but it does matter to the waiter and the chef -- at their interface.

If the power company decides to switch from a coal-fired plant to hydroelectric power, it doesn't affect the way the deep-fryer runs, because power grids are standardized.

In other words, components can work independently, with the points of contact as interfaces. Think of it this way:

power plant---[I]---deep-fryer---[I]---chef---[I]---waiter---[I]---customer
               |                  |            |              |
             outlet            buttons   ticket system      order

Each [I] represents an interface: A standard for how the component to the right will use the one to the left.

* It is true that the delivery truck has a list of foods. In this sense the delivery person "knows" something about the kitchen. In software practice, though, this is essentially a different layer. More later.