[Effective Java 3rd Edition](https://www.amazon.co.jp/Effective-Java-%E7%AC%AC3%E7%89%88-%E3%], which is a must-have book for intermediate Java users and above. 82% B8% E3% 83% A7% E3% 82% B7% E3% 83% A5% E3% 82% A2% E3% 83% BB% E3% 83% 96% E3% 83% AD% E3% 83% 83% E3% 82% AF-ebook / dp / B07RHX1K53) has a Kindle version, so I will summarize it.
Previous: Effective Java 3rd Edition Chapter 7 Lambda and Stream Next: Effective Java 3rd Edition Chapter 9 General Program
--For public and protected methods, use the Javadoc @ throws tag to document the exception that is thrown if the parameter value constraints are not adhered to. Generally the exceptions are ʻIllegalArgumentException, ʻIndexOutOfBoundsException, NullPointerException.
--The ʻObjects.requireNonNull` method added in Java7 is flexible and convenient, so you don't have to do null checking manually.
//Throw a NullPointerException if strategy is null
this.strategy = Objects.requireNonNull(strategy, "strategy must not be null.")
--In Java 9, a range checking mechanism has been added to java.util.Objects. It consists of three methods, checkFromIndexSize, checkFromToIndex, and checkIndex, and checks whether the index of the list and array is within the range.
--Methods that are not public should use assertions to check their parameters.
--When a mutable object like the Date class comes in as a parameter, it is important to copy it defensively.
--Choose the method name carefully. Avoid long method names. --Do not provide too many useful methods. Individual methods should "play their own role", and many methods make testing and maintenance difficult. --Avoid long list of parameters. Aim for 4 or less. It is harmful to have multiple parameters of the same type. There are three techniques for shortening the list of overly long parameters: --Split the methods so that each method requires only a subset of the parameters. --Create a helper class that holds a collection of parameters. --Apply the Builder pattern from object creation to method invocation. --For the parameter type, select the interface rather than the class. If an appropriate interface exists to define the parameters, use that interface rather than the class that implements it. (Example: HashMap → Map) --If the meaning of boolean is not clear from the method name, use an enum type that has two elements rather than boolean.
--The overload chooses which method to call at compile time. In a Collection instance, if the content is ʻArrayList, ʻArrayList cannot successfully call the argument method.
--A safe and conservative policy does not provide two overloaded methods with the same number of parameters. Instead of overloading, give the method a different name.
--The problem is that the variable length argument method can only be checked at runtime when one or more arguments are required. --Variadic arguments are placed after the required parameters.
--Do not return null instead of empty collections or arrays. --Null makes the API difficult to use and has no performance benefits.
--There are three ways to represent an object that has no value.
--null (danger of NullPointerException)
--Exception (high cost)
--Optional (from java8)
--ʻOptional.empty () empty. Optional that contains value in ʻOptional.of (value) .
--ʻOptional.ofNullable (value) determines and returns one of the above depending on whether value is null or not. --Methods that return Optional must not return null. --Returning an option that includes a boxed basic data type is expensive because you do two levels of boxing. For that purpose, the basic data types ʻOptionalInt, ʻOptionalLong, and ʻOptionalDouble are prepared.
--It should be rare to use Optional other than the return value.
--Document comments must be written before all published classes, interfaces, constructors, methods and field declarations.
--Document comments about methods should briefly describe the contract between the method and its clients.
--List all preconditions, postconditions, and side effects of the method.
--The @ param, @ return, and @ throws tags should be written.
--Document comments are converted to HTML, so you can use HTML tags.
--When designing a class for inheritance, the self-use pattern must be documented. For that, use @implSpec.
-HTML metacharacters (<``>``&Etc.) when using@literalEnclose in tags. Example){@literal |r| < 1}
Recommended Posts