Effective Java (Remarked) - Creating and Destroying Objects

Item 1: Consider static factory methods instead of constructors (readability)

One advantage of static factory methods is that, unlike constructors, they have names. A second advantage of static factory methods is that, unlike constructors, they are not required to create a new object each time they’re invoked. A third advantage of static factory methods is that, unlike constructors, they can return an object of any subtype of their return type. A fourth advantage of static factory methods is that they reduce the verbosity of creating parameterized type instances. 

When use? to create a new object with more accuracy rather a constructor.

Item 2: Consider a builder when faced with many constructor parameters (readability)

It is a good way to create objects especially with optional arguments. Static factories and constructors share a limitation: they do not scale well to large numbers of optional parameters. In summary, the Builder pattern is a good choice when designing classes whose constructors or static factories would have more than a handful of parameters, especially if most of those parameters are optional.

When use? to build a object with or without a optional parameter.

Item 3: Enforce the singleton property with a private constructor or an enum type (stability)

A singleton is simply a class that is instantiated exactly once. This approach is functionally equivalent to the public field approach, except that it is more concise, provides the serialization machinery for free, and provides an ironclad guarantee against multiple instantiation, even in the face of sophisticated serialization or reflection attacks.

When use? singleton pattern is needs.

Item 4: Enforce noninstantiability with a private constructor (stability)

Attempting to enforce noninstantiability by making a class abstract does not work. The class can be subclassed and the subclass instantiated. Furthermore, it misleads the user into thinking the class was designed for inheritance (Item 17). There is, however, a simple idiom to ensure noninstantiability. A default constructor is generated only if a class contains no explicit constructors, so a class can be made noninstantiable by including a private constructor.

When use? utility noninstantiate class.

Item 5: Avoid creating unnecessary objects (performance)

It is often appropriate to reuse a single object instead of creating a new function- ally equivalent object each time it is needed. Reuse can be both faster and more stylish. An object can always be reused if it is immutable (Item 15). Note that the penalty for reusing an object when defensive copying is called for is far greater than the penalty for needlessly creating a duplicate object. Failing to make defensive copies where required can lead to insidious bugs and security holes; creating objects unnecessarily merely affects style and performance.

When use? all the time.

Item 6: Eliminate obsolete object references (performance, stability)

Because memory leaks typically do not manifest themselves as obvious failures, they may remain present in a system for years. They are typically discovered only as a result of careful code inspection or with the aid of a debugging tool known as a heap profiler. Therefore, it is very desirable to learn to anticipate problems like this before they occur and prevent them from happening.

When use? all the time.

Item 7: Avoid finalizers (performance, stability)

Finalizers are unpredictable, often dangerous, and generally unnecessary.

Their use can cause erratic behavior, poor performance, and portability problems. In summary, don’t use finalizers except as a safety net or to terminate noncritical native resources. In those rare instances where you do use a finalizer, remember to invoke super.finalize. If you use a finalizer as a safety net, remember to log the invalid usage from the finalizer. Lastly, if you need to associate a finalizer with a public, nonfinal class, consider using a finalizer guardian, so finalization can take place even if a subclass finalizer fails to invoke super.finalize.

When use? all the time.