Singer and Android developer Donn Felker explores Joshua Bloch’s fourth Item: Enforce noninstantiability with a private constructor.

Stay tuned, cause we got more of these quick ones coming.

Download

Show Notes:

• Effective Java (2nd Edition) – Joshua Bloch

Enforce noninstantiability with a private constructor.

Examples where you don’t want class to be instantiated

1. class that groups static methods and static fields (Util like classes think java.lang.Math/java.util.Arrays)
2. class that groups static methods (including factory methods) for objects implementing specific interfaces (think java.util.Collections)
3. class that group methods on a final class (vs. extending the class)

Considerations

• Makes no sense to instantiate such “Util” classes
• Private constructors prevent instantiation
• Important side effect: prevents subclassing

Contact us:

• @fragmentedcast [twitter.com]
• @donnfelker [twitter.com]
• @kaushikgopal [twitter.com]

In this mini Fragment, we introduce Joshua’s third Item: Enforce the Singleton property with a private constructor or an enum type.

Stay tuned for more items from our “Effective Java for Android developers” Fragment series.

Download

Show Notes:

• Effective Java (2nd Edition) – Joshua Bloch

Enforce the Singleton property with a private constructor or an enum type

Approaches

1. Create a public static final INSTANCE variable and privatize constructor
2. Same as 1 but privatize variable and expose access with provide factory method getInstance
3. Single element Enums

Considerations

• First two approaches are open to Serialization attacks (deserializing creates new instance)
• To protect from those declare the fields transient + provide readResolve method
• Enums are concise, provide free serialization and ironclad Singleton guarantees and are functionally equivalent to first approach

Supplemental reading (for the diligent ones that follow shownotes)

• Dianne Hackborn regretting exposing the base Application class
• DH again saying Application is a Singleton with crappier semantics
• Elvis sightings

Contact us:

• @fragmentedcast [twitter.com]
• @donnfelker [twitter.com]
• @kaushikgopal [twitter.com]

In our third Fragment installment, we introduce Josh’s second Item: Consider a builder when faced with many constructor parameters.

Stay tuned for more items from our “Effective Java for Android developers” Fragment series.

Download

Show Notes

• Effective Java (2nd Edition) – Joshua Bloch

Consider a builder when faced with many constructor parameters

Telescoping Constructor Pattern

• Provide constructor with only required parameters, another with a single optional param, a third with 2 optional params… and so on.
  • Advantage: Works well for small number of parameters
  • Disadvantage: Does NOT scale well

JavaBeans Pattern

• Call parameterless constructor to create the object; then call setter methods to set required parameter and each optional param of interest.
  • Advantage: Scales well, easy (but wordy) to read resulting code
  • Disadvantage: Allows inconsistency (if all required params not called); impossible to make classes immutable if using this pattern.

Builder pattern

• winner!
  • Advantage: Simulates named optional parameters; allows immutable objects to be constructed; flexible
  • Disadvantage: more ceremony to actually construct the Builder Class and finally use.

Example usage from Android source:

• AlertDialog Builder [androidxref.com]

Tip:

• Use IntelliJ to generate your Builders easily

Contact us:

• @fragmentedcast [twitter.com]
• @donnfelker [twitter.com]
• @kaushikgopal [twitter.com]