Professional C__ - Marc Gregoire [37]
Choose Threading Models
In this step, you choose the number of threads in your program and specify their interactions. In multithreaded designs, you should try to avoid shared data as much as possible because it will make your designs simpler and safer. If you cannot avoid shared data, you should specify locking requirements. If you are unfamiliar with multithreaded programs, or your platform does not support multithreading, then you should make your programs single-threaded. However, if your program has several distinct tasks, each of which should work in parallel, it might be a good candidate for multiple threads. For example, graphical user interface applications often have one thread performing the main application work and another thread waiting for the user to press buttons or select menu items. Multithreaded programming is covered in Chapter 22.
The chess program needs only one thread to control the game flow.
Specify Class Hierarchies for Each Subsystem
In this step, you determine the class hierarchies that you intend to write in your program. The chess program needs a class hierarchy, to represent the chess pieces. The hierarchy could work as shown in Figure 2-1.
FIGURE 2-1
In this hierarchy, a generic ChessPiece class serves as the abstract superclass. The hierarchy uses multiple inheritance to show that the queen piece is a combination of a rook and a bishop. A similar hierarchy is required for the ChessPieceView class.
Another class hierarchy can be used for the ChessBoardView class to make it possible to have a text-based interface or a graphical user interface for the game. Figure 2-2 shows an example hierarchy that allows the chess board to be displayed as text on a console or as a 2D or 3D rendering.
FIGURE 2-2
A similar hierarchy is required for the Player controller and for the individual classes of the ChessPieceView hierarchy.
Chapter 3 explains the details of designing classes and class hierarchies.
Specify Classes, Data Structures, Algorithms, and Patterns for Each Subsystem
In this step, you consider a greater level of detail, and specify the particulars of each subsystem, including the specific classes that you write for each subsystem. It may well turn out that you model each subsystem itself as a class. This information can again be summarized in a table:
This section of the design document would normally present the actual interfaces for each class, but this example will forgo that level of detail.
Designing classes and choosing data structures, algorithms, and patterns can be tricky. You should always keep in mind the rules of abstraction and reuse discussed earlier in this chapter. For abstraction, the key is to consider the interface and the implementation separately. First, specify the interface from the perspective of the user. Decide what you want the component to do. Then decide how the component will do it by choosing data structures and algorithms. For reuse, familiarize yourself with standard data structures, algorithms, and patterns. Also, make sure you are aware of the standard library code in C++, as well as any proprietary code available in your workplace.
Specify Error Handling for Each Subsystem
In this design step, you delineate the error handling in each subsystem. The error handling should include both system errors, such as memory allocation failures, and user errors, such as invalid entries. You should specify whether each subsystem uses exceptions. You can again summarize this information in a table:
SUBSYSTEM HANDLING SYSTEM ERRORS HANDLING USER ERRORS
GamePlay Logs an error with the ErrorLogger, shows a message to the user and gracefully shuts down the program if unable to allocate memory for ChessBoard or Players Not applicable (no direct user interface)
ChessBoard
ChessPiece Logs an error with the ErrorLogger and throws an exception if unable to allocate memory Not applicable (no direct user interface)
ChessBoardView
ChessPieceView