Design Issues

Where to put class definitions  What goes in a source file? At most 1 public class At most 1 public class Other “helper” classes as needed (list/node) Other “helper” classes as needed (list/node) All classes have a unique.class file All classes have a unique.class file  What goes in a package? Related classes, duh Related classes, duh Many files, though Many files, though

Arranging Class Members  Pick a style and stick with it In other words, who cares? In other words, who cares?  Many like public-to-private continuum So can see class interface first So can see class interface first  With javadoc, these aren’t crucial issues  Be readable! Use white space (indent, etc.) Use white space (indent, etc.) Not too many comments! (“Say it in code”) Not too many comments! (“Say it in code”)

Avoid Public Fields  At all costs! Except static final primitives (constants) 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 Can throw off object state

javadoc  “javadoc” command  Documents classes by reading /**-style comments Immediately before class and method definitions Immediately before class and method definitions  Recognizes

Invariants  Conditions that do not vary At certain points in your code At certain points in your code  Loop invariants True at beginning of loop and after termination True at beginning of loop and after termination  Class invariants True before and after each method call True before and after each method call  Method invariants Pre- and post conditions Pre- and post conditions Part of “Design-by-contract” 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 The pre-condition and post-condition together should guarantee this Better than just blind coding and testing! Better than just blind coding and testing!  Example: Rational: denominator > 0

Loop Invariants  Part of program correctness proofs Mostly an academic exercise Mostly an academic exercise  Often conceptual Should be used more often! Should be used more often! Must be commented instead of tested Must be commented instead of tested  Example: file merge

Enforcing Invariants  Remember, they are design invariants Don’t depend on user Don’t depend on user If they fail, you have a bug (find early!) If they fail, you have a bug (find early!)  Use Assertions assert statement assert statement Takes a boolean expression Takes a boolean expression If false, throws an exception If false, throws an exception Since JDK 1.4 (javac –source 1.4 …) 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. Concrete objects that can be assigned, copied, read, written, etc. Not for all classes Not for all classes  Include: No-arg constructor No-arg constructor Override of Object.equals and Object.hashCode Override of Object.equals and Object.hashCode Override of Object.toString Override of Object.toString Implement Cloneable and Serializable Implement Cloneable and Serializable

Design Patterns  Codifications of solutions for common design problems How to allow only one object of a class (Singleton)How to allow only one object of a class (Singleton) How to automate polymorphic object creation (Factory)How to automate polymorphic object creation (Factory) How to handle recursive containment relationships (directories/files; Composite)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 Holds a reference to the real implementation Can switch implementations at runtime Can switch implementations at runtime  Both Proxy and the real implementations implement the interface of interest The proxy just forwards the work to the implementation 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 test getters and setters Rarely should have them!Rarely should have them!  Should be automated Don’t inspect detailed output Don’t inspect detailed output Let the computer do the testing for you! Let the computer do the testing for you!