top down : Java Glossary

You then break the program into major chunks and define what each is going to do. You then define subchunks. You get it down to classes and methods. Each with a clearly defined function of what it will and will not do.

Then you code, or give the job to a team of programmers.

The advantages of this approach are:

• You plan before you code. You don’t throw away code (at least not until the user gets a peek and decides to totally rewrite the spec).
• There is greater logical consistency. The UI (User Interface) makes sense to the user. It is not warped by considerations based on ease of implementation.
• The code is easier to understand.
• You get better encapsulation, since the rules are clear on just what a method does and even more importantly does not do.

• You will usually miss elegant implementations, and the code itself will have to jump through hoops to implement some arbitrary high level behaviour or interface definitions.
• You will find yourself creating several variants on the same low level code. It can be quite a bit of work to make these standard and replace them.
• The whole scheme is based on the premise you know more about what the project should do before you start that after you have developed some tools and the user has played with a primitive version of the application. The approach works best when you have an extremely clear idea of where you are headed before you start.