I tried to explain Effective Java 3rd edition "almost all chapters" in "easy-to-read Japanese".

I think Effective Java is an inevitable book to become a "full-fledged" Java engineer. Especially engineers who are in a position to make public APIs can not make decent ones unless they understand what is written in this book.

It goes without saying that it is a wonderful book, but on the other hand, I also feel that it is difficult to understand that it is such a thing.

The cause is probably as follows.

• The expression is roundabout.
• There are 90 items in total, but the structure within the items is difficult to understand.
• Code examples can be more complex than necessary.

The essence of the content itself is not very difficult, but I think it's hard to say that the threshold of this book is raised for this reason.

Therefore, in this article, I would like to explain (almost) all items in "easy-to-read Japanese" as much as possible.

However, I have omitted explanations for items that are too obvious or easy to read. Also, my personal opinion is mixed. I hope you can see it on that premise.

Effective Java 3rd Edition is written targeting Java 9. Therefore, I will post the official Java 9 documentation just in case (because it is unexpectedly difficult to reach).

[Java 9] Official Document Top https://docs.oracle.com/javase/jp/9/

[Java 9] JDK Javadoc (followed from the top screen) https://docs.oracle.com/javase/jp/9/docs/toc.htm

[Java 9] Java language specifications (can be traced from the top screen) https://docs.oracle.com/javase/specs/jls/se9/html/index.html

Chapter 1 Introduction

It only contains definitions of terms used in books. You don't have to read it. (end)

Chapter 2 Object Creation and Disappearance

Item 1 Consider a static factory method instead of a constructor.

For example, it looks like the following.

• NG: BigInteger (int, int, Random) ← Constructor. Confusing.
• OK: BigInteger.probablePrime (int, Random) ← static factory method. Easy to understand.

Consider the static factory method first, and if it's subtle, choose a constructor.

◆ Advantages

** ① You can give a descriptive name. ** **

The constructor has the following inconveniences.

• The name of the constructor is limited to one (class name).

• The only distinction between constructors is the difference in their arguments. As a result, it is difficult for users to understand the differences between constructors.

Static factory methods do not have this inconvenience.

** ② There is no need to create a new object. Reuse the same object. ** **

** ③ You can return an object of that subtype instead of the return type itself. ** **

For example, java.util.Collections has a static factory method called ʻemptyList ()`. It has the following features.

• ʻEmptyList ()` returns an instance of the inner class EmptyList. The inner class EmptyList is not public and can be hidden from the outside.
• The return type of ʻemptyList ()is theList` interface.

Thanks to this, the Collections API is very simple. In particular···

• Implementers do not need to explain to users how to use EmptyList (API).

• Users do not need to be aware of the existence of EmptyList and do not need to understand how to use (API). You only need to know how to use the List interface.

** ④ You can switch the subtype to be returned according to the situation. ** **

In ③, the explanation is based on the assumption that the same subtype is always returned. What I want to say in ④ is that you can select and return the one that suits your situation from multiple subtypes.

** ⑤ The subtype to be returned can be decided at runtime. (It is OK even if it is not decided at the time of implementation of the static factory method.) **

For example, JDBC DriverManager.getConnection () corresponds to this.

As a result, it becomes more flexible as an API.

◆ Disadvantages

** ① The user cannot create a subclass of the return type. ** **

For example, ʻemptyList ()` in java.util.Collections returns EmptyList, but since EmptyList is a private class, users cannot create subclasses of EmptyList.

Not limited to this example, I couldn't think of a case that would make me want to create a subclass. In practice, I don't think there are any weaknesses or restrictions.

** ② It is difficult for users to find static factory methods. ** **

This is certainly the case. In Javadoc, the constructor is a separate section, which makes it stand out, but static factory methods are buried in the list of methods.

Try to make the API easy for users to understand by following the general naming pattern below.

reference

Overview of Collections Framework https://docs.oracle.com/javase/jp/9/docs/api/java/util/doc-files/coll-overview.html

Item 2 Consider a builder when faced with many constructor parameters

[NG] Telescoping pattern

public class NutritionFacts {
    //Field definition omitted

    public NutritionFacts(int servingSize, int servings) {
        this(servingSize, servings, 0);
    }

    public NutritionFacts(int servingSize, int servings, int calories) {
        this(servingSize, servings, calories, 0);
    }

    //The above flow continues endlessly ...
}

NG point

• Even if the parameter does not matter to the user, it will force the setting.
• The user has to worry about what number parameter is, which is very difficult. (In practice, the IDE will reduce it a little)
• It is difficult for the reader of the code to understand the meaning of each parameter. (In practice, the IDE will reduce it a little)
• As long as the types match, no compilation error will occur, so even if parameters of the same type are specified in the wrong order, the user will not notice the mistake.

[NG] JavaBeans pattern

//It's just plain JavaBeans.
public class NutritionFacts {
    //Field definition omitted

    public NutritionFats() {}
    
    public void setServingSize(int val) { //Abbreviation}
    public void setServings(int val) { //Abbreviation}
    public void setCalories(int val) { //Abbreviation}
    //The setter continues ...
}

NG point

• Inconsistencies may occur between parameters after instantiation. Essentially, you should detect such inconsistencies before instantiating.
• You can change the internal state from setter, so you can't make the class immutable.

[Builder pattern]

//User code
NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8).
    calories(100).sodium(35).carbohydrate(27).build();

Advantages

• Easy to implement.
• Easy to read.
• You can detect inconsistencies between parameters before instantiating with build (). This advantage is very important. This is because if the inconsistency is not detected here and an error occurs in a distant place due to the inconsistency, it will be difficult to identify the cause.
• This pattern can be applied even if the classes are hierarchical.
• Makes the API flexible. For example, by reusing one Builder (instance) and numbering the serial number in build (), you can generate more and more unique objects.

Disadvantages (trivial)

• Builders need to be instantiated and should be considered in situations where performance requirements are severe. However, in practice, such a situation is rare, so it is a minor disadvantage.
• The user's code will be longer than the telescoping pattern. Therefore, it may be better to use it when the number of parameters is large. However, the number of parameters may increase steadily as you maintain it, and it is unrealistic to change to the Builder pattern in the middle, so it is a minor disadvantage.

Item 3 Enforce singleton characteristics with private constructor or enum type

There are three ways to achieve a singleton. Choose the best one for your situation.

• Implement a singleton with enum type. ← In many cases this is the best
• Create one instance with private constructor ...
• Set to public field and publish.
• Return with static factory method.

If you implement a singleton with an enum type, it will look like this.

enum type singleton

public enum Elvis {
    INSTANCE;
    public void someMethod();
}

The best way is to use an enum, as other methods run the risk of not being a singleton and you will have to work around it. Specifically, it is as follows.

• In the case of a private constructor, the user can call the internal private constructor by reflection. It is troublesome to write a check process to prevent this.
• If you want to be able to serialize a singleton class, you risk creating an instance each time you deserialize it. It is troublesome to write a process to prevent this. (I think it's rare that you want to serialize ...)

I think that these risks can be ignored in practice, but you should think about them properly.

I haven't seen the method of using enum type in practice, but it is rational in the above points, so it should be used positively.

The two methods of using the private constructor have the following advantages. However, I feel that there are only a limited number of cases where you want to obtain these advantages, so in the end, enums are the best choice in many cases.

Item 4 Force impossibility of instantiation with private constructor

A class consisting of only static methods and static fields is commonly referred to as a utility class.

Such classes shouldn't be instantiated and used, but if you can use the constructor, you risk accidentally instantiating them. I don't think there is much actual harm, but it makes me very disappointed when it is used in that way.

So let's implement a private constructor like this:

public class UtilityClass {
    //Suppress the default constructor so that it cannot be instantiated.
    //By leaving a comment like this, let's convey the implementation intention of this constructor to posterity.
    private UtilityClass() {
        throw new AssertionError();
    }
}

This will prevent you from being accidentally instantiated or accidentally inherited to create a subclass.

Item 5: Select dependency injection rather than directly linking resources

Let's take a spell checker as an example.

[NG] Implemented as a utility class

public class SpellChecker{
    //Dictionary used for Speccheck
    private static final Lexicon dictionary = ...;

    //Suppress instantiation according to the method of item 4
    private SpellChecker() {} 

    public static boolean isValid(String word) { ... }
}

[NG] Implemented to be a singleton

// SpellChecker.INSTANCE.isValid("some-word");Use like.
public class SpellChecker{
    //Dictionary used for Speccheck
    private final Lexicon dictionary = ...;

    //Suppress instantiation according to the method of item 4
    private SpellChecker() {} 
    public static SpellChecker INSTANCE = new SpellChecker(...); 

    public static boolean isValid(String word) { ... }
}

Since only one dictionary can be used in these NG examples, it is not possible to switch dictionaries depending on the situation. This difficulty applies not only to production code, but also to testing.

There is a way to provide a method like setDictionary (lexicon) so that you can change it later, but it's confusing to the user. It's also not thread safe.

In the first place, the fact that a dictionary changes depending on the situation means that the dictionary is a "state". Therefore, you should implement the spell checker as a class that can be instantiated and used.

Specifically, it is as follows.

[OK] Implemented in the style of dependency injection

public class SpellChecker{
    //Dictionary used for Speccheck
    private final Lexicon dictionary;

    //Since it has a "state" called a dictionary, it is instantiated and used.
    //At this time, a dependency called a dictionary is injected.
    public SpellChecker(Lexicon dictionary) {
        this.dictionary = Objects.requireNonNull(dictionary);
    } 

    public static boolean isValid(String word) { ... }
}

This way, you can switch dictionaries depending on the situation and it will be thread safe.

Item 6 Avoid creating unnecessary objects

Reusing objects can minimize the cost of creating objects and increase their speed.

On the other hand, if you create a lot of unnecessary objects, it will be extremely slow.

The immutable nature is very important because immutable objects (immutable objects) can always be safely reused.

[NG Part 1]

// new String()So, we are creating an unnecessary object.
// "bikini"So, we are creating an unnecessary object.
String s = new String("bikini");

【OK】

//The generated object is"bikini"String instance only.
//String literals within the same JVM"bikini"Instances of are always reused.
String s = "bikini";

[NG Part 2]

//Since it is a constructor, a new object is always created.
new Boolean(String);

【OK】

//The static factory method does not need to create a new object.
//A true or false Boolean object is reused.
Boolean.valueOf(String);

[NG Part 3]

//A Pattern object is created inside matches.
// isRomanNumeral()Every time is called, a Pattern object is created.
static boolean isRomanNumeral(String s){
    return s.matches("Regular expressions. The content is omitted.");
}

【OK】

public class RomanNumerals {
    //You are reusing a Pattern object.
    private static final Pattern ROMAN = Pattern.compile("Regular expressions. The content is omitted.");

    static boolean isRomanNumeral(String s) {
        return ROMAN.matcher(s).matches();
    }
}

[NG Part 4]

//NG example in auto boxing
private static long sum() {
    Long sum = 0L;
    for (long i = 0; i <= Integer.MAX_VALUE; i++)
        //Since Long is immutable, a new instance will be created each time it is added.
        sum += i;

    return sum;
}

【OK】

private static long sum() {
    //Change to primitive type (Long)-> long）
    long sum = 0L;
    for (long i = 0; i <= Integer.MAX_VALUE; i++)
        sum += i;

    return sum;
}

By the way, for example, Map.keySet () returns a Set view (adapter), but no matter how many times you call keySet (), the same Set instance will be returned. It's easy to think that a new instance is created each time you call it, but in fact, the instance is reused in these places as well, and efficiency is improved. Even when we implement the API, we should implement it optimally from the perspective of "Is it necessary to create a new instance?"

Item 7 Remove object references that are no longer used

If your class manages its own memory that is beyond the control of the garbage collector, you need to clear references to objects that you no longer need (set the variable to null).

Unmanaged means that the garbage collector is unaware of virtually unused objects.

Variables that are out of scope are usually subject to garbage collection. On the other hand, if you manage objects in a class, they will not be out of scope and will not be subject to garbage collection. From the garbage collector's point of view, the object is considered to be in use.

The book explains the above using a simple stack implementation as an example. Please refer to the book for details.

Case of implementing your own cache

Even if you implement your own cache, it corresponds to the above-mentioned "case of managing your own memory in the class".

For example, when caching image data with HashMap, HashMap should be managed as a field of some object A, so the references are connected as follows.

Source-> Object A-> HashMap-> key and value

Even if the data (key and value) managed by HashMap is actually no longer needed, that data will not be garbage collected as long as object A and HashMap continue to be referenced. As a result, the memory grows.

The remedy in this case is as follows. (I don't think there are many opportunities to implement the cache yourself ...)

** Method ① Implement the cache with WeakHashMap. ** **

When a key is no longer referenced by anything other than its WeakHashMap object, the WeakHashMap will be subject to the next GC for that entry (key-value pair). We use a so-called weak reference mechanism.

If you want to delete the key from the cache with the state that "the key is not referenced by other than that WeakHashMap object", consider adopting it.

As explained in this book, if it is deleted from the cache so easily, it can no longer be called a cache. For details, see [See below. ](# What is a reference weak reference)

** Method (2) Use ScheduledThreadPoolExecutor to periodically delete old data in the cache. ** **

This article is recommended for a quick understanding of how to use ScheduledThreadPoolExecutor. https://codechacha.com/ja/java-scheduled-thread-pool-executor/

Consider using it if you want to delete something that has been registered in the cache for some time.

** Method ③ When adding a new entry to the cache, delete the old one. ** **

It's simple. As with (2), if you want to delete something that has been registered in the cache for some time, consider using it.

Case of registering listeners and callbacks in memory

When creating an API that allows listeners and callbacks to be registered from the client, the registered listeners and callbacks will not be subject to GC unless they are created with proper consideration.

It's a good idea to use a weak reference mechanism, such as saving it as a WeakHashMap key. If it is no longer used by anyone other than WeakHashMap, it will be subject to GC.

Reference: What is a weak reference?

Objects that normally cannot reach the referrer (objects that are not used by anyone) are subject to GC and are deleted from memory.

However, it can be a problem if it is deleted immediately. There is a mechanism to prevent objects that cannot be reached from the reference source from being immediately subject to GC. That is the java.lang.ref package.

In the world of this package, ordinary references are called "strong references", and their own "references" are defined as follows.

Item 8 Avoid finalizers and cleaners

The finalizer here is java.lang.Object # finalize () or a method that overrides it in a subclass.

A cleaner is a java.lang.ref.Cleaner.

There are various reasons why this is not good, but there is almost no need to understand the contents.

Never use it because it is dangerous anyway. That's fine.

Item 9 Select try-with-resources rather than try-finally

Try-finally has the following problems:

• Close leakage is likely to occur.
• If you try to close without omission, nesting will increase. As a result, the code is hard to read and hard to modify.
• Easy to crush the exceptions that occur.
• To avoid crushing exceptions, you need to write a catch clause. As a result, the code is hard to read and hard to modify.

Try-with-resources solves these problems.

If an exception occurs during try and then an exception occurs even with close, the former will be given priority and thrown. You can catch this in the catfh clause.

To access the latter, use the getSuppressed method in the former exception object. However, in many cases you will want to know the former, so it seems that you will not have many opportunities to use it.

Chapter 3 Methods common to all objects

Item 10 When overriding equals, follow the general contract

I think the opportunity to override the equals method is limited in the first place. If you are overriding, there are requirements to meet.

If you need to override the equals method, stick to that requirement. Specifically, the requirements are as follows.

• Reflectivity: x.equals (x) returns true.

• Symmetry: x.equals (y) returns true only if y.equals (x) is true.

• Transitive: If x.equals (y) and y.equals (z) are true, x.equals (z) returns true.

• Consistency: If x.equals (y) is called multiple times, the result will be the same.

• Non-null: x.equals (null) returns false.

• It is assumed that x, y, and z are not null.

The book says there are things to keep in mind about each requirement, but there aren't many opportunities to override equals in the first place, so it's probably less costly to learn more when you don't need it.

For this reason, I'll just refer to the book when I need it, and I won't go into detail in this article either.

Item 11 When overriding equals, always override hashCode

As you can see in item 10, there aren't many chances to override equals, so this item doesn't seem to be very important either. I'll just give you an overview.

The requirements for overriding the hashCode method are as follows:

• If the hashCode method is called multiple times, it returns the same value.
• If the two objects are equal in the equals method, the hashCode methods of the two objects return the same value.
• Just because the two objects are different in the equals method, the hashCode methods of the two objects also need not ** need to return different values **. However, returning separate values tends to improve the performance of the hash table.

Item 12 Always override toString

The advantage of overriding the toString method is that it makes it easier for users of that class to debug.

However, the system created in practice is not a work of art, and human and temporal resources are limited. Therefore, I think that you should decide whether or not to override if necessary.

If you override the toString method, be aware of the following:

• Output all the information that the user should know. Be aware that toString exists for you.
• Decide whether to decide the format of the return value (for example, 090-1234-5678 for phone numbers) depending on the situation. It may be nice for users to have a fixed format, but once it is decided, it is difficult to change it later. Let's balance.

Item 13 Carefully override clone

Overriding Object.clone () is basically NG. The reason is as follows.

• The requirements that must be met when overriding are not enforced by the compiler, nor are they even specified in the Javadoc.
• The requirements are quite complex. See the book for details.
• The overridden method requires you to call Object.clone () in the form super.clone (). At that time, the following complexity is created.
• You need to handle a CloneNotSupportedException that Object.clone () may throw.
• The return type of Object.clone () is Object, but in practice you need to cast it to a specific type.
• Final fields cannot be copied as modification is prohibited. You need to remove final for a non-essential reason to override clone ().
• There are other detailed reasons besides the above. See the book for details.

Since it is NG, you should not override Object.clone () unless you already have a class that overrides Object.clone () and you have to fix it for maintenance.

Instead, use the following methods. These do not have the above drawbacks.

//Copy constructor
public Yum(Yum yum) { ... }

//Copy factory
public static Yum newInstance(Yum yum) { ... }

Regardless of whether you use a copy constructor or copy factory method or Object.clone (), be aware of the following points in common.

• As a general rule, when copying a field, make a deep copy.

In other words, when copying a field, it is not enough to set the copy source object reference to the copy destination field. This is because the same object reference is shared between the copy source and the copy destination. This is the so-called shallow copy. It's a natural idea, but it's quite cumbersome to implement. There are exceptions to this rule, and if it's an immutable object, you can copy the reference.

• Of course it is NG that the state of the copy source changes during copying, so let's implement it in thread safety.

To understand this item, it is recommended that you know the following in advance.

• Object.clone () has a native modifier, so it is implemented in languages other than Java. In other words, there is content in the process.

• Covariant return type https://www.slideshare.net/ryotamurohoshi/ss-38240061

Item 14 Consider implementing Comparable

If you implement Compareable.compareTo () in the class you develop, you can store the objects of that class in the collection and use the convenient API of the collection. For example, you will be able to sort nicely.

If you want to get this benefit, implement a Comparable interface.

In that case, requirements similar to overriding the equals method must be met.

• sgn (x.compareTo (y)) == -sgn (y.compareTo (x)). That is, when the order is reversed and the comparison is made, the sign of the result is also reversed.

• If (x.compareTo (y)> 0 && y.compareTo (z)> 0), then x.compareTo (z)> 0. In other words, it becomes a transitive relationship.

• If x.compareTo (y) == 0, then sgn (x.compareTo (z)) == sgn (y.compareTo (y)). That is, if the order of x and y is equal, the result will be equal when comparing other objects z with each of x and y.

• If x.compareTo (y) == 0, then x.equals (y) is true, and vice versa ** is not required, but preferable **.

• Sgn (expression) is a function that returns -1, 0, 1 when expression is negative, zero, and positive, respectively.

There are notes on the first three requirements. Given an existing class that implements Comparable, it is virtually impossible to meet these requirements if you extend it and add new fields. If you force it, it's no longer object-oriented code. In such a case, let's realize it with composition instead of extends (item 18).

What if I violate the fourth requirement? An example of a violation is Big Decimal. new BigDecimal ("1.0") and new BigDecimal ("1.00") are not equal in the equals method and equal in the compareTo method.

If you put them in a new HashSet, they will be compared by the equiqls method, so the number of elements will be 2. On the other hand, if you put it in a new TreeSet, the number of elements will be 1 because it will be compared by the compareTo method. If you don't keep this behavior in mind, you'll have no idea what the cause is in the unlikely event of a problem.

In addition to the four requirements, note the following:

• The Comparable interface is parameterized, so there is no need to check or cast argument types.
• If the argument is null, a NullPointerException should be thrown. It should normally be the case without doing anything.
• If the fields you want to compare are objects, compare them by compareTo instead of comparing their references. If desired, you can implement compareTo yourself or use an existing Comparator (eg String.CASE_INSENSITIVE_ORDER).
• Don't use relational operators (>, <, ==) when comparing magnitudes. It just gets confusing. Instead, use a compare method such as Integer.compare ().
• In Java 8, it can be implemented in a flowing manner using the comparator construction method.

private static final Comparator<PhoneNumber> COMPARATOR = 
            comparingInt((PhoneNumber pn) -> pn.areaCode)
                .thenComparingInt(pn -> pn.prefix)
                .thenComparingInt(pn -> pn.lineNum);

public int compareTo(PhoneNumber pn) {
    return COMPARATOR.compare(this, pn);
}

• If a comparator based on the difference is used, not only the transitive requirement cannot be met, but also there is a risk of integer overflow. Instead, use static methods such as Integer.compare () mentioned above, or comparator construction methods.

//NG example
static Comparator<Object> hashCodeOrder = new Comparator<>() {
    public int compare(Object o1, Object o2) {
        return o1.hashCode() - o2.hashCode();
    }
}

Chapter 4 Classes and Interfaces

Item 15 Minimize accessibility to classes and members

What is information hiding and encapsulation?

Minimize the part of the component that can be accessed from outside (public API). Make other parts (internal data, implementation details) inaccessible from the outside.

To put it plainly, minimize what you declare in public or protected. Carefully design your class to do so.

Reasons for information hiding and encapsulation (why)

Information hiding and encapsulation allows components to be developed individually and optimized individually. This greatly reduces the worry of harming other components.

The purpose of information hiding and encapsulation is to aim for the following.

• Allows each component to be developed in parallel to speed up development.
• Reduces the effort of impact investigation and reduces the maintenance load.
• Allows local elimination of bottlenecks to facilitate performance tuning.
• Allows components to be reused.

If you cannot achieve these goals, there is no point in aiming for information hiding or encapsulation. Practical programs are not works of art, but a means to a successful business. So you shouldn't be satisfied that you've made something beautiful (I'm very careful because it's easy to be satisfied that way).

How to do it (how)

Specifically, consider the following points.

• Instead of adding public without thinking, choose the one that minimizes accessibility.
• Implementing Serializable effectively makes it a public API.
• Those declared as protected will be public APIs because they can be accessed by users (subclasses).
• Making the package private for testing is acceptable in that it is not exposed to the outside world.
• If you publish a constant in public static final, you should make sure that the constant is in line with the component abstraction policy.
• Variable objects may be changed by the user. Therefore, it is NG to publish as a constant. Instead, you should either convert it to an immutable object and publish it (such as Collections.unmodifiableList) or return a copy.
• The module system added in Java 9 has not been widely used yet and its usefulness has not been confirmed, so it is not necessary to actively use it at this time.

Item 16 In the public class, use the accessor method instead of the public field.

It's a matter of course to add setter / getter.

In practice, I think it's common sense to do this, and I think it's easy to add setters / getters without thinking about anything. However, if you do not understand the reason, it will not be a good class design. Let's understand the reason why we should add setter / getter again.

The reason you should add setter / getter is to get the benefits of information hiding and encapsulation. Specifically, it is as follows.

• This is so that the representation format of internal data (what type it should be, etc.) can be changed later.
• This is so that you can check the consistency between fields.
• This is so that auxiliary processing can be added later.

Since the essential point is to reduce the public API as much as possible, there is little need to prepare setters / getters in the fields for package private classes and private inner classes. If you try to provide setters / getters unnecessarily, it will take more time to implement and the code will be difficult to read. Don't feel like "just add a setter / getter without thinking".

Item 17 Minimize variability

Immutable objects (immutable objects) have several advantages, including the fact that they can be used thread-safely. Typical examples in the JDK are boxed basic data classes such as String and Integer, BigDecimal and BigInteger.

If you create your own class that has values, make it immutable unless you have a good reason to make it variable. Even if it's not practical to make it perfectly immutable, it's a good idea to make it as immutable as possible, such as making the field as final as possible. This is because if the number of possible states is reduced, there are merits such as less trouble.

Benefits of immutable objects

• Thread safe. It doesn't matter if it is accessed by multiple threads. In practice, I think this is the greatest merit.
• The user does not have to be aware of the state transition inside the object.
• You can share the instance. As a result, the cost of creating objects and memory consumption can be reduced.
• Internal state can be shared between instances. For example, if your class has an array inside, you can pass a reference to the array held by one instance to a new instance and reuse it.
• Other objects that hold that instance in a field may need to maintain some state internally (such as the magnitude relationship between fields). If the instance held in the field is variable, you have to be aware of the state transition of that instance, so the process to keep the desired state becomes very complicated. Or, it is impossible to realize in the first place. On the contrary, if the instance held in the field is immutable, there is no such problem.
• There is an error atomic property. Error atomicity is the property of an object to return to its pre-failure state. Immutable objects do not change in the first place, so it is natural to have this property. In order to give the variable object error atomicity, it takes time and effort to do so. Immutable objects don't require that kind of effort, but that's good.

Disadvantages of immutable objects

• Each instance with a different value consumes system resources. As a result, it can consume a lot of memory and result in poor performance. For example, in each of multiple calculation steps, an ad hoc instance may be created and destroyed. The workaround is as follows.

• Combine multiple processing steps into one public API.

• Provides a public variable companion class, such as StringBuilder for String.

How to make an immutable object (requirements to be met)

• Do not provide methods that can change the state of an object, such as setter.
• Prevent it from being extended. Either make the class final, or make the constructor private and provide static factory methods.
• Make all fields final. This makes the field immutable and allows you to securely pass instance references between threads. There are exceptions to this. In some cases, you may want to cache the calculation results that are used only internally in the field. In that case, the option of not making it final is also an ant.
• Make all fields private. By doing this, even if you have a variable object in the field, you can prevent the user from changing the contents of the object. You can also change the internal representation of the field later without affecting the user.
• If the field has a mutable object, only the immutable class (itself) can access the mutable object. When creating an immutable class object based on the object passed by the user, do not use the reference as it is, but make a defensive copy (item 50).

Item 18 Choose composition over inheritance

Inheritance breaks encapsulation. In other words, subclasses depend on the implementation details of the superclass. As a result, changes in the implementation details of superclasses can lead to subclasses not working as intended or security holes.

You might think it's okay if the subclass doesn't override the superclass's methods, but that's not the case. The method signatures that the superclass added later may conflict with the methods implemented in the subclass.

Because of these inconveniences, don't jump into inheritance suddenly. Compositions do not have the same inconvenience.

However, inheritance is 100% bad, and composition is not 100% positive. Let's be able to choose between composition and inheritance depending on the situation.

What is composition

Instead of inheriting the existing class, keep the existing class in the private field, as shown below. Extend an existing class by calling the methods of that existing class.

//The transfer class. Composition has been applied in this class.
//A class is provided separately from the InstrumentedSet so that it can be reused.
public class ForwardingSet<E> implements Set<E> {
    //Hold the object of the existing class you want to extend in the field.
    private final Set<E> s;

    public ForwardingSet(Set<E> s) {
        this.s = s;
    }

    //Throw the process to the object of the existing class you want to extend.
    public void clear() {
        this.s.clear();
    }

    //Omitted thereafter.
}

/*
Create your own class by inheriting the transfer class.
You might think, "What? Inheritance is not good, right?", But inheritance here is
It's a reasonable decision to make the ForwardingSet reusable for other purposes.
*/
public class InstrumentedSet<E> extends FowardingSet<E> {
    //This class is responsible for managing how many times a set has been added in total.
    private int addCount = 0;

    public InstrumentedSet(Set<E> s) {
        super(s);
    }

    @Override
    public boolean add(E e) {
        addCount++;
        return super.add(e);
    }

    //Omitted thereafter.
}

By the way, the technique in the above code example is not exactly "delegation". Please be careful.

When it is okay to inherit

You may inherit in the following cases.

• When the inherited class (the class you want to be a superclass) is created on the assumption that it will be inherited. The Javadoc for your class should say so.
• When the inherited class (class that you want to be a superclass) is published only in the package (package private). In this case, if you change the superclass, even if there is any negative effect on the subclass, the negative effect will remain in the package. You can get things done by modifying the subclass.

As a major premise when adopting inheritance, it is necessary that an "is-a" relationship is established between the classes. That is, if class B inherits from class A, the answer "Are all Bs A?" Must be yes. Inheritance is a technology for realizing such relationships in code.

Item 19 Design and document for inheritance, otherwise prohibit inheritance

Creating a class that is supposed to be inherited is actually extremely difficult and difficult. Specifically, you need to consider the following:

• It is necessary to show the user when the method that can be overridden in the subclass is called in the superclass. This information is exactly the "implementation details" of the superclass, so it breaks information hiding / encapsulation ...

• You will need to provide the superclass with protected methods (possibly fields) to provide subclasses with hooks for the superclass's internal behavior. Too much will move you away from the benefits of information hiding / encapsulation. On the other hand, too few will make superclasses difficult for subclasses to use. It is necessary to design with this balance, which is extremely difficult.

• Superclass constructors must not call overridable methods. This is because the superclass's constructor is called at the beginning of the subclass's constructor, so you're calling an overridable method when the subclass isn't ready.

• There are some things to be aware of when superclasses implement Cloneable, Serializable. However, I think that such a situation is rare, so I will omit the explanation. See the book for details.

As you can see, it's extremely difficult. If you make a class that is supposed to be inherited by all means, be prepared to take on the above points. That is a professional.

I think there are more cases where this is not the case than when creating a class that is supposed to be inherited. In that case, either make the class final or make the constructor private and prepare a static factory method so that the created class is not inherited by mistake.

Item 20 Select an interface over an abstract class

This item is extremely difficult to read. I will explain with priority on comprehensibility.

There are multiple implementations of a "type". For example, there are multiple implementations of a "type" called Comparable. Java provides the following two mechanisms to realize such a "allow multiple implementations" type.

• Interface (Click here for the example of Comparable)
• Abstract class

If you want to create a new type that "allows multiple implementations", basically do it with an interface. Interfaces are superior to abstract classes in the following ways: It is easy for users to use.

• Users can implement multiple interfaces. In Java, only one class can be inherited, so if you use an abstract class, you will not get these advantages.
• You can introduce an interface to an existing class, even if it already inherits something. In Java, only one class can be inherited, so if you use an abstract class, you will not get these advantages.
• Users can combine existing interfaces to create new ones. You can do the same with abstract classes, but it's ridiculously complicated. Specifically, this article is very helpful.
• Suppose a user wants to create a new function by using an existing "allow multiple implementations" type. If the type is an abstract class, the user has no choice but to inherit from the abstract class. If it is an interface, you can use composition (item 18).

Techniques for creating complicated interfaces "Implementation assistance" "Skeletal implementation"

If you want to create a simple interface yourself, this is a technique you don't have to worry about. Please see only those who need it.

When you create your own interface, suppose you define multiple methods for that interface. For example, suppose you define method A and method B. Usually, if you know that method A calls method B, it's easier for you to implement the typical method A logic in your interface. For users, it's easier if there are few parts that they implement.

There are the following two patterns to achieve this.

• Implementation assistance: Declare the interface method by default and implement the logic in the interface. In the previous example, add default to the declaration part of method A to implement the logic. default is available from Java 8. If this is all you need, you will get the full benefits of the interface, so consider this option first instead of the skeleton implementation shown below.
• Skeleton implementation: Implement the interface with implementation assistance with an abstract class. There are some restrictions, such as not being able to implement methods of the Object class such as equals in the default interface. You can cover (implement) those parts with an abstract class. A concrete example of this pattern is AbstractList. In addition, since it is assumed that it will be inherited, let's write Javadoc firmly according to item 19.

Item 21 Design the interface for the future

Once the interface is published, it's the last. It's not so easy to change. Let's verify it thoroughly before publishing.

If you add a method to an interface later, the class that implements that interface will get a compile error. You can use default as a "Tips" to avoid the problem, but this is NG in the following points. It is important to design firmly without relying on default.

• default does not exist for that purpose.
• If the default method calls an existing method of the interface, it may break the internal state of the class that implemented the interface. It feels like the site is confused because unreasonable rules are unilaterally imposed without understanding the situation at the site.

Item 22 Use the interface only to define the type

There is a method of defining constants in an interface and implementing the interface so that the class can use the constants. This is NG. The JDK actually has such an interface, but don't copy it.

This is because the class makes use of the constants of other components, which is an implementation detail. Implementing an interface means making that part a public API. Implementation details should not be public APIs. In the first place, exposing constants is out of the question because it is far from the essence of the interface.

If you want to provide the constant to the outside, do one of the following.

• If a constant is strongly tied to a particular class, add it inside that class. For example, Integer.MAX_VALUE.
• If a constant is considered a member of an enum, define it as an enum.
• In other cases, define it in a non-instantiable utility class.

//Non-instantiable utility class
public class PhysicalConstatns(){
    private PhysicalConstants() {} //Prevent instantiation

    public static final double AVOGADROS_NUMBER = 6.022_140_857e23;
}

By statically importing the constant class, the user does not have to write the class name every time the constant is used. It is explained in the book, but when you look back at it later, you will be asked "Where is this constant defined?", Which can be difficult to read. Consider the balance when deciding whether a static import is appropriate.

Item 23 Select a class hierarchy rather than a tagged class

Suppose you have a class in one class that expresses whether it is a circle or a rectangle. Some of them have constructors, fields, and methods that are used for circles, and some are used for rectangles as well.

Classes that try to express multiple concepts in one class in this way are called "tagged classes" in books.

If you want to express multiple concepts, divide the classes obediently. Specifically, let's use inheritance / subtyping to organize them into a hierarchical structure. It's natural.

Item 24 Select a static member class over a non-static member class

Sometimes you want to declare another class inside a class. In this context, the former class is called the "enclosing class" and the latter class is called the "nested class".

There are several ways to implement a nested class. Specifically, there are the following four.

• static member class
• Non-static member class
• Anonymous class
• Local class (a class declared with a name in a method)

Let's use these properly. Considering the following flow, there should be no mistake.

Examination step 0

Is it possible that the "nested class" I'm trying to create will be used by another class, regardless of the enclosing class?

If YES, it shouldn't be created as a nested class in the first place. It should be created as just an ordinary class, independent of the enclosing class.

Examination step 1

If the "nested class" you are trying to create is all of the following, use ** anonymous class **.

• Used only in certain methods of the enclosing class.
• The declaration part of the nested class is short. If it is too long, the methods of the enclosing class will be difficult to read.
• ** Instantiate only in one place **.

If an anonymous class is declared in a non-static method of the enclosing class, the instance of the anonymous class will automatically refer to the instance of the enclosing class. In some cases this causes a memory leak. Be aware of the danger before using it.

This does not happen if it is declared inside a non-static method.

Examination step 2

If the "nested class" you are trying to create is all of the following, use ** local class **.

• Used only in certain methods of the enclosing class.
• The declaration part of the nested class is short.
• Instantiate ** in multiple places within that method. If it is used in multiple places, it must be declared with a name.

Examination step 3

If the "nested class" you are trying to create is all of the following, use a ** non-static member class **.

• One of the following applies.
• The declaration part of the nested class is long.
• Used by multiple methods of the enclosing class.
• Need to access an instance of the enclosing class ** is **. When a non-static member class is instantiated, it automatically references the enclosing class instance from that instance. In some cases this causes a memory leak. Be aware of the danger before using it.

Examination step 4

If the "nested class" you are trying to create is all of the following, use a ** static member class **.

• One of the following applies.
• The declaration part of the nested class is long.
• Used by multiple methods of the enclosing class.
• No need to access an instance of the enclosing class **. There is no danger like non-static member classes, so choose this as much as possible.

Item 25 Limit source files to a single top-level class

Normally, you wouldn't implement multiple top-level classes in a single source file. This item explains why it's NG, but you don't need to know the reason because you don't do that in practice in the first place. (end)

Chapter 5 Generics

Item 26: Do not use the prototype

A prototype is an expression that does not involve a type parameter, such as List instead ofList <String>.

It's no longer common sense that you shouldn't use the prototype. The reason is that you may get a ClassCastException at run time. If you implement it with type parameters, you can notice such risks in the form of compile errors and compile-time warnings. Let's not use the prototype.

However, there is a situation where you may inadvertently use the prototype. Specifically, it is as follows.

【NG】

//Don't do this just because you don't know the type parameters of Set.
static int numElementsInCommon(Set s1, Set s2) {
    int result = 0;
    for (Object o1 : s1)
        if(s2.contains(o1))
            result++;
    return result;
}

Let's implement it as follows.

【OK】

//If you do this, you will get a compile error when you try to add an element to s1 or s2.
//It's definitely better than noticing at runtime. (However, null can be added)
static int numElementsInCommon(Set<?> s1, Set<?> s2) {
    //Abbreviation
}

Item 27 Remove uninspected warning

When implemented using generics, the risks leading to a ClassCastException at runtime can be noticed by compile errors and compile-time warnings.

You can compile the warnings if you leave them alone, but as a general rule, respond to all the warnings and fix them so that they do not appear. Add @SuppressWarning ("unchecked ") to suppress the warning only if there is really no problem. By the way, "unchecked" is a warning that means "I haven't checked the type, but is it okay?"

If you don't suppress the warning when it's really okay, you won't notice the really problematic warning. Let's not cut corners there either.

Item 28 Select a list rather than an array

Due to historical background, sequences and generics have different properties. Because of that, using them in combination causes problems. Unless you have a noticeable problem with code simplicity or performance, implement it uniformly in Generics.

What kind of problems will occur when used in combination?

If you implement both in combination, you will not understand the meaning of the errors and warnings issued by the compiler, and you will be unnecessarily confused. In some cases, the warning is suppressed without careful consideration, resulting in a ClassCastException or asking maintenance members "Why are you doing @SuppressWarning here ...? " Will embrace and confuse you.

For example ...

• Arrays with generics as elements, such as List <String> [], will result in a compile error. If you allow it, you can get a ClassCastException. You might think it doesn't matter because you don't do that, but that's not the case. For example, a variadic method creates an array to hold variadic arguments. If you make the argument a generic type, you will get a warning that is difficult to understand. If you don't understand what's happening behind the scenes, you won't be able to solve it properly. new E [] is also useless.

• As a result of implementing it ad hoc without understanding the meaning of compilation errors and warnings, the following NG classes are created.

  public class Chooserr<T> {
      private final T[] choiceArray;
  
      public Chooser(Collection<T> choices) {
          //choices may be the type that holds T,
          //Often toArray()Is T[]There should be no guarantee that it will return.
          //You may get a ClassCastException at run time.
          //I don't understand the meaning@It is NG to Suppress Warnings.
          @SuppressWarning("unchecked")
          choiceArray = (T[]) choices.toArray();
      }
  }
  

Why does this happen?

This is because there are the following differences between the two. (Although the book explains, it doesn't explain why these differences lead to the above problems ... I'll add more commentary later if I have time.)

• Covariant is translated as covariant and invariant is translated as invariant, but these Japanese translations only lead to confusion. You had better not remember.

Item 29 Use generic type

When you create your own class, you should make it as generic as possible. By doing so, users will have the following benefits:

• You can eliminate the risk of a ClassCastException at run time.
• Users do not have to cast the return value one by one.

In some cases, it may be better to use arrays inside your own class. For example, if you want to create a basic generic type like ArrayList, or if you have performance reasons.

In these cases, you'll have to do @SuppressWanings ("unchecked ") inside the class to suppress compile-time warnings. Of course, it goes without saying that we should carefully consider whether it is really appropriate to suppress it.

Item 30 Use generic method

When you write your own method, you should make it as generic as possible. By doing so, the user will get the same benefits as item 29.

First, I will explain the case of defining a normal generic method.

[NG] Non-generic method

//If the type of the object to be held is different between s1 and s2, ClassCastException will be thrown at runtime.
public static Set union(Set s1, Set s2) {
    Set reslut = new HashSet(s1);
    result.addAll(s2);
    return result;
}

[OK] Generic method

//The type parameters used in the method (list of) must be declared between the qualifier and the return type.
//In this example, it's right after static<E>That is.
public static <E> Set<E> union(Set<E> s1, Set<E> s2) {
    Set<E> reslut = new HashSet<>(s1);
    result.addAll(s2);
    return result;
}

Next is the case of implementing an advanced generic method. I will introduce the following two techniques.

• Generic singleton factory
• Recursive boundary

Technique # 1: Generic Singleton Factory

Let's say you need an API that has the role of returning an object that works with the type specified by the user. If the object to be created does not have a state, it is useless to create the object every time because the type specified by the user is different.

The generic singleton factory is a technique that can make an object a singleton (that is, reduce the cost of creating an instance and the amount of memory used) while operating with the type specified by the user.

The book gives an identity function as an example of this. By the way, the identity function is a function that returns the parameters as they are. What is it useful for? You may think that it appears as one of the activation functions in the area of machine learning. I have to specify something in the API as an activation function, but I don't want to do anything, so there is a use such as specifying a function that does virtually nothing.

//Point of this technique ①
private static UnaryOperator<Object> IDENTITY_FN = (t) -> t;

//Point of this technique ②
@SuppressWarnings("unchecked")
public static <T> UnaryOperator<T> identityFunction() {
    return (UnaryOperator<T>) IDENTITY_FN;
}

** Points of this technique ① **

Because the generics are implemented by eraser, it is OK to just return one instance called IDENTITY_FN no matter what type is specified by the user.

On the other hand, if the generics are embodied, that is, if IDENTITY_FN remembers the type parameter specified by the user even at runtime, one instance called IDENTITY_FN cannot handle it.

For example, if a user calls identityFunction () with a String as the type parameter, IDENTITY_FN must be ʻUnaryOperator ` (a world where generics are embodied). In this case, in order to correspond to the person who wants to specify Long as the type parameter, the Long version of IDENTITY_FN must be prepared. You'll also need a Long version of the identityFunction () method that returns that object.

** Point of this technique ② **

When I try to implement a generic singleton factory, I cast it without inspection, is that okay? Will be warned. But in many cases it's okay. Recognize the reason and suppress the warning.

First, what does the uninspected cast warning mean in this example?

ʻUnaryOperator