Effective Java Ch.02 - Creating and Destroying Objects

After covering basics for Java it is time to step up the game and in my opinion best way to explore advanced part of the Java is reading a defacto book that widely acknowledged in industry: Effective Java by Joshua Bloch. I will cover this book chapter by chapter and if there something that I would like to add on, I will point it, but mostly this series will be a summary for chapters and items from book.

Item 1. Prefer static methods instead of constructors

+ Unlike constructors, static methods have names. It will be self-explanatory for someone who would like to instantiate an object.

Copy 
1// constructor for prime BigInteger
2public BigInteger(int bitLength, int certainty, Random rnd)
3// usage with constructor
4BigInteger prime1 = new BigInteger(bitLength, certainty, rnd); 
5
6// static method for prime BigInteger
7public static BigInteger probablePrime(int bitLength, Random rnd)
8// usage with method
9BigInteger prime2 = BigInteger.probablePrime(bitLength, rnd);

Without examining someone can easily understand that BigInteger.probablePrime will return a prime number, but it is not the case with constructor usage.

+ Unlike constructors, static methods are not required to create a new instance each time they are called. A static method can return a cached object or preconstructed instance in order not to create repeatedly instance with same properties.

+ Unlike constructors, they can return sub-types other than return type of object.

+ The class of return type can change depend on the inputs. For instance EnumSet(no constructors only static factory methods) class in JDK will return RegularEnumSet or JumboEnumSet depending on the quantity of the input.

- If class only includes static factory methods instead of constructors, that class cannot be subclassed. However, at first this seems a downside, actually it would be beneficial since it is good to favor composition over inheritance.

- It could be hard to find static factory methods in API (not visible in Javadoc) but this can be resolved by using a naming convention. (from, of, valueOf, getInstance, newInstance, getType, newType, type)

Copy 
1Date d = Date.from(instant);
2BigInteger prime = BigInteger.valueOf(Integer.MAX_VALUE);
3BufferReader br = BufferReader.newBufferReader(); // newType
4List<String> list = Collections.list(stringList); // type

Item 2. Consider builder instead of constructor with many parameters

It is very hard to create a constructor or use a static factory method when we faced a class that uses a lot of parameter. There are some constructor implementation to overcome this issue, but each of them has a drawback.

- Telescoping constructor pattern(providing one more parameter for each constructor) does not scale well. Not only scalability is problem but also it is very hard to read by programmer and error prone.

Copy 
1public class Product {
2    int a, b, c;
3    public Product(int a) {this.a = a;}
4    public Product(int a, int b) {this. a= a; this.b = b;}
5    public Product(int a, int b, int c) {this. a = a; this.b = b; this.c = c;}
6}

- JavaBeans constructor pattern(create object with parameterless constructor and then set necessary fields) does not have disadvantages in telescoping pattern, but may be in inconsistent state while instantiating object. Also this pattern defeats immutability and thread safety.

Copy 
1Product p = new Product();
2p.setA("A");
3p.setB("B");
4p.setC("C");

+ Safety of telescoping pattern + readability of JavaBeans pattern = Builder pattern

Copy 
1public class Product {
2    private final int a;
3    private final int b;
4    private final int c;
5
6    public static class Builder {
7        // required parameters
8        private final int a;
9        private final int b;
10
11        // optional parameters with default value
12        private final int c = 0;
13
14        public Builder(int a, int b) {
15            this.a = a;
16            this.b = b;
17        }
18
19        public Builder a(int a) {this.a = a; return this;}
20        public Builder b(int b) {this.b = b; return this;}
21        public Builder c(int c) {this.c = c; return this;}
22
23        public Product build() {
24            return new Product(this);
25        }
26    }
27
28    private Product(Builder builder) {
29        this.a = builder.a;
30        this.b = builder.b;
31        this.c = builder.c;
32    }
33}
34
35// usage
36int a = 5, b = 10;
37Product p1 = new Product.Builder(a, b).build(); // c = 0;
38Product p2 = new Product.Builder(a, b).c(15).build();

Item 3. Enforce the singleton property with a private constructor or an enum type

There are two types of implementation for Singleton. In both implementation, there is only one instance can be created and always same reference to instance will be returned (with one caveat: accessibility of object can be modified reflectively).

Copy 
1// with public member field
2public Product {
3    public static final Product INSTANCE = new Product();
4    private Product() {...}
5}
6
7// with static factory method
8public Product {
9    private static final Product INSTANCE = new Product();
10    private Product() {...}
11    public Product getInstance {return INSTANCE;}
12}

Third way for a Singleton implementation is to declare a single-element enum. This approach is simpler and provides Serialization out of the box, also protected against reflection attacks.

Copy 
1public enum Product {
2    INSTANCE;
3    public void fooMethod() {...}
4}

Item 6. Avoid creating unnecessary objects

This seems pretty obvious but it is not saying that dont create object if you not going to use it. Knowing the creation detail of a particular object will make program sylish and faster. For instance, String str = new String("word") creates an String object each time it is executed, but instead String str = "word" can be used and same instance of String will be used each time.

Using primitives and boxed primivites together causes unnecessary autoboxing issues. It would be better to use primitive insted of boxed primitives(long instead of Long). However in some situtations we have to use boxed primitives, like using for java generics (List<int> is not allowed, List<Integer> is). If data is nullable, it also have to be boxed primitive, in other words wrapper class. If creating a boxed primitive required, using a static factory method instead of a constructor would be better as stated in java docs (Integer.valueOf(1)).