Effective Java, Chapter 4: Classes and Interfaces Last Updated: Fall 2011

Classes and Interfaces 2 Agenda Material From Joshua Bloch Effective Java: Programming Language Guide Cover Items 14 through 20 “Classes and Interfaces” Chapter Was Items 12 through 18 in 1 st Edition Moral: Inheritance requires careful programming

Classes and Interfaces 3 Item 13: Minimize Accessibility of Classes and Members Standard advice for information hiding/encapsulation Decouples modules Allows isolated development and maintenance Java has an access control mechanism to accomplish this goal

Classes and Interfaces 4 Make Each Class or Member as Inaccessible as Possible Standard list of accessibility levels private package-private (aka package friendly) protected public Huge difference between 2 nd and 3 rd package-private: part of implementation protected: part of public API

Classes and Interfaces 5 Exception: Exposing Constants Public constants must contain either primitive values or references to immutable objects Wrong – Potential Security Hole: public static final Type[] VALUES = {…}; Problem: VALUES is final; entries in VALUES are not!

Classes and Interfaces 6 Exposing Constants - Solutions Correct: private static final Type[] PRIVATE_VALUES = {…}; public static final List VALUES = Collections.unmodifiableList(Arrays.asList (PRIVATE_VALUES)); Also Correct: private static final Type[] PRIVATE_VALUES = {…}; public static final Type[] values() { return (Type[]) PRIVATE_VALUES.clone(); }

Classes and Interfaces 7 Item 14: In Public Classes, Use Accessors, Not Public Fields Avoid code such as: class Point { public double x; public double y; } No possibility of encapsulation Also, public mutable fields are not thread safe Use get/set methods instead: public double getX() { return x; } public void setX(double x) { this.x = x} Advice holds for immutable fields as well Limits possible ways for class to evolve

Classes and Interfaces 8 Example: Questionable Use of Immutable Public Fields public final class Time { private static final int HOURS_PER_DAY = 24; private static final int MINUTES_PER_HOUR = 60; public final int hour; // Not possible to change rep for class public final int minute; // But we can check invariants, since fields are final public Time ( int hour, int minute ) { if (hour = HOURS_PER_DAY) throw new IllegalArgumentException(“Hour: “ + hour); if (minute = MINUTES_PER_HOUR) throw new IllegalArgumentException(“Minute: “ + minute); this.hour = hour; this.minute = minute; } // Remainder omitted }

Classes and Interfaces 9 Item 15: Minimize Mutability Reasons to make a class immutable: Easier to design Easier to implement Easier to use Less prone to error More secure Easier to share Thread safe

Classes and Interfaces 10 Example: Class Complex public final class Complex { private final double re; private final double im; public Complex (double re, double im) { this.re = re; this.im = im;} // Accessors with no corresponding mutators public double realPart() { return re; } public double imaginaryPart() { return im; } // Note standard “producer” pattern public Complex add (Complex c) { return new Complex (re + c.re, im + c.im); } // similar producers for subtract, multiply, divide // implementations of equals() and hashCode() use Double class }

Classes and Interfaces 11 5 Rules to Make a Class Immutable Don’t provide any mutators Ensure that no methods can be overridden (more detail…) Make all fields final (more detail…) Make all fields private Ensure exclusive access to any mutable components (more detail…)

Classes and Interfaces 12 Rule 2: No Overridden Methods Prevents careless or malicious subclasses from compromising the immutable behavior of the class How to implement Make class final (easiest) Make methods final (allows subclassing) Make all constructors private or package- private Requires static factories, which are better anyway

Classes and Interfaces 13 Example: Static Factory for Complex Class // Note that this version is no longer a final class public class Complex { private final double re; private final double im; // private constructor shuts off subclassing // package friendly constructor would allow local subclassing private Complex (double re, double im) { this.re = re; this.im = im; } // Static factory – could have lots of possible implementations public static Complex valueOf (double re, double im) { return new Complex (re, im); } // Remainder as before }

Classes and Interfaces 14 Rule 3: Make All Fields Final Clearly expresses intent System enforcement of immutability Issues with object instantiation and thread access Sometimes, making fields final is too strong Lazy initialization may be preferable

Classes and Interfaces 15 Rule 5: Exclusive Access to Mutable Components Never initialize a mutable field to a client provided reference Never return a reference to a mutable field Make defensive copies Note what this says about mutability Performance advantage often illusory!

Classes and Interfaces 16 Typical Transformation Typical method in mutable class Foo: public void foo(T1 t1, T2, t2, …) {modify “this”} Immutable version of Foo: public Foo foo(T1 t1, T2, t2, …) { Foo f = … … return f; } Functional programming vs. procedural programming. See Poly example

Classes and Interfaces 17 Disadvantage: Performance Typical approach: Provide immutable class Provide mutable companion class for situations where performance is an issue Clients choose on performance needs Example in Java Library: String (Immutable) StringBuilder (Companion Mutable Class) StringBuffer (Deprecated Companion Mutable Class) Static factories can cache frequently used items

Classes and Interfaces 18 Item 16: Favor Composition over Inheritance Issue ONLY for implementation inheritance Interface inheritance does NOT have these problems Interface inheritance is better for lots of reasons… Inheritance breaks encapsulation! Difficult to evolve superclass without breaking subclasses Difficult for superclass to maintain invariants in face of malicious/careless subclass

Classes and Interfaces 19 Example: Broken Subtype // This is very common, but broken public class InstrumentedHashSet extends HashSet private int addCount = 0; // add() calls public InstrumentedHashSet() {} public InstrumentedHashSet(Collection c) { super(c); } public boolean add(E o) { addCount++; return super.add(o); } public boolean addAll(Collection c) { addCount += c.size(); return super.addAll(c); } // accessor method to get the count public int addCount() { return addCount; } }

Classes and Interfaces 20 Broken Example, continued So, what’s the problem? InstrumentedHashSet s = new InstrumentedHashSet (); s.addAll(Arrays.asList(“Snap”, “Crackle”, “Pop”)); What does addCount() return? 3? 6? Internally, HashSet addAll() is implemented on top of add(), which is overridden. Note that this is an implementation detail, so we can’t get it right in InstrumentedHashSet

Classes and Interfaces 21 Source of Difficulty: Overridden Methods Overriding methods can be tricky May break the superclass invariant Overridden method does not maintain invariant May break subclass invariant New methods may be added to superclass What if new method matches subclass method? Also, recall problems with equals() and hashCode()

Classes and Interfaces 22 Composition Fortunately, composition solves all of these problems – even though it makes the programmer work harder // Inheritance public Class Foo extends Fie {…} // Composition public class Foo { private Fie f = …; // Note: forwarded methods... }

Classes and Interfaces 23 Revisiting the Example // Note that an InstrumentedSet IS-A Set public class InstrumentedSet implements Set { private final Set s; private int addCount = 0; public InstrumentedSet (Set s) { this.s = s} public boolean add(E o) { addCount++; return s.add(o); } public boolean addAll (Collection c) { addCount += c.size(); return s.addAll(c); } // forwarded methods from Set interface }

Classes and Interfaces 24 A More Elegant Version // Wrapper class – uses composition in place of inheritance public class InstrumentedSet extends ForwardingSet { private int addCount = 0; public InstrumentedSet (Set s) { super(s); public boolean add(E e) { addCount++; return super.add(e); public boolean addAll(Collection c) { addCount += c.size(); return super.add(c); } public int getAddCount() { return addCount; } } // Reusable Forwarding Class public class ForwardingSet implements Set { private final Set s; public ForwardingSet (Set s) { this.s = s;} public void clear() { s.clear();} public boolean contains(E o) { return s.contains(o);} // plus forwards of all the other Set methods }

Classes and Interfaces 25 This is Cool! Consider temporarily instrumenting a Set Note that Set is an interface static void f(Set s) { InstrumentedSet myS = new InstrumentedSet (s); // use myS instead of s // all changes are reflected in s! }

Classes and Interfaces 26 A Variation That Doesn’t Work // Note that this uses the “basic” version, // but extending a “ForwardingCollection” doesn’t // work either, for the same reason public class InstrumentedCollection implements Collection { private final Collection c; private int addCount = 0; public InstrumentedCollection (Collection c) { this.c = c} public boolean add(E o) {…} public boolean addAll (Collection c) {…} // forwarded methods from Collection interface public boolean equals(Object o) { return c.equals(o); } // Now, we’re dead! }

Classes and Interfaces 27 This is no longer Cool! Consider temporarily instrumenting a Set Note: Set is a subtype of Collection Set s = new HashSet (); InstrumentedCollection t = new InstrumentedCollection (s); s.equals(t) // t is not a Set, so false t.equals(s) // t.c == s, so true Issue: Set has a uniform equals() contract Collection does not (and should not…) Keep this in mind when using this model.

Classes and Interfaces 28 Item 17: Design and Document for Inheritance Or else prohibit it. First, document effects of overriding any method Document “self use”, as in InstrumentedHashSet example This is “implementation detail”, but unavoidable, since subclass “sees” implementation. Inheritance violates encapsulation!

Classes and Interfaces 29 Efficiency May Require Hooks protected methods may be required for efficient subclasses. Example: protected removeRange() method in AbstractList Not of interest to List clients Only of interest to implementers of AbstractList – provides fast clear() operation Alternative – O(n^2) clear() operation

Classes and Interfaces 30 Inheritance is Forever A commitment to allow inheritance is part of public API If you provide a poor interface, you (and all of the subclasses) are stuck with it. You cannot change the interface in subsequent releases. TEST for inheritance How? By writing subclasses

Classes and Interfaces 31 Constructors Must Not Invoke Overridable Methods // Problem – constructor invokes overridden m() public class Super { public Super() { m();} public void m() {…}; } public class Sub extends Super { private final Date date; public Sub() {date = new Date();} public void m() { // access date variable} }

Classes and Interfaces 32 What Is the Problem? Consider the code Sub s = new Sub(); The first thing that happens in Sub() constructor is a call to constructor in Super() The call to m() in Super() is overridden But date variable is not yet initialized! Further, initialization in Super m() never happens! Yuk!

Classes and Interfaces 33 Inheritance and Cloneable, Serializable Since clone() and readObject() behave a lot like constructors, these methods cannot invoke overridable methods either. Problem – access to uninitialized state For Serializable readResolve(), writeReplace() must be protected, not private Or they will be ignored in subclass.

Classes and Interfaces 34 Bottom Line Be sure you want inheritance, and design for it, or Prohibit inheritance Make class final, or Make constructors private (or package- private)

Classes and Interfaces 35 Item 18: Prefer Interfaces to Abstract Classes Existing classes can be easily retrofitted to implement a new interface Same is not true for abstract classes due to single inheritance model in Java Interfaces are ideal for “mixins” Example: Comparable interface Interfaces aren’t required to form a hierarchy Some things aren’t hierarchical

Classes and Interfaces 36 More Interfaces Wrapper idiom a potent combination with interfaces See ISet example Possible to provide skeletal implementations for interfaces java.util does this with AbstractCollection, AbstractSet, AbstractList, and AbstractMap

Classes and Interfaces 37 Example for AbstractList // Concrete implementation built on abstract skeleton static List intArrayAsList(final int[] a) { if (a == null) throw new NPE(…); // Note anonymous class return new AbstractList() { public Object get(int i) { return new Integer(a[i]); } public int size() { return a.length; } public Object set(int i, Object o) { int oldVal = a[i]; a[i] = ((Integer) o).intValue(); return new Integer(oldVal); } }; }

Classes and Interfaces 38 This Implementation Does a Lot! The List interface includes many methods. Only 3 of them are explicitly provided here. This is an “anonymous class” example Certain methods are overridden Note that it is possible to add a method to an abstract class in a new release It is not possible to add a method to an interface

Classes and Interfaces 39 Item 19: Use Interfaces Only to Define Types Example that fails the test: “Constant” interface – avoid public interface PhysicalConstants { static final double AVOGADROS = } Why is this bad? Users of a class that implements this interface don’t care about these constants! Think about the client, not the implementor

Classes and Interfaces 40 Alternative to Constants in Interfaces Constant utility class public class PhysicalConstants { public static final double AVOGADROS =... }

Classes and Interfaces 41 Item 20: Prefer Class Hierarchies to Tagged Classes //Tagged Class – vastly inferior to a class hierarchy class Figure { enum Shape { RECTANGLE, CIRCLE }; final Shape shape; // Tag field double length; double width; // for RECTANGLE double radius; // for CIRCLE Figure (double length, double width) {…} // RECTANGLE Figure (double radius) {…} // CIRCLE double area() { switch (shape) { // Gag! Roll-your-own dispatching! case RECTANGLE: return length*width; case CIRCLE: return Math.PI*(radius * radius); default: throw new AssertionError(); }

Classes and Interfaces 42 Item 20 Continued: A much better solution //Class hierarchy replacement for a tagged class abstract class Figure { // Note: NOT instantiable! abstract double area(); } class Circle extends Figure { final double radius; Circle(double rad) { radius = rad; } double area() { return Math.PI * (radius * radius); } class Rectangle extends Figure { final double length; final double width; Rectangle (double len; double wid) { length = len; width = wid; } double area() { return length * width; }

Classes and Interfaces 43 Item 21: Use Function Objects to Represent Strategies In Java, you can’t pass functions directly Only Objects can be arguments So, pass Objects to pass functions // Strategy interface public interface Comparator { public int compare ( T t1, T t2); } // Question: Is compare() consistent with equals() Class StringLengthComparator implements Comparator { private StringLengthComparator() {} public static final StringLengthComparator INSTANCE = new StringLengthComparator(); public int compare (String s1, String s2) { return s1.length – s2.length; }

Classes and Interfaces 44 Item 22: Favor Static Member Classes Over Nonstatic Nested classes Defined within another class Four flavors Static member class Nonstatic member class (inner) Anonymous class (inner) Local class (inner)

Classes and Interfaces 45 Static vs NonStatic Static requires no connection to enclosing instance. Nonstatic always associated with enclosing instance Possible performance issue Possible desire to create by itself Hence recommendation to favor static See Iterator implementations

Classes and Interfaces 46 Local classes Declared anywhere a local variable may be declared Same scoping rules Have names like member classes May be static or nonstatic (depending on whether context is static or nonstatic)