====== Effective Java ======

By Joshua Bloch

===== Chapter 1 Introduction =====

...

===== Chapter 2 Creating and Destroying Objects =====

==== Item 1: Consider static factory methods instead of contructors ====

  * Static factory method : static method that returns an instance of a class.

Advantages of static factory methods over constructors:
  - static methods have names 
  - static methods must not create a **new** object (example: ''Boolean.valueOf(boolean)'') 
    * //instance-controlled classes//
  - static methods can return instances of any subtype of their return type
    * possibility to hide subtypes from  public -> //inteface-based frameworks// 
  - class of the returned object can vary from call to call as a function of the input parameters 
  - class of the returned object need not exist when the class containing the method is written
    * //service provider frameworks//
      * -> //dependency injection// (default implementation: ''java.util.ServiceLoader'')

Limitations/Shortcomings of static factory methods:
  - the main limitation of providing only static factory methods is that classes without public or protected constructors cannot be subclassed
  - hard for programmers to find
    * to "fix" it use common names like
      * **from** - makes object from one parameter, e.g. ''Date.from(instant)''
      * **of** - makes "aggregated" object, e.g. ''Set<Rank> faceCards = EnumSet.of(JACK, QUEEN, KING);'' 
      * **valueOf** - more verbose alternative to ''from'' and ''of''
      * **instance** or **getInstance** - returns maybe not new instance
      * **create** or **newInstance** - returns new instance
      * **get//Type//** - like ''getInstance'' but is in a different class
      * **new//Type//** - like ''createInstance'' but is in a different class
      * **//type//** - concise alternative to ''get//Type//'' and ''new//Type//'', e.g. ''Collections.list()''

==== Item 2: Consider a builder when faced with many contructor parameters ====

Problem: many fields where some of them are not always necessary.

  * //telescoping constructor// pattern - many constructors with growing parameter number
    * Disadvantages
      * telescoping contructor works but it is hard to write client code, and harder to read it.

  * //JavaBeans// pattern - parameterless constructor and many setters
    * Disadvantages
      * construction is split across multiple calls, so the bean can be in inconsistent state partway through it construction
      * JavaBeans precludes the possibility to make a class immutable

Solution: Builder pattern
  * Don't create the object directly, but with the help of a builder object (typically ''static'' member of the class it creates)

<code java>
NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8).calories(100).sodium(35).carbohydrate(27).build();
</code>

  * The Builder pattern is well suited to class hierarchies.

  * //Covariant return typing// - subclass method is declared to return a subtype of the return type declared in the superclass
    * allows clients to use these builder without the need for casting

Disadvantages of Builder:
  * more verbose than telescoping constructor
    * so it should be used if we really have more than a handful of parameters

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

...
==== Item 11: Always override hashCode when you override equals ====
...