4 Good class design to build the application right

In chapter 3, we worked with our clients on the functional and nonfunctional requirements to ensure that we build the right application. Simple textual analysis produced our initial set of classes. In this chapter, we begin to design the classes well to ensure that we build the application right.

In chapter 1, we learned that design is a disciplined engineering approach to create a solution to a problem. For software development, that means applying good software design techniques to find the best development path to a well-designed application that meets its requirements. In chapter 2, we saw that the development path requires iterations and, most likely, backtracking.

This chapter discusses where application design fits within the overall development process. It covers some basic guidelines for good class design. Because most applications consist of multiple classes, we’ll also examine how the classes can relate to each other. Chapter 3 introduced UML (Unified Modeling Language) use case diagrams. To document our class design, we’ll use more of these industry-standard diagrams. Finally, a design specification pulls together all the design documentation for an application.

4.1 When do we do application design?

4.2 Two important goals for good class design

4.2.1 Cohesion and the Single Responsibility Principle

4.2.2 Loose coupling and the Principle of Least Knowledge

4.3 UML class diagrams to document class design

4.4 Class relationships determine runtime interactions

4.4.1 Dependency: The most basic relationship

4.4.2 Aggregation and composition: Objects that contain other objects

4.4.3 Generalization: Superclasses and their subclasses

4.4.4 Abstract classes and interfaces: What subclasses must implement

4.5 UML state diagram: How an object changes state

4.6 UML sequence diagram: How objects interact [optional]

4.7 The design specification and software verification

Summary