Page 330 - Introduction to Programming with Java: A Problem Solving Approach

296 Chapter 8 Software Engineering 8.1 Introduction
In Chapters 6 and 7, we looked mostly at the “science” of Java programming—how to declare objects, define classes, define methods, and so on. In this chapter, we’ll be looking more at the “practice” of Java programming—how to design and develop a program, and how to make it easy to read. The practice of pro- gramming is nicely summed up in the term software engineering, where software engineering is:1
1. The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software.
2. The study of approaches as in 1.
We start the chapter with an in-depth discussion of coding-style conventions that help make programs more readable. We show how to divide a large task into a set of smaller tasks by delegating some of the work in a method to other methods. We discuss encapsulation, one of the cornerstones of proper OOP design. Next, we describe alternative design strategies—top-down, bottom-up, and case-based. As you work with some- thing, your understanding of it improves, and we suggest that you plan to continuously redesign with more sophistication in an evolutionary process called iterative enhancement. We emphasize that you’ll be happier and your product will be better if you test thoroughly and frequently as you go along. To facilitate modular testing, we show how you can include a main method in each class. Up until now we’ve made heavy use of this to emphasize that each execution of an instance method is uniquely tied to a particular object, but near the end of the chapter we show how you can streamline your code by omitting this when there is no ambiguity. In a final optional section, we show how you can use simple graphics to construct a handy orga- nizational tool called CRC cards.
8.2 Coding-Style Conventions
We’ll now present some guidelines for coding style. We’ve mentioned and illustrated many of these style guidelines previously, so much of this section should be review. We’ll provide more guidelines later as we de- scribe more Java. For a complete list of all the coding-style guidelines used in this book, refer to Appendix 5, “Java Coding-Style Conventions.” The coding-style conventions we use are for the most part a simplified
2 subsetofthestyleconventionspresentedinSun’sJavaCodeConventionsWebsite. Ifyouhaveastyleques-
tion that is not addressed in Appendix 5, refer to Sun’s Web site.
We realize there are some style issues where there is legitimate disagreement over the best way to do
things. Many different standards exist. Sun attempts to choose the best conventions from among the com- monly used conventions. We attempt to do the same. If you’re reading this book as part of a course and your teacher disagrees with the book’s style conventions or Sun’s style conventions, please follow your teacher’s guidelines. One thing in particular that your teacher might require is special formatting for class and method documentation. Many professional Java programmers use Java’s javadoc tool to aid with class and method documentation. The javadoc tool extracts specially commented documentation from the source code and displays it in a neatly organized report. Sun uses the javadoc tool to produce its API library documentation. See Appendix 6 for details.
1 Definition taken from Institute of Electrical and Electronics Engineers (IEEE) Standard 610.12. 2 http://java.sun.com/docs/codeconv
Apago PDF Enhancer