019: Effective Java for Android developers : Item 4

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:

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:

018: Effective Java for Android developers : Item 3

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:

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)

Contact us:

016: Effective Java for Android developers : Item 2

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

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:

Tip:

Contact us:

014: Effective Java for Android developers : Item 1

We’ve mentioned the book “Effective Java” by Joshua Bloch quite a few times on previous episodes. At this point, everyone knows they should have read this book (quadruple times). But it’s a dense read and everyone could use a reading buddy. Also, what does Effective Java look like through the eyes of an Android developer?

In this second installment of our Fragment (a.k.a mini-episode), we thought we’ll do our listeners a favor and help with that reading. We introduce the very first of these venerable “Items”: Consider providing static factory methods instead of constructors.

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

Download

Show Notes

Consider providing static factory methods instead of constructors

Advantages:

  1. You can control the name and thus give it much more meaningful names
  2. You are not required to create a “new” object each time they are invoked
  3. You can even return an object that’s a subtype of the return type (unlike constructors which only return class type)

Disadvantages:

  1. Classes without public or protected constructors cannot be subclassed
  2. Static factory methods are not readily distinguishable from other static methods

Takeaways

  1. “Consider” using static factory methods (not always)
  2. Use newInstance when creating Fragments [androiddesignpatterns.com]
  3. Use newIntent static factory method for creating intents inside the target activity.

Contact us:

012: Continous Integration and Collective Code Ownership

In this episode we’re trying something new. Everyone has requested more episodes of the podcast. In short, everyone wants a weekly show. So this week, we’re introducing what we call a mini-episode … or as we like to call them a “Fragment”. Fragment episodes will be shorter in length but still packed with goodness. They will range from ~7-25 minutes in length and will showcase either Kaushik, myself (Donn) or both of us.

In the first “Fragment” installment we’re going to talk about Continuous Integration (CI) and Collective Code Ownership (CCO). Donn talks about what CI is, why its important and how it benefits you and your team. He then dives right into CCO and how it can be facilitated through testing.

We hope you enjoy these new mini-episodes … aptly named … Fragments. :)

Download

Show Notes

Continuous Integration solutions:

Continuous Delivery:

Contact

Donn Felker

Kaushik Gopal