Effective Java 3rd Edition Chapter 4 Classes and Interfaces

[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 3 Methods Common to All Objects Next: Effective Java 3rd Edition Chapter 5 Generics

Item 15 Minimize accessibility to classes and members

--Each class or member should be as inaccessible as possible.

Top-level classes and interfaces

--There are public and package private, and it should be package private as much as possible. Because it is no longer a public API for packages. --If a top-level package private class or interface is used by only one class, consider making it a private nested class within that class.

Members (fields, methods, nested classes, nested interfaces)

--Everything should be private at first, and only when you need to access other classes in the same package. --For members of the public class, accessibility is greatly increased if the package is changed from private to protected. --The need for protected members should be relatively rare. --When overriding a method of a superclass, the access level that the method has in the superclass is not allowed to be narrowed in the subclass (Java specification). --To some extent it is permissible to relax access restrictions on classes, interfaces and members for ease of testing. From private to packaging private. No more is accepted. --Instance fields should not be public. When it's a non-final, variable object reference, it gives up limiting the values that can be stored in that field. As a result, classes with public variable fields are generally not thread-safe. --Use public static final to expose constants. It is customary to use capitalized, underscore-separated names. It is imperative to have either a basic data type or a reference to an immutable object. Because the value will change. Note that non-zero length arrays are always variable.

//Potential security hole (the contents of the array can be changed)
public static final Thing[] VALUES = { ... };

//Solution 1. Returns a public immutable list
private static final Thing[] PRIVATE_VALUES = { ... };
public static final List<Thing> VALUES = 

//Solution 2. Returns a copy of the array in the public method
private static final Thing[] PRIVATE_VALUES = { ... };
public static final Thing[] values() { 
  return PRIVATE_VALUES.clone();

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

--Public classes should not expose variable fields. It should have a private field and a public accessor method (getter), and a mutator (setter) for variable classes. --For package-private or private nested classes, exposing their data fields directly is essentially fine.

Item 17 Minimize variability

--Immutable objects are simple. In essence thread safe. --For immutable classes, it is not necessary to provide clone method or copy constructor, and it should not be provided. --To make a class immutable, follow the following five principles. --Does not provide a method to change the state of an object. --Don't extend the class. --Make all folds final. --Make all folds private. --Guarantee exclusive access to variable components. --The practical drawback of immutable objects is that they require separate objects for different individual values. --Classes should be immutable unless there is a good reason to make them variable. --If you can't make a class immutable, you should limit its variability as much as possible.

Item 18 Select composition from inheritance

--Inheritance, when used improperly, creates fragile software. Inheritance breaks encapsulation. The proper functioning of subclasses depends on the implementation of the superclass. --Instead of extending an existing class, give the new class a private field that references an instance of the existing class. This design is called composition. --Each instance method of the new class calls the method corresponding to the existing instance of the class it holds and returns the result. This is called a transfer, and the new class of methods is called a transfer method. --The combination of composition and transfer is sometimes loosely referred to as delegation. Technically, it's not a delegation unless the wrapper object passes itself to the wrapped object.

Item 19 Design and document for inheritance, otherwise prohibit inheritance

--Designing a class for inheritance imposes considerable restrictions on that class. All self-use of the class must be documented, and once documented, it must be followed as long as the class exists. --Use the Javadoc tag of @implSpec to document for inheritance. --The best solution is to ban subclasses of classes that are neither designed nor documented for safe subclassing. There are two ways to ban subclasses. --Declare the class final. --Make the class constructor private or package private and add a public static factory method as an alternative to the constructor.

Item 20 Select an interface over an abstract class

--If there is an obvious implementation of a method with an interface, consider providing implementation assistance in the default method format. Providing default methods for Object methods such as equals and hashCode is not allowed. --The interface is not allowed to contain instance fields or non-public static members (other than private static methods). --By providing an abstract skeleton implementation class that accompanies an interface, you can combine the strengths of the interface and the abstract class. The skeleton implementation is based on the basic methods of the interface and implements the remaining non-basic methods of the interface. Most of the interface implementation is done by extending the skeletal implementation. (* Template Method * pattern) --By convention, the skeleton implementation class is named Abstract * Interface *. --For example, the collection framework provides skeletal implementations that accompany each major collection interface: AbstractCollection, AbstractSet, AbstractList, AbstractMap. --The great thing about skeleton implementation is that it provides implementation assistance, which is an abstract class, without imposing serious restrictions on the abstract class's role as a type definition. --A class that implements an interface can hold an instance of a private inner class that extends the skeleton implementation and forward the interface call to that instance. This technique is called pseudo-multiple inheritance.

Item 21 Design the interface for the future

--Before Java8, when you add a new method to an interface, the existing implementation doesn't have that method yet and you get a compile error. Java 8 added default method syntax, but adding methods to existing interfaces is risky. --The default method may be able to compile the interface implementation without errors or warnings, but it may fail at runtime. --Even if the default methods are part of the Java platform, careful interface design remains important. Adding methods carries a great deal of risk. --It is important to test a new interface before releasing it. At a minimum, three different implementations should be implemented and tested. It is difficult to fix interface defects after release.

Item 22 Use the interface only to define the type

--The interface, when implemented in a class, acts as a type that can be used to reference that instance. --You should not use the constant interface, which is just an interface for defining constants. --Constants should be provided in enum types or non-instantiable utility classes.

Item 23 Select a class hierarchy rather than a tagged class

--A class that has two or more characteristics and switches between them with an enum is called a tagged class, and has many drawbacks. Hard to read, increased memory, verbose, apologetic and inefficient. --Subtype to define a single data type that can represent objects with multiple characteristics. --Define an abstract class that contains abstract methods for individual operations. If there is common behavior or data, put it in an abstract class. --Define a subclass that embodies the root class for each characteristic.

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

――Four kinds of nested classes --Static member class (inner class) --Non-static member class --Anonymous class --Local class --The only syntactic difference between static and non-static member classes is that static member classes have a static modifier in their declaration. These two types of nested classes are different. --Each instance of a non-static member class is implicitly associated with the enclosing instance of the class that contains it. Within an instance method of a non-static member class, you can call the method on the enclosing instance, or you can get a reference to the enclosing instance using the qualified this syntax. -(Planned to be added)

static member class

class Outer {
    private int outerField;
    private static int a;

    //static member class
    static class Inner {
        void innerMethod() {
            //Only available for static external class members
            a = 10;

    //Methods inside the outer class
    void outerMethod() {
        Inner ic = new Inner();

class Main {
    public static void main(String[] args) {
        // Outer.Used in Inner
        Outer.Inner ic = new Outer.Inner();

Non-static member class

class Outer {
    private static int outerField;
    private int b;

    //Non-static member class
    class Inner {
        void innerMethod() {
            outerField = 10;
            b = 5;

    //Methods inside the outer class
    void outerMethod() {
        Inner ic = new Inner();

class Main {
    public static void main(String[] args) {
        Outer o = new Outer();
        // o.Used in new
        Outer.Inner in = o.new Inner();

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

--Do not put multiple top-level classes in a single source file. The reason is that the compiler may not recognize the class correctly.

Recommended Posts

Effective Java 3rd Edition Chapter 4 Classes and Interfaces
Effective Java 3rd Edition Chapter 6 enums and annotations
Effective Java 3rd Edition Chapter 7 Lambda and Streams
Effective Java 3rd Edition Chapter 5 Generics
Effective Java 3rd Edition Chapter 8 Methods
Effective Java 3rd Edition Chapter 2 Object Creation and Disappearance
Effective Java 3rd Edition Chapter 9 Program General
Effective Java 3rd Edition Chapter 3 Methods Common to All Objects
What has changed between Effective Java 2nd Edition and 3rd Edition
Effective Java Chapter 2
Effective Java Chapter 6 34-35
Effective Java Chapter 4 15-22
Effective Java Chapter 3
effective java 3rd summary
java (classes and instances)
Effective Java 3rd Edition Section 85 Choose Alternatives Over Java Serialization
[Java] Generics classes and generics methods
Java abstract methods and classes
Java and first-class functions-beyond functional interfaces-
Java generics (defines classes and methods)
Classes and instances Java for beginners
A note on the differences between interfaces and abstract classes in Java
Java programming (classes and instances, main methods)
[Read Effective Java] Chapter 2 Item 7 "Avoid Finalizers"
JAVA learning history abstract classes and methods
[Details] Let's master abstract classes and interfaces! !!
[Java ~ Classes and External Libraries ~] Study Memo (6)
[Java] Personal summary of classes and methods (basic)
Parallel and parallel processing in various languages (Java edition)
Effective Java 2nd Edition Related Matters Survey Summary
Understand the difference between abstract classes and interfaces!
[Read Effective Java] Chapter 3 Item 10 "Always Override toString"
Differences in writing Java, C # and Javascript classes
Kantai Collection Java # 1 Classes and Objects [For Beginners]
Classes and instances
I tried to explain Effective Java 3rd edition "almost all chapters" in "easy-to-read Japanese".
Java and JavaScript
XXE and Java
[Read Effective Java] Chapter 2 Item 6 "Remove obsolete object references"
Java classes and instances to understand in the figure
Equivalence comparison of Java wrapper classes and primitive types
Updates from Effective Java Third Edition 2nd Edition Personal Notes
I will write an excerpt of what I found interesting while reading Effective Java 3rd Edition