User Tools

Site Tools


effective_java

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
effective_java [2020/05/07 09:33] – [Item 1: Consider static factory methods instead of contructors] kalaschnikoweffective_java [2020/05/13 16:33] (current) – [Item 2: Consider a builder when faced with many contructor parameters] kalaschnikow
Line 1: Line 1:
 +====== 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 ====
 +...