Design Recipes (V1): 11/07 - 11/10

The design recipe will evolve during the course of this term, in line with the different phases that are being considered.

Design Recipe V1 -- Composition

The format of the data being processed naturally implies the way in which Java programs are written. As we finally move to describe the concepts of Java programs using classes and objects, we must revisit our design process

Classification Phase

Each class has the opportunity to define state information as fields. These naturally make it possible to create helper methods to access or update the information. Thus, the template is as follows:

public class SOMECLASS {
// information
T field;

    // get helper method
   public T getField() {
      return field;
   }

   // modify the field
   public void setField(T newValue) {
      field = newValue;
   }
}

So each field implies the existence of a "getter" helper method, to return the value, as well as a "setter" helper method, to update the value.

Desired operations on an object's state appear as methods that take parameters as objects. For example, you might wish to say "count grades less than 20" to an object. Assume this is actually some meaningful statement with regards to a particular class. This operation can be broken into several parts: (a) name ("countGradesLessThan"); (b) returnValue (an int is likely to be returned); (c) parameters (there is nothing magical about 20. It could be 10 and still be meaningful. Treat as a parameter "min". We are now ready to present the template for an operation:

public class SOMECLASS {
/**
   * Operation.
   *
   * @param p1 describe parameter p1.
   * @param p2 describe parameter p2.
   * @return    describe what is returned
   */
   public returnValue name (parameters) {
        ...
       return some Value (if returnValue not void)
    }
}

In the specific case above, we have the following operation:

public class SOMECLASS {
    /**
     * Count grades less than some minimum value.
     *
     * @param min    Minimum value
     * @return       count of values less than min.
    public int countGradesLessThan(int min) {
       int ct;

       ...

       return ct;
    }
}

Design Phases

The first step, now, in solving any problem is to identify the core concepts that exist within the problem definition. Whereas in the design recipe version 0 we were content to store all information within local variables of primitive type (or arrays) we choose now to identify common concepts and encapsulate information relevant to those concepts within classes.

/**
 * Define the package within which the concept is to be defined. The package should include
 * your CCC unix id, so we can uniquely identify the code. Within reason, it is also useful
 * to encode the homework problem in the name, to make it easy for you to manage your homeworks.
 */
package heineman.hw1;

/**
 * What is the specific concept being defined here. The name of the
 * class reflects the concept being defined.
 * 
 * @author AUTHOR-ID
 */
public class Template {

  /**
   * Fields are defined here.
   */

   
  /**
   * Constructors used to construct objects of this class are defined next.
   * The no-argument constructor is considered the "default" one.
   */
  public Template () {
  }  

  /** next common getter and setter methods are defined, as needed, based on the fields. */
  public void setSomeField(PARAMS) { ... }
  public void setSomeOtherField(PARAMS) { ... }

  /** next come the method(s) that represent the behavior of objects from this class. */
  public RETURN-TYPE someMethod(PARAMS) { ... }
  public RETURN-TYPE someOtherMethod(PARAMS) { ... }

}

Note that these concept classes should rarely have a static void main (String []args) method defined. Following this etiquette will help you keep your code clean. All main methods should be defined in classes that are clearly identified as either Test classes, or Main classes that are to be executed by the user directly.