Principle 1.2.1. PROGRAMMING TIP: Design before coding.
The sooner you begin to type code, the longer the program will take to finish, because careful design of the program must precede coding. This is particularly true of object-oriented programs.
Section 1.2 Designing Good Programs
Programming is not simply a question of typing Java code. Rather, it involves a considerable amount of planning and careful designing. Badly designed programs rarely work correctly.
Even though it is tempting for novice programmers to start entering code almost immediately, one of the first rules of programming is
In other words, the more thought and care you put into designing a program, the more likely you are to end up with one that works correctly. The following subsections provide a brief overview of the program development process.
Subsection 1.2.1 The Software Engineering Life Cycle
Software engineering is the process of designing and writing computer programs, or, software. The software life cycle refers to the different phases in that process. Our presentation of examples in the book will focus on four phases of the overall life cycle.
- Specification: In the specification phase we provide a statement of the problem and a detailed description of what the program will do.
- Design: In the design phase we describe the details of the various classes, methods, and data that will be used in the program.
- Implementation: The implementation phase refers to the actual coding of the program into Java.
- Testing: In the testing phase we test the program’s performance to make sure it is correct, recoding it or redesigning it as necessary.
Figure 1.2.2 gives a detailed overview of the software life cycle. It shows that designing an object-oriented program is largely a matter of asking the right questions about the classes, data, and methods that make up the program.
Overall, the programming process can be viewed as one that repeatedly applies the divide-and-conquer principle. That is, repeatedly divide the problem until you have a collection of relatively easy-to-solve subproblems, each of which can be handled by an object.
In this way the program is divided into a collection of interacting objects. For each object we design a class. And for each class, we divide it further into its variables and methods.
When should we stop subdividing? How much of a task should be assigned to a single object or a single method?
The answers to these and similar questions are not easy. Good answers require the kind of judgment that comes through experience, and frequently there is more than one good way to design a solution.
As we learn more about object-oriented programming, we’ll learn more about how to make these decisions.
You have attempted of activities on this page.
