Decomposition

Decomposition means taking one large, complex problem and dividing it into smaller problems that can be handled separately. Instead of keeping a huge job in your head, you deal with a set of small jobs and then combine their solutions.

Imagine you are asked to write a program for a bike-hire scheme at a country park. It has to keep track of the bikes, hire them out, charge customers and report on the day, which is a lot to design in one go, so you decompose it into sub-problems:

• store the details of each bike
• hire a bike out to a customer
• work out the cost of a hire
• record a bike being returned
• print a summary of the day's hires

Each of these is a smaller problem that can be solved separately, and solving all five and putting the results together solves the whole problem.

Breaking a sub-problem down again

If a sub-problem is still too big, decompose it again. Working out the cost of a hire could become: find how many hours the bike was out, multiply that by the hourly rate, then take off the member discount if the customer has a membership number. Keep going until no piece feels too large to handle alone. A useful test is that you can list the steps for that piece without needing to know how any other part of the program works.

Combining the parts

Decomposition is not finished once the parts are solved, because they must fit together into one working program. The part that hires a bike out needs the stored bike details, and the summary needs the records of each hire, so you have to decide what information passes between the parts.

A description of someone dividing a job into separate pieces that can each be solved on their own and then put back together is describing decomposition. It is more than listing the sections of a program that already exists.