Creating and Destroying Objects
Item 1: Consider static factory methods instead of constructors
advantage
- 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.
- the class of the returned object can vary from call to call as a function of the input parameters.
- the class of the returned object need not exist when the class containing the method is written.
disadvantage
- classes without public or protected constructors cannot be subclassed.（using composite）
- they are hard for programmers to find.(java tools, and good name)
eg:
Item 2: 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, especially if many of the parameters are optional or of identical type.
performance
Item 3: Enforce the singleton property with a private constructor or an enum type
it is more concise, provides the serialization machinery for free, and provides an ironclad guarantee against multiple instantiation.
enum type is often the best way to implement a singleton.(static final)
Item 4: Enforce noninstantiability with a private constructor
Item 5: Prefer dependency injection to hardwiring resources
Item 6: Avoid creating unnecessary objects
Item 7: Eliminate obsolete object references
Item 8: Avoid finalizers and cleaners
Cleaners are less dangerous than finalizers, but still unpredictable, slow, and generally unnecessary.
There is a severe performance penalty for using finalizers and cleaners.
Just have your class implement AutoCloseable
Item 9: Prefer try-with-resources to try-finally
Methods Common to All Objects
Item 10: Obey the general contract when overriding equals
Item 11: Always override hashCode when you override equals
https://blog.csdn.net/wangyunpeng0319/article/details/74156934
Item 12: Always override toString
Item 13: Override clone judiciously
https://blog.csdn.net/bigconvience/article/details/25025561
Item 14:Consider implementing Comparable
Classes and Interfaces
Item 15: Minimize the accessibility of classes and members
make each class or member as inaccessible as possible.
Item 16: In public classes, use accessor methods, not public fields
Item 17: Minimize mutability
To make a class immutable, follow these five rules:(Immutable objects are inherently thread-safe)
Don’t provide methods that modify the object’s state (known as mutators).
Ensure that the class can’t be extended.
Make all fields final.
Make all fields private.
Ensure exclusive access to any mutable components.
Item 18: Favor composition over inheritance
inheritance violates encapsulation
Item 19: Design and document for inheritance or else prohibit it
the class must document its self-use of overridable methods.
Item 20: Prefer interfaces to abstract classes
Item 21: Design interfaces for posterity
Item 22: Use interfaces only to define types
Item 23: Prefer class hierarchies to tagged classes
Item 24: Favor static member classes over nonstatic
Item 25: Limit source files to a single top-level class
Item 26: Don’t use raw types
If you use raw types, you lose all the safety and expressiveness benefits of generics.
Item 27: Eliminate unchecked warnings
If you can’t eliminate a warning, but you can prove that the code that provoked the warning is typesafe, then (and only then) suppress the warning
with an @SuppressWarnings("unchecked") annotation.
Item 28: Prefer lists to arrays
Arrays are
covariant and reified; generics are invariant and erased. As a consequence, arrays
provide runtime type safety but not compile-time type safety, and vice versa for
generics.
Item 29: Favor generic types
generic types are safer and easier to use than types that require
casts in client code.
Item 30: Favor generic methods
Item 31: Use bounded wildcards to increase API flexibility
PECS stands for producer-extends, consumer-super. (super: 当前类或则父类, extends:当前类或者子类)
eg:
public static <T> void copy(List<? super T> dest,List<? extends T> src)
在<code>src</code>中，我们可以传入与<code>T</code>类型相关的<code>List</code>，并且能够保证取出的是<code>T</code>类型或者<code>T</code>的子类型的值。
在<code>dest</code>中，我们可以传入<code>T</code>类型和<code>T</code>的父类的<code>List</code>，并且能够保证我们从存放的值都满足要求
Item 32: Combine generics and varargs judiciously ?
Item 33: Consider typesafe heterogeneous containers?
Enums and Annotations
Item 34: Use enums instead of int constants
Item 35: Use instance fields instead of ordinals
Item 36: Use EnumSet instead of bit fields
Item 37: Use EnumMap instead of ordinal indexing
Item 38: Emulate extensible enums with interfaces
Item 39: Prefer annotations to naming patterns
Item 40: Consistently use the Override annotation
Item 41: Use marker interfaces to define types
Lambdas and Streams
Item 42: Prefer lambdas to anonymous classes
Item 43: Prefer method references to lambdas
Item 44: Favor the use of standard functional interfaces
Item 45: Use streams judiciously
Item 46: Prefer side-effect-free functions in streams
Item 47: Prefer Collection to Stream as a return type
Item 48: Use caution when making streams parallel
Methods
Item 49: Check parameters for validity
Item 50: Make defensive copies when needed
保护性复制，防止变量被修改,date
Item 51: Design method signatures carefully
Choose method names carefully.
Don’t go overboard in providing convenience methods.
Avoid long parameter lists.
For parameter types, favor interfaces over classes
Prefer two-element enum types to boolean parameters,
Item 52: Use overloading judiciously
overloaded methods is static, while selection among overridden methods is dynamic.
Item 53: Use varargs judiciously
Item 54: Return empty collections or arrays, not nulls
Item 55: Return optionals judiciously
Item 56: Write doc comments for all exposed API elements
General Programming
Item 57: Minimize the scope of local variables
Item 58: Prefer for-each loops to traditional for loops
Item 59: Know and use the libraries
By using a standard library, you take advantage of the knowledge of the experts who wrote it and the experience of those who used it before you.
java.lang, java.util, and java.io, java.util.concurrent...
Item 60: Avoid float and double if exact answers are required
Item 61: Prefer primitive types to boxed primitives
Item 62: Avoid strings where other types are more appropriate
Item 63: Beware the performance of string concatenation
Item 64: Refer to objects by their interfaces
Item 65: Prefer interfaces to reflection
Item 66: Use native methods judiciously
Item 67: Optimize judiciously
Item 68: Adhere to generally accepted naming conventions
Exceptions
Item 69: Use exceptions only for exceptional conditions
Item 70: Use checked exceptions for recoverable conditions and
runtime exceptions for programming errors
Item 71: Avoid unnecessary use of checked exceptions
Item 72: Favor the use of standard exceptions
Item 73: Throw exceptions appropriate to the abstraction
Item 74: Document all exceptions thrown by each method
Item 75: Include failure-capture information in detail messages
Item 76: Strive for failure atomicity
Item 77: Don’t ignore exceptions
Concurrency
Item 78: Synchronize access to shared mutable data
when multiple threads share mutable data, each thread that
reads or writes the data must perform synchronization.
Item 79: Avoid excessive synchronization
Item 80: Prefer executors, tasks, and streams to threads
Item 81: Prefer concurrency utilities to wait and notify
Item 82: Document thread safety
Item 83: Use lazy initialization judiciously
Item 84: Don’t depend on the thread scheduler
Serialization
Item 85: Prefer alternatives to Java serialization
Item 86: Implement Serializable with great caution
Item 87: Consider using a custom serialized form
Item 88: Write readObject methods defensively
Item 89: For instance control, prefer enum types to readResolve
Item 90: Consider serialization proxies instead of serialized
instances
