1. Mutability SWE 332 Fall 2011 Paul Ammann

2. SWE 3322 Data Abstraction Operation Categories Creators Create objects of a data abstraction Producers Create objects of their type based on existing objects Typically used in immutable data types Mutators Modify objects of their type Typically used in mutable data types Observers Take objects of their type as inputs and return results of other types

3. SWE 3323 Adequacy of a API Should provide enough operations so that users can manipulate objects conveniently and efficiently Should have at least three of the four category operations Should be fully populated Possible to obtain every possible abstract object state

4. SWE 3324 Some Examples Polynomials – We’ve already seen this Poly.java Complex numbers (pp 74-75 in Bloch) Complex.java Note use of producers instead of mutators

5. SWE 3325 Mutable/Immutable Transform Mutable Stack example in Bloch (page 56) Stack.java Goal: Transform to an immutable version ImmutableStack s = new ImmutableStack(); s = s.push(“cat”); s = s.push(“dog”); What do these objects look like?

6. SWE 3326 Mutator  Producer Consider a void mutator method in class C: public void mutator1(…) Corresponding producer method: public C producer1(…) Consider a non-void mutator method in class C: public S mutator2(…) Corresponding observer/producer methods are: public S observerPart(…) public C producerPart(…) Note that non-void mutator needs to be split into two methods. Example: pop() in Stack vs. pop(), top() in ImmutableStack

7. SWE 3327 Bloch 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

8. SWE 3328 5 Rules to Make a Class Immutable 1. Don’t provide any mutators 2. Ensure that no methods can be overridden (more detail…) 3. Make all fields final (more detail…) 4. Make all fields private 5. Ensure exclusive access to any mutable components (more detail…)

9. SWE 3329 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

10. SWE 33210 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

11. SWE 33211 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

12. SWE 33212 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.

13. SWE 33213 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) Static factories can cache frequently used items

14. SWE 33214 Caching Frequently Used Items Goals: Control creation of immutable objects Limit occurrence of given object to 0 or 1 Return existing object if possible, Else construct new object Flyweight Pattern Requires a table of existing items Table design is a key decision Requires hiding constructors Enables “fast” equals(), hashCode() Memory leakage may be an issue

15. SWE 33215 Flyweight example public class Word { private static Map map = new HashMap(); // Strings to Words private String s; // returns word corresponding to s public static Word makeWord (String s) // factory { if (map.containsKey(s)) return map.get(s); else …} // creates this to be Word corresponding to s private Word (String s) { this.s = s; } // why private ??? // producer to join two words public Word join (Word w1; Word w2); { String res = w1.toString() + w2.toString(); if (map.containsKey(res)) return map.get(res); else …}