Effective Java, Chapter-2 Creating and Destroying Objects: Summary

Item 1 (Consider Static factory methods instead of constructors)

• Static factory methods have names unlike constructors.
• Unlike constructors they are not required to create a new object every time they are invoked.
• Unlike constructors they can return an object of any sub type of their return type.

• Immutable class:-Immutable class is the one whose object can't be modified once created.
• Any modification in the object results in new immutable object.
• Immutable objects are thread safe.i.e can be shared without synchronization in concurrent environment.

Service provider framework  of JDBC

1. service interface:-It provides implement.  ex:Connection
2. provider registration API:-system uses it to register implementation.   ex.:DriverManager.registerDriver()
3. service access API:-client use to obtain an instance of the service.  ex.:DriverManager.getConnection()
4. service provider interface:-providers implement it to create instances of their service implementation.  

ex.:Driver

• The main disadvantage of providing only static factory methods is that classes without public or protected
• constructors cannot be sub-classed.
• For example, it is impossible to subclass any of the convenience implementation classes in the Collections Framework.

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

• traditional programmers have used telescoping constructor pattern which does not scale well.
• A second alternative when you are faced with many constructor parameters is the Java-beans pattern, in which you call a parameter less constructor to create the object and then call setter methods to set each required parameter and each optional parameter of interest
• A Java-Bean may be in an inconsistent state partway through its construction.
• build patters are more safer than java beans.
• Inner class in java are associated with an outer class while nested static class is not associated with any outer class object, so it's instance can be created independently.

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

• Singleton class can be instantiated exactly once. Implemented by making the constructor private.
• In serialization aspect, to maintain the singleton property of a class you have to declare all instance field transient and provide a readResolve() method. Otherwise, each time a serialized object is deserialized a new instance will be created.
• A single element enum type is the best way to implement a singleton.

Item 4 (Enforce noninstantiability with a private constructor)

• A class having private constructor can't be extended or subclassed.
• Attempting to enforce non-instantiability by making a class absract does not work.

Item 5 (Avoid creating unnecessary objects)

• String s = new String("Ashish"); //this is not desirable
• String s = "Ashish"; //this should be adopted instead
• It is possible to avoid unnecessary initialization by lazy initialization.

Item 6 (Eliminate obsolete object references)

• If a stack grows and shrinks the popped off objects will not be garbage collected even if stack has no references to it, this is because a stack maintains obsolete references to these objects.
• An obsolete reference is simply a reference that will never be dereferenced again.
• Memory leaks in garbage collected languages are harmful. If an object reference is unintentionally retained, not only is that object excluded from garbage collection, but so too are any objects referenced by that object. So, even if few objects references are unintentionally retained, many, many objects references may be prevented from garbage collection , with potentially large impact on performance.
• Null out the references once they become obsolete.
• Whenever a class manages its own memory, the programmer should be aware of memory leaks. 
• Whenever an element is freed, any object reference contained in that element should be manually nulled out.
• Another sources of memory leaks are caches and callbacks and listeners.

Item 7 (Aviod Finalizers)

• Finalizers are often unpredictable, often dangerous, and generally unnecessary.
• You should not do anything time critical in finalizers because it can arbitrarily takes long between the time that an object becomes unreachable and the time that its finalizer is executed.
• Creating and Destroying an object in Finalizer severely slows down the perfomances.
• So, instead of finalizers you should provide explicit termination method.
• Typical example is close method on InputStream, OutputStream, and java.sql.Connection. Another is cancel method on java.util.Timer.
• Explicit termination methods are typically used in combination with the try-finally construct to ensure termination.
• Finalizers can act as a 'safety net' in case the owner of an object fails to call its explicit termination method.
• A second legitimate use of finalizers concerns objects with native peers.