Producing high-quality programs is difficult and expensive, so programmers and the people who employ them are always eager to reuse past work. In bottom-up design, the approach is to start "at the bottom," with problems that you already know how to solve (and for which you might already have a reusable software component at hand).
From there, you can work upwards towards a solution to the overall problem.
During the 1970s and into the 80s, the primary software engineering methodology was . It is a valuable and often-used approach to problem-solving. For one thing, it deals almost entirely with producing the instructions necessary to solve a problem.
The structured programming approach to program design was based on the following advice: To solve a large problem, break the problem into several pieces and work on each piece separately; to solve each piece, treat it as a new problem which can itself be broken down into smaller problems; eventually, you will work your way down to problems that can be solved directly, without further decomposition. But as time went on, people realized that the design of the data structures for a program was at least as important as the design of subroutines and control structures.
For example, a mailing-list module might contain a list of names and addresses along with a subroutine for adding a new name, a subroutine for printing mailing labels, and so forth.
In such modules, the data itself is often hidden inside the module; a program that uses the module can then manipulate the data only indirectly, by calling the subroutines provided by the module.Top-down programming doesn't give adequate consideration to the data that the program manipulates.Another problem with strict top-down programming is that it makes it difficult to reuse work done for other projects.A mailing list object, for example, has a state consisting of a list of names and addresses.If you send it a message telling it to add a name, it will respond by modifying its state to reflect the change.There is not much "top-down" in the large-scale design of such a program, and people used to more traditional programs can have a hard time getting used to OOP.However, people who use OOP would claim that object-oriented programs tend to be better models of the way the world itself works, and that they are therefore easier to write, easier to understand, and more likely to be correct.This protects the data, since it can only be manipulated in known, well-defined ways.And it makes it easier for programs to use the module, since they don't have to worry about the details of how the data is represented.By starting with a particular problem and subdividing it into convenient pieces, top-down programming tends to produce a design that is unique to that problem.It is unlikely that you will be able to take a large chunk of programming from another program and fit it into your project, at least not without extensive modification.