3. Good Ways to Define
Class
• Class Modifier
• Should it be final
• Default Constructor
• Compiler generates one if not defined
• But, always define it explicitly
• Always invoke super() explicitly
• Visibility
• Class
• Constructor
• Singleton
5. Avoid Creating
Unnecessary Objects
• String str = new String(“hello”);
• Integer i = new Integer(10);
• Boolean b = new Boolean(true);
6. Avoid Creating
Unnecessary Objects
• String str = new String(“hello”);
• Integer i = new Integer(10);
• Boolean b = new Boolean(true);
do not waste time and memory
7. Memory Leak
• Garbage Collection
• Mark-Sweep-Compact, as an example
• Memory Leak in Java means unintentionally
retained
• Nulling out references when really necessary
• It should be the exceptional rather than the
normal
• The best way is let the variable fall out of
scope
9. Exercises
• Refine Resource/Designer/Tester
• name, age, id, gender, unit as fields
• Static class ResourceBuilder
• Which can build a kind of resource
• Manager as a Singleton
• Create memory leak
11. equals()
• Suppose x, y, z are all non-null references
• Reflexive
• x.equals(x) must return true
• Symmetric
• x.equals(y) must return true if and only if
y.equals(x)returns true
• Transitive
• if x.equals(y) returns true
• and y.equals(z) returns true
• then x.equals(z) must return true
• Consistent
• x.equals(y) must consistently return the same result
12. hashCode()
• Equal objects must have equal hash
codes
• If equals() is overridden,
hashCode() must be overridden
• Failed to do so, there will be trouble
working with hash-based collections
13. toString()
• Default toString returns something like
“Designer@163b91”
• A good toString() implementation
• Makes the class pleasant to use
• Should return all interesting information
contained in the object
• Specifies the format if necessary and stick to it
• Provides programmatic access to the returned
string if necessary
14. Exercises
• Add equals() and hashCode() to
Designer and Tester
• Consider about how to write a “correct”
equals() and “perfect” hashCode()
• Add toString() to Designer and
Tester
• A parse() method in Resource to
parse a Designer or Tester
16. How to Define Java Bean
• What is Java Bean?
• Data structure
• Object representative
• The ingredients
• Fields
• Setters and Getters
• Optional equals()/hashCode(), and
toString()
17. Prefer Interface to
Abstract Class
• No multiple inheritance in Java
• Pros
• Easily retrofitted to implement a new interface
• Ideal for defining mixins: Comparable for example
• Allow construction of nonhierarchical type framework: someone
can be both a singer and songwriter
• Cons
• Not off-the-shelf to use
• Once released and widely implemented, almost impossible to change
• Skeletal implementation combining interface and abstract class
• Map/AbstractMap
• Set/AbstractSet
18. Use Interfaces Only to
Define Types
• Constant interface pattern
• Nothing but only constants defined
• Use noninstantiable class instead
19. Use Interfaces Only to
Define Types
IT
ER DO
• Constant interface pattern NEV
• Nothing but only constants defined
• Use noninstantiable class instead
20. Use Interfaces Only to
Define Types
IT
ER DO
• Constant interface pattern NEV
• Nothing but only constants defined
• Use noninstantiable class instead
21. Prefer Class Hierarchies
to Tagged Classes
• What is tagged class?
• A class with certain field to indicate
the actual type
• Tagged class are verbose, error-prone,
and inefficient
• Unfortunately, tagged class is not OO
22. Favor Static Member
Classes over Non-static
• The class defined in another class
• Non-static member class can
• Obtain reference to the enclosing instance using the qualified
this construct
• Static member class can
• Be instantiated in isolation from an instance of its enclosing
class
• Make it a static member class
• Whenever it does not require access to an enclosing instance
• When it should be instantiated from outside of the enclosing
class
• Get rid of time and space costs to store reference to its
enclosing instance
23. Exercises
• Try static and non-static member
class
• Define the class
• Instantiate it from outside the
enclosing class
• Obtains reference of the enclosing
instance
25. Generics
• Don’t use raw types in new code
• Favor generic types
• List<String>, instead of List
• Favor generic method
• List<T> hello(T word), instead
of List<Object> hello(Object
word)
31. General Programming
• Minimize the scope of local variables
• Mark variable as final whenever possible
• Prefer for-each loop
• Know and use the libraries
• String concatenation, StringBuilder
and StringBuffer
• Refer to object by interface
36. Checked and Unchecked
• Checked
• Required to catch
• Can reasonably be expected to recover
• Unchecked
• Not required to catch
• Generally, not recoverable
37. Avoid Unnecessary of
Checked Exception
• Checked exception is great
• Forcing programmer to deal with exception
• Enhancing reliability
• Overusing it will make API less pleasant to use
• If contract can be made between API and client, no
need to use checked exception
• For example, wrong format of argument
• A method provided to check exceptional
condition
38. Favor Standard
Exceptions
Exception Occasion for Use
IllegalArgumentException null value is not good to go
• Before go creating your
own exception type, favor IllegalStatementException
instance state is not OK for
method invocation
standard exception
NullPointerException null value is not prohibited
• Java platform libraries
provide a basic set of IndexOutOfBoundsException input parameter is out of range
unchecked exceptions concurrent modification of an object
ConcurrentModificationException
has been detected where it is prohibited
UnsupportedOperationException object does not support method
39. Use Exception Only for
Exceptional Conditions
try {
int i = 0;
while (true) {
range[i++].climb();
}
} catch (ArrayIndexOutOfBoundsException e) {
...
}
• Exception should only be used for exceptional conditions
• Well designed API must not force its clients to use
exception for ordinary control flow
40. Chaining Exceptions
try {
...
} catch (AException e) {
throw new BException(“more description”, e);
}
• Preserve exception stack trace
• Complete information when exception
happens
• A bad example is FDSStandardException
41. Chaining Exceptions
try {
...
} catch (AException e) {
}
throw new BException(“more description”,
e
);
• Preserve exception stack trace
• Complete information when exception
happens
• A bad example is FDSStandardException
42. How to Define Own
Exception
• Extend from Exception or RuntimeException
• Provide serialVersionUID
• Override all constructors
• Default
• With detail message only
• With detail message and cause
• With cause only
• Add you own fields if necessary, for example error
code
43. Other Best Practice
• Document all exceptions thrown by each
method
• Always set detail message
• Don’t catch and ignore exception, at least
write down a comment
44. Exercises
• Define own checked and unchecked
exceptions
• Write methods throwing the above
exceptions
• Write client code to invoke the above
methods