Skip to content

Instantly share code, notes, and snippets.

@andersonleite
Created August 19, 2015 14:52
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save andersonleite/03583bbbea7c7eb6a2f4 to your computer and use it in GitHub Desktop.
Save andersonleite/03583bbbea7c7eb6a2f4 to your computer and use it in GitHub Desktop.
notes from effective java
Effective Java
==============
[Creating and Destroying Objects]
/ Consider static factory methods instead of constructors
+ they have names
+ they are not required to create a new object each time they’re invoked
+ they can return an object of any subtype of their return type
- classes without public or protected constructors cannot be subclassed
- they are not readily distinguishable from other static methods
/ Consider a builder when faced with many constructor parameters
+ the Builder pattern is a good choice when designing classes whose constructors or static factories would have more than a handful of parameters
- it could be a problem in some performance-critical situations
/ Enforce the singleton property with a private constructor or an enum type
+ a single-element enum type is the best way to implement a singleton
+ flexibility to change
- a privileged client can invoke the private constructor reflectively (AccessibleObject.setAccessible)
/ Enforce noninstantiability with a private constructor
+ guarantees that the class will never be instantiated under any circumstances
+ prevents the class from being subclassed
- Attempting to enforce noninstantiability by making a class abstract does not work.
/ Avoid creating unnecessary objects
+ prefer primitives to boxed primitives, and watch out for unintentional autoboxing.
- increases memory footprint, and harms performance
- creating objects unnecessarily merely affects style and performance.
/ Eliminate obsolete object references
+ nulling out object references should be the exception rather than the norm.
- whenever a class manages its own memory, the pro- grammer should be alert for memory leaks
/ Avoid finalizers
- finalizers are unpredictable, often dangerous, and generally unnecessary.
- can cause erratic behavior, poor performance, and portability problems.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment