Docstoc

Design Issues

Document Sample
Design Issues Powered By Docstoc
					Design Issues
 Where to put class definitions
 What    goes in a source file?
     At most 1 public class
     Other “helper” classes as needed (list/node)
     All classes have a unique .class file
 What    goes in a package?
     Related classes, duh
     Many files, though
      Arranging Class Members
 Pick   a style and stick with it
     In other words, who cares?
 Many    like public-to-private continuum
     So can see class interface first
 With javadoc, these aren’t crucial issues
 Be readable!
     Use white space (indent, etc.)
     Not too many comments! (“Say it in code”)
             Avoid Public Fields
 At   all costs!
      Except static final primitives (constants)
 Don’t be tempted to use struct-like records
 Will cause race conditions with threading
 Beware setter methods!
      Can throw off object state
                   javadoc
          command
 “javadoc”
 Documents classes by reading /**-style
  comments
     Immediately before class and method
      definitions
 Recognizes    special tags:
     @author, @version, @since, @param,
      @return, @see, @throws, @serial,
      @serialData
                       Invariants
   Conditions that do not vary
       At certain points in your code
   Loop invariants
       True at beginning of loop and after termination
   Class invariants
       True before and after each method call
   Method invariants
       Pre- and post conditions
       Part of “Design-by-contract”
              Class Invariants
 All constructors should place their object in
  a valid state
 All methods should leave their object in a
  valid state
     The pre-condition and post-condition together
      should guarantee this
     Better than just blind coding and testing!
 Example:    Rational: denominator > 0
              Loop Invariants
 Part   of program correctness proofs
     Mostly an academic exercise
 Often   conceptual
     Should be used more often!
     Must be commented instead of tested
 Example:    file merge
           Enforcing Invariants
 Remember,       they are design invariants
     Don’t depend on user
     If they fail, you have a bug (find early!)
 Use    Assertions
     assert statement
     Takes a boolean expression
     If false, throws an exception
     Since JDK 1.4 (javac –source 1.4 …)
           Assertion Example

public void add(Object o)
{
   if (count == data.length)
   {
      // Grow the array
      Object[] newData = new Object[data.length + CHUNK];
      System.arraycopy(data, 0, newData, 0, data.length);
      data = newData;
   }
   assert count < data.length : "stupid programmer error";
   data[count++] = o;
}
          Class “Canonical Form”
   Useful for creating “value types”
       Concrete objects that can be assigned, copied, read,
        written, etc.
       Not for all classes
   Include:
       No-arg constructor
       Override of Object.equals and Object.hashCode
       Override of Object.toString
       Implement Cloneable and Serializable
             Design Patterns
              of solutions for common
 Codifications
 design problems
     • How to allow only one object of a class (Singleton)
     • How to automate polymorphic object creation
       (Factory)
     • How to handle recursive containment relationships
       (directories/files; Composite)
 Language   independent
 Object-oriented
      The Proxy Design Pattern
A Proxy class “stands in” for an actual
 implementation class
     Holds a reference to the real implementation
     Can switch implementations at runtime
 BothProxy and the real implementations
 implement the interface of interest
     The proxy just forwards the work to the
      implementation
     Looking at Proxy




See file ProxyTest.java
                      Unit Testing
 The fundamental unit is the class
 What a programmer does to gain confidence
  that his classes meet requirements and are well
  behaved
 Test everything that could possibly break
       Rarely test getters and setters
         • Rarely should have them!
   Should be automated
       Don’t inspect detailed output
       Let the computer do the testing for you!

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:11
posted:4/20/2013
language:Unknown
pages:15