Design and Development Guidelines


Style Guidelines

Code readability and maintainability are both incredibly important. It is essential that you develop a consistent coding style for yourself as well as anyone who may look at your code in the future. Below are a few common guidelines that you should incorporate into your code.

Excerpts from Java Software Solutions 5th edition by Lewis&Loftus (Appendix F)

Identifier Naming

Method and variable names generally start with a lowercase letter and class names normally start with an uppercase letter. Identifiers are often a multi-word description of what they are identifying, and uppercase letters are used to specify word breaks. For example, a variable representing a first name might be called firstName. A class representing a bank account might be called BankAccount.

Indentation

Code between an open brace ({) and the corresponding close brace (}) should be indented a consistent number of spaces. This applies to if statements, loops, method definitions, and class definitions. The close brace should always be lined up with the header of the statement. L&L suggest that the open brace be on a new line, however putting the open brace at the end of the header line is also common. Choose your own style, and be consistent!

Examples:

if(firstName.equals("Bob")) 
{ 
   //all code indented by the same amount
   System.out.println("Short for Robert?");
   System.out.println("Or is that your full name?");
}  

public static void main(String[] args) { //open brace at the end of the header line
   //all code indented by the same amount
   System.out.println("Hello, world");
}  

Spacing

Documentation


Program Design

Beginning programmers are typically most concerned with getting their code to run. Just getting a program to compile can be such a huge hurdle that the programmer doesn't stop to think about whether someone else can actually read the code, or whether it can be easily extended to support new functionality. However, the process of designing a clean program is extremely important, and a good design can make the coding itself much simpler.

Becoming a good designer takes lots of practice, and it also takes a bit of confidence. As you design programs, you have to have confidence that you will be able to figure out a way to implement your designs. Rather than try to piece together what you know how to do, think about what you want your program to do and have confidence that you can find a way to make your program do that.

Additionally, understand that program design is a creative process. Your design for a program may differ from that of one of your classmates. You may also design a program and decide that your design isn't quite right. You need to be willing to redesign your programs when you discover that your design just doesn't support everything it needs to.

Design Goals

  1. Reusability - As you develop more programs, you will undoubtedly notice that many of them require similar functionality. If you are careful in designing your programs, you should be able to easily reuse components in future programs. For example, you might notice that lots of your programs require you to maintain a sorted list of items. If you were careful in designing that very first program that required a sorted list, you probably implemented a general purpose class that maintained a sorted list of items and supported methods such as add, remove, and find. You can easily reuse this class in any program that requires a sorted list.
  2. Robustness - It is important to ensure that your programs are robust to failures and errors, and handle all situations gracefully. Among other things, this means that your design should limit the number of errors that might be triggered by misbehaving code. Encapsulation, a fundamental object-oriented principle, refers to limiting how data is modified by making data members private and allowing access to and modification of the data only through limited methods. It is one way to help ensure that your programs are robust.
  3. Extensibility - Anyone with a computer knows that software updates happen continuously. Software is continually being extended to support new functionality. Clearly, in order to avoid having to rewrite a program from scratch each time it is updated, a design should easily support integration of new classes.
  4. Modularity - Designing a program as a set of interoperating yet independent modules makes development and maintenance much simpler. It can be very intimidating to think about writing a program containing hundreds or thousands of lines of code. However, if a programmer takes the time to design the program as several modules that can be implemented and tested independently, the task of implementation becomes much more manageable.
  5. Efficiency - The easy way to do something is not always the most efficient. It is important to understand the resources required to accomplish a task and to ensure that your algorithms make efficient use of those resources. We'll touch on this topic in CS 112, but you will learn more about this in CS 245.

Design Techniques and Tools

Design really is a creative process and each person may approach the process differently. For the purposes of this class, the outcome of the design process will be a set of classes you need to implement, the data and methods each class will contain, and and overview of how the classes will interact. Larger programs may have more complex design issues and the first outcome of the design process will be a system architecture with multiple components for which a more refined design will then be developed.

Keep in mind that an initial design is unlikely to be flawless. You will almost certainly need to go back and refine or change your design as you implement your program.

Class Responsibilities Collaborators (CRC) Model

The CRC model is an approach to design wherein the designers use index cards to represent the classes interacting in a program. For each class, the designers identify the responsibilities of the class and the classes with which it will need to collaborate in order to execute its responsibilities.

Links:

http://www.agilemodeling.com/artifacts/crcModel.htm

Unified Modeling Language (UML)

UML stands for the Unified Modeling Language, which has become the most popular notation for representing the design of an object-oriented program.

UML class diagrams represent each class with a rectangle, inside of which are the data members and methods supported by the class. Dotted arrows are drawn between classes to indicated that one class invokes the methods of another. There are many other types of UML diagrams as well.

Links:

http://dn.codegear.com/article/31863

Identifying Classes

The CRC model and UML help you to think through what each class should contain and how to relate one class to another. But, the question of how to identify an initial set of classes still remains. It is certainly worth your time to revisit Chapter 6 (particularly 6.1-6.4) of the L&L text.

One approach (discussed in the text) to identifying the classes you should use in your design is to identify the nouns and noun phrases present in the description of the program you must write. Below is a description of a Connect Four program. From this description, identify a set of classes you might use to implement the program. An example might be a class to represent the board.

The game is played using a board with 7 columns and 6 rows. Each player is assigned a color, one player is red and one player is black. At each turn, a player places a checker of her color in the top empty space of one of the columns. Once a checker has been placed, your program will check to see if a player has won the game, or if the board is full. A player wins if four checkers of her color are adjacent either vertically, horizontally, or diagonally. If there is a win or tie, the program will print an appropriate message and exit. If not, the next player takes a turn.

Links:

http://www.codeproject.com/gen/design/idclass.asp

Identifying Methods

Methods define the behaviors of each class. To identify the methods necessary for the program, consider the actions described by the verbs in your program description. In the example above, we would likely want to have a method to support placing a checker on the board. That might indicate that a placeChecker method should be implemented in the Board class.

It may not always be clear in which class a method should be implemented. Again, don't be afraid to consider multiple options and change your design if necessary.

Discussion:

  1. Complete the design of the Connect Four program described above.
  2. Compare and contrast 2 or 3 alternate designs.

Sami Rollins

Date: 2007-08-13