Downloaded 12 times
Uploaded byRohit Vaidya
Effective java - Creating and Destroying Objects
Creating & Destroying Objects The document discusses best practices for object creation and destruction in Java. It covers 6 items: 1) using static factory methods instead of constructors, 2) using builders for classes with many constructor parameters, 3) enforcing singleton properties with private constructors or enums, 4) enforcing non-instantiability with private constructors, 5) avoiding unnecessary object creation, and 6) eliminating obsolete references to avoid memory leaks. The document provides examples and explanations for each best practice.
Effective java - Creating and Destroying Objects
- 1. Creating & DestroyingObjects Reference: Effective Java - Joshua Bloch -Rohit Vaidya
- 2. Agenda ● Discuss overobject creation and destruction ● Study best practices ● Use profiler to go over how good or bad code is
- 3. Items ● Item1 ConsiderStatic factory methods ● Item2 Consider builders ● Item3 Enforce Singleton,private constructors or enum type ● Item4 Enforce non-instanstiability private constructors ● Item5 Avoid creating unnecessary Objects ● Item6 Avoid finalizers
- 4. Creating Objects ● Whenand how to create Objects ● How to avoid creating them ● Ensure they are destroyed ● Cleanup before destruction
- 5. Item 1 Consider staticfactory methods instead of constructors
- 6. Item 1 Premise ●Create an object ● Implicitly not create objects when unnecessary ● Ability to create a object of subtype
- 7. Item1 - Solution ●Provide static factory methods ● Advantages – Unlike constructors they have names – Not required each time you create a new object ● E.g: Boolean.valueof(boolean) – never creates a object – Can return a object of any subtype of return type ● Disadvantages – Classes without public or protected members cannot be sub classed ● This has a hidden advantage – Not easily distinguishable from other static factory methods
- 8. Item 2 Consider builderwhen faced with many constructor parameter
- 9. Item 2 Premise ●Many parameter constructors or static factories do not scale – Hell for the client ● Telescoping constructor pattern – Why its bad? Hard to read/write code ● Java Beans pattern – Inconsistent path way through its construction – Does not allow your class to be immutable. Setters!!!
- 10. Item 2 Solution ●Builders!!! – Makes your class immutable. Important – Makes it easy to read and write code – Builders allows you to set invariants. If Invariant is not satisfied throw IllegalArgumentException – Builders can have multiple varargs where as constructor only one ● “The Builder pattern is a good choice when designing classes whose constructors or static factories would have more than a handful of parameters"
- 11. Item 3 Enforce thesingleton property with a private constructor or an enum Type
- 12. Item 3 -Premise ● Make a class singleton ● Avoid reflection attacks on singleton classes made singleton conventionally – AccessibleObject.setAccessible ● Serialization making multiple copies of the same object
- 13. Item3-Solution ● Have apublic static final field which contains the instance – Class declaration makes it evident, its singleton ● Have a private static field with the factory method returning the instance – The factory API can be easily modified to make it non singleton ● Use enum to create singletons ● Have the constructor throw an exception – to solve Reflection problem ● Make all the field transient and implement a resolveObject API to resolve serialization problem
- 14. Item 4 Enforce non-instantiabilitywith a private constructor
- 15. Item 4 –Premise ● Want to write a class which is a group of static methods ● Write group of methods on primitive values or arrays. e.g: java.util.Arrays java.lang.Math ● Don't create an object where its non-sensical to do so – Utility Classes
- 16. Item 4 -Solution ● Simple: Add a private constructor. ● If you don't? - A default constructor gets generated. You can still do a X obj = new X(); //This is bad. ● You have instantiated a class when not required ● Positive Side Effect: Can't be subclasses
- 17. Item 5 Avoid creatingunnecessary Objects
- 18. Premise ● Reuse objects ●Consequently avoid creating new instances ● Reuse immutable objects and mutable objects ● Avoid accidentally creating objects
- 19. Solution ● String poolof-course!!! – String s = new String(“string”);//Code smell ● Use static factory methods for object creation – Boolean(String) //Code smell ● Reuse Mutable Objects. Assuming these objects are not expected to be mutated ● Safe to reuse immutable objects ● Beware of auto-boxing
- 20. Item 5 -Snippets
- 21.
- 22.
- 23. Item 5 –Fix it
- 24. Item 5 AfterFix
- 25. Item 5 –After fix
- 26. Item 6 Eliminate ObsoleteReferences
- 27. Premise ● Need tounderstand Memory Leaks first ● Don't misunderstand Java Garbage collector cleans it all – Obsolete References to blame. – References that will never be referenced again ● Memory Leaks in caches ● Listeners and their callbacks, another culprit – API exposes where client register a call back but no mechanism to de-register them.
- 28. Solution ● Nullify obsoletereferences ● Don't make it a norm and use judiciously. Best way to let variable fall out of scope ● Cache – WeakHashMap Enteries will be removes automatically after they become obsolete ● Store only weak references to callbacks
- 29. Avoid finalizers ● Unpredictable,dangerous and unnecessary ● Implementation of finalizers is JVM implementation dependent ● When finalizer will be invoked is a function of the VM's garbage collection algorithm ● System.gc does not guarantee finalizers execute ● Performance penalty with finalizers ● Don't rely on finalizer to ensure program correctness. Your design is flawed ● Instead – Make use of explicit termination methods. try catch finally.
- 30.