• 기본 타입 / 박싱 타입의 차이

기본 타입과 박싱된 기본 타입을 혼용한 연산에서는 박싱된 기본 타입의 박싱이 자동으로 풀린다.

static Integer i;

public static void main(String[] args) {
    if ( i == 42) //null 참조를 언박싱하면서 NullPointerException이 발생한다
        System.out.println("믿을 수 없군!"); 
}

박싱된 기본 타입을 사용하는 경우

• 컬렉션의 원소, 키, 값
• 매개변수화 타입이나 매개변수화 메서드의 타입 매개변수로는 박싱된 기본 타입을 사용
• 리플렉션을 통해 메서드를 호출할 때도 박싱된 기본 타입 사용

컬렉션이나 배열 같은 컨테이너(container)가 비었을 때 null을 반환하는 메서드를 사용하면 방어 코드를 넣어줘야 한다.

private final List<Cheese> cheesesInStock = ....;

public List<Cheese> getCheeses() {
	return cheesesInStock.isEmpty() ? null : new ArrayList<>(cheesesInStock);
}

제거기 앖디거 특별한 취급을 할 필요는 없지만 아래와 같이 방어 코드가 필요하다.

List<Cheese> cheese = shop.getCheeses();
if (cheese != null && cheeses.contains(Cheese.STILTON)) 
	Sytem.out.println("좋았어, 바로 그거야.");

사용 패턴에 따라 빈 컬렉션 할당이 성능을 떨어뜨리는 경우 매번 똑같은 빈 '불변' 컬렉션을 반환하면 된다.

Collections.emptySet, Collections.emptyMap을 사용하면 된다. 

최적화가 필요하다고 판단되면 수정 전과 후의 성능을 측정하여 실제로 성능이 개선 되는지 꼭 확인하자.

return cheeseInStock.toArray(new Cheese[cheeseInStock.size()]);

null이 아닌, 빈 배열이나 컬렉션을 반환하라. null을 반환하는 API는 사용하기 어렵고 오류 처리 코드도 늘어난다. 그렇다고 성능이 좋은 것도 아니다.

전통적인 명명 패턴의 단점

• 오타 발생 시 컴파일러는 메서드를 무시하고 지나칠 수 있어 개발자는 오류가 없다고 인식할 수 있다.
• 올바른 프로그램 요소에 사용하지 않을 경우에 컴파일 오류, 런타임 오류 등 개발자가 인지할 수 있는 수준의 오류가 발생하지 않는다.
• 프로그램 요소를 매개변수로 전달할 방법이 없다.

애너테이션은 명명 패턴의 문제를 해결해주는 개념으로 Junit에도 버전 4부터 전면 도입됐다. 

애너테이션 선언에 다는 애너테이션을 메타애너테이션(meta-annotation)이라 한다.

대상 코드의 의미는 그대로 둔 채 그 애너테이션에 관심 있는 도구에서 특별한 처리를 할 기회를 준다.

질문 정리

• '이 코드는 EnumMap이 아닌 고유한 맵 구현체를 사용했기 때문에 EnumMap을 써서 얻은 공간과 성능 이점이 사라진다' 에 대한 설명

EnumMap은 key로 enum객체를 가질 수 있고 enum은 순차적인 정수값(ordinal)를 가지기 때문에 EnumMap은 Array배열에 데이터를 저장하게 된다. 즉, 일반적인 Map과 달리 hashing작업(hash만들고 해싱 충돌 관리 등)을 할 필요가 없고 key값인 enum사이즈 만큼 값을 가지기 때문에 특정 사이즈 이상 커지면 resizing해야하는 Map과 달리 성능성의 이점을 가질 수 있다.

• [item36. 223p가장 맨 밑~ 224p] 정수 상수보다 열거 타입을 선호하는 프로그래머 중에도 상수 집합을 주고 받아야 할 때는 여전히 비트 필드를 사용하기도 한다.
  Q. 자바에서 비트 필드를 활용하는 예가 있을까요? 검색하면 C, C++ 에서만 활용하는 예제가 나와서 자바에서 비트필드를 활용하는지 궁금합니다.

보통 비트 단위 작업은 임베디드 시스템, 하드웨어 드라이버, 네트워크 프로토콜, 이진 파일 형식 및 문자 인코딩, 암호화 등 하드웨어 제어 수준에서 사용하여 보통의 프로그래머가 사용할 일은 없습니다.

• [item38. 235p]
  자바 라이브러리도 이번 아이템에서 소개한 패턴을 사용한다. 그 예로, java.nio.file.LinkOption 열거 타입은 CopyOption과 OpenOption 인터페이스를 구현했다.
  public enum LinkOption implements OpenOption, CopyOption {
      /**
       * Do not follow symbolic links.
       *
       * @see Files#getFileAttributeView(Path,Class,LinkOption[])
       * @see Files#copy
       * @see SecureDirectoryStream#newByteChannel
       */
      NOFOLLOW_LINKS;
  }
  Q. LinkOption 열거 타입에 해당 내용만 있어서,, 어떻게 CopyOption, OpenOption 인터페이스를 구현하여 이번 아이템에서 얘기한 것과 같이 CopyOption, OpenOption이 어떻게 정의되었고, LinkOption이 어떻게 이 인터페이스를 구현하는지 궁금합니다.!
  정리

API가 제공하는 기본 연산 외에 사용자 확장 연산을 추가할 수 있도록 열어줘야 할 때가 있다. 열거 타입이 임의의 인터페이스를 구현할 수 있다는 사실을 이용하는 것으로 연산 코드용 인터페이스를 정의하고 열거 타입이 이 인터페이스를 구현하게 하면 된다.

package java.nio.file;

/**
 * An object that configures how to copy or move a file.
 *
 * <p> Objects of this type may be used with the {@link
 * Files#copy(Path,Path,CopyOption[]) Files.copy(Path,Path,CopyOption...)},
 * {@link Files#copy(java.io.InputStream,Path,CopyOption[])
 * Files.copy(InputStream,Path,CopyOption...)} and {@link Files#move
 * Files.move(Path,Path,CopyOption...)} methods to configure how a file is
 * copied or moved.
 *
 * <p> The {@link StandardCopyOption} enumeration type defines the
 * <i>standard</i> options.
 *
 * @since 1.7
 */

public interface CopyOption {
}

/*
 * Copyright (c) 2007, 2011, Oracle and/or its affiliates. All rights reserved.
 * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
 */

package java.nio.file;

/**
 * An object that configures how to open or create a file.
 *
 * <p> Objects of this type are used by methods such as {@link
 * Files#newOutputStream(Path,OpenOption[]) newOutputStream}, {@link
 * Files#newByteChannel newByteChannel}, {@link
 * java.nio.channels.FileChannel#open FileChannel.open}, and {@link
 * java.nio.channels.AsynchronousFileChannel#open AsynchronousFileChannel.open}
 * when opening or creating a file.
 *
 * <p> The {@link StandardOpenOption} enumeration type defines the
 * <i>standard</i> options.
 *
 * @since 1.7
 */

public interface OpenOption {
}

책에있는 예시보단 StandardOpenOption, StandardCopyOption enum 클래스가 이 예제에 더 적합해보입니다.

• p.225 주석.2 구아바 라이브러리를 EnumSet을 사용해 구현해서 성능면에서는 손해 라고 되어있는데, 정확한 이유를 알고 싶습니다. 참고 : 구아바소스 (https://github.com/google/guava/blob/e62d6a0456420d295089a9c319b7593a3eae4a83/guava/src/com/google/common/collect/ImmutableSet.java)
  ImmutableSet.java
  ```
  /*
  * Copyright (C) 2007 The Guava Authors
  *
  * Licensed under the Apache License, Version 2.0 (the "License");

불변 객체와 가변 객체의 성능을 생각하면 된다. 불변 객체는 한번 생성되고 나면 재할당 및 값을 변경할 수 없고 GC의 성능을 올려주나 가변 객체는 재할당할 수 있다.

• 아이템 39. 메타 어노테이션에 대해 좀 더 자세히 궁금합니다!

메타 어노테이션은 어노테이션에 대한 설명을 담은 어노테이션

https://github.com/naver/lucy-xss-servlet-filter/tree/master/src

일반 클래스를 제네릭 클래스로 만드는 방법

• 클래스 선언에 타입 매개 변수를 추가
• 제네릭 배열 생성을 금지하는 제약 우회 :  Object 배열을 생성한 다음 제네릭 배열로 형변환 - 비검사 형변환이 안전하다면 @SuppressWarnings 애너테이션으로 해당 경고를 숨긴다 -> 해당 방식을 제일 많이 선호
• elements 필드 타입을 E[]에서 Object[]로 바꾸는 것이다.

대다수의 제네릭 타입은 타입 매개변수에 아무런 제약을 두지 않는다. 단 기본 타입은 사용할 수 없어 박싱된 기본 타입을 사용해 우회할 수 있다.

뒷 장에서 알아볼 내용

런타임 타입이 컴파일타임 타입과 달라 힙 오염(heap pollution : 아이템 32)

• 배열은 공변이고 제네릭은 불공변이다. 이는 Sub가 Super의 하위 타입이면 배열 Sub[]도 Super[]의 하위 타입이 된다.
• 배열은 실체화(reify)된다. 제네릭 배열은 런타임 시 ClassCastException이 발생할 수 있어 지원하지 않는다.
• E, List<E>, List<String> 같은 타입을 실체화 불가 타입 - 런타임에는 컴파일타임보다 타입 정보를 적게 가지는 타입
• 제네릭 컬렉션에서는 자신의 원소 타입을 담은 배열을 반환하는게 보통은 불가능하다. 또한 제네릭 타입과 가변인수 메서드(varargs method, 아이템53)를 함께 쓰면 해석하기 어려운 경고 메시지를 받게 된다.
• 배열로 형변환할 때 제네릭 배열 생성 오류나 비검사 형변환 경고가 뜨는 경우 대부분은 배열인 E[]대신 컬렉션인 List<E>를 사용하면 해결된다.

뒷 장에서 확인할 내용

완벽하지는 않지만 대부분의 상황에서 이 문제를 해결해주는 방법을 아이템 33에서 설명한다. 

제네릭을 사용하면 컴파일러 경고를 많이 마주치게 되는데 할 수 있는 한 모든 비검사 경고를 제거해야한다. 

• 모두 제거하면 해당 코드는 타입 안전성을 보장할 수 있다. ClassCastException이 발생할 일이 없다.
• @SuppressWarnings("unchecked")은 경고는 제거할 수 없으나 타입 안전성을 확보했을 때 해당 애너테이션을 달아 경고를 숨길 수 있다.
• @ SuppressWarnings 애너테이션은 항상 가능한 한 좁은 범위에 적용
• @SuppressWarnings("unchecked") 애너테이션을 사용할 때면 그 경고를 무시해도 안전한 이유를 항상 주석으로 남겨야 한다.

태그 달린 클래스의 단점

• 열거 타입 선언, 태그 필드, switch 문 등 쓸데없는 코드가 많다.
• 단일 책임 원칙 (Single responsibility principle)의 원칙에 어긋나 가독성도 나쁘고 메모리도 많이 사용한다.
• switch문에 새로운 의미를 처리하는데 빼고 작성하면 런타임 시에나 문제를 발견한다.
• 인스턴스 타입만으로 클래스의 목적을 알 수 없다.

태그 달린 클래스는 장황하고 , 오류를 내기 쉽고, 비효율적이다.

클래스 계층구조를 활용하는 서브타이핑은 타입 하나로 다양한 의미의 객체를 표현한다.

1. 계층구조의 루트(root)가 될 추상 클래스를 정의
2. 태그 값에 따라 동작이 달라지는 메서드를 루트 클래스의 추상 메서드로 선언
3. 태그 값에 상관없이 동작이 일정한 메서드를 루트 클래스에 일반 메서드로 추가
4. 모든 하위 클래스에서 공통으로 사용하는 데이터 필드도 전부 루트 클래스로 올림
5. 루트 클래스를 확장한 구체 클래스를 의미별로 정의

각  의미를 독립된 클래스에 담아 관련 없던 데이터 필드를 모두 제거

• 디폴트 메서드를 선언하면, 해당 인터페이스를 구현한 후 디폴트 메서드를 재정의하지 않은 클래스에는 디폴트 구현이 사용된다. 
• 디폴트 메서드는 (컴파일에 성공하더라도) 기존 구현체에 런타임 오류를 일으킬 수 있다. 
• 인터페이스를 릴리스한 후라도 결함을 수정하는 게 가능한 경우도 있겠지만, 절대 그 가능성에 기대서는 안 된다.

• 자바 8부터 인터페이스도 디폴트 메서드(default method)를 제공할 수 있게 되었다.(https://docs.oracle.com/javase/specs/jls/se17/html/jls-9.html#jls-9.4.3)
• 인터페이스는 믹스인(mixin)정의에 안성맞춤이다. - 믹스인 : 클래스의 주된 목적 외에 특정 선택적 기능을 제공(Comparable 자신을 구현한 클래스의 인스턴스들끼리 순서를 정할 수 있다.)
• 인터페이스로는 계층구조가 없는 타입 프레임워크를 만들 수 있다. 거대한 클래스 계층구조에는 공통 기능을 정의해놓은 타입이 없으니, 자칫 매개변수 타입만 다른 메서드들을 수없이 많이 가진 거대한 클래스를 낳을 수 있다.
• 래퍼 클래스 컴포지션(아이템 18)과 함께 사용하면 인터페이스는 기능을 향상시키는 안전하고 강력한 수단이 된다. 
• 인터페이스 + 추상 골격 구현 클래스 함께 제공하는 템플릿 메서드 패턴은 골격 구현을 확장하는 것으로 인터페이스를 구현하는데 필요한 일을 모두 할 수 있다.

static List<Integer> intArrayAsList(int[] a) {
        Objects.requireNonNull(a);
        
        //다이아몬드 연산자를 이렇게 사용하는 건 자바 9부터 가능하다.
        // 더 낮은 버전을 사용한다면 <Integer>로 수정하자.
        return new AbstractList<Integer>() {
            @Override
            public Integer get(int index) {
                return a[i];
            }
            
            @Override public Integer set(int i, Integer val) {
                int oldVal = a[i];
                a[i] = val;
                return oldVal;
            }

            @Override
            public int size() {
                return a.length;
            }
        };
    }

위 코드는 골격 구현의 적합한 예시

골격 구현 작성 방법

1. 인터페이스에서 다른 메서드 구현에 사용되는 기반 메서드(->추상메서드)를 선정 
2. 기반 메서드를 사용해 직접 구현할 수 있는 메서드를 디폴트 메서드로 제공
3. 기반, 디폴트 메서드가 아닌 대상을 골격 구현 클래스에 작성

인터페이스의 속성

• 인스턴스 필드를 가질 수 없다.
• public이 아닌 정적 멤버도 가질 수 없다.
• * private 정적 메서드는 예외로 가질 수 있다.
• 작성하지 않은 인터페이스에는 디폴트 메서드를 추가할 수 없다.

잘 설계된 컴퓨넌트는 내부 구현 정보를 캡슐화하여 숨기고 외부 컴포넌트는 API를 통해 외부와 정보를 주고 받을 수 있도록 분리되어 설계된다. 정보 은닉이 잘된 시스템은 아래와 같은 장점이 있다. 

• 컴포넌트별 캡슐화가 잘 되어 있어 병렬 개발할 수 있으며 이는 시스템 개발 속도를 높인다. 
• 시스템 관리 비용을 낮춘다. 캡슐화로 인해 오류 발생 시 컴포넌트별로 빠르게 파악할 수 있고 디버깅 시 연관도가 낮아 수정 개발이 편리하다.
• 성능 최적화를 할 수 있다. 완성된 시스템을 프로파일링해 최적화할 컴포넌트를 정해 해당 컴포넌트만 수정 & 변경을 통해 최적화할 수 있다.
• 소프트웨어 재사용성을 높일 수 있다.
• 큰 시스템을 제작하는 난이도를 낮춰준다. 

접근 제한자(private, protected, public)와 선언된 위치로 접근성이 제한된다. 접근 제한자를 활용하여 정보 은닉의 이점을 누릴 수 있다. 모든 클래스와 멤버의 접근성을 좁히면 된다. 

클래스, 인터페이스의 접근 제한자

* 외부 공개 API를 제공하는 목적이 아니면 public으로 선언하는 것은 고려해야한다.

접근 제어자(Access Modifier)

• private : 멤버를 선언한 클래스에서만 접근할 수 있다.
• package-private(default) : 멤버가 소속된 패키지 안의 모든 클래스에서 접근할 수 있다. 
• protected: package-private의 접근 범위를 포함하고 해당 멤버를 상속한 하위 클래스에서도 접근할 수 있다.
• public : 모든 곳에서 접근할 수 있어 공개 API이다.

해당 클래스, 클래스가 속한 패키지내의 구현 범위에 해당하는 private과 package-private는 공개 API에 영향을 주지 않는다. * Serializable을 구현한 클래스에서는 의도와 달리 공개 API가 될 여지가 있다.

테스트를 위해서 멤버 접근 범위를 넓히려 하는데 private -> package-private까지는 괜찮지만 그 이상은 적용하지 않는게 좋다. 테스트를 위함이라면 테스트 코드를 같은 패키지에 두면 package-private 요소에 접근할 수 있기에 package-private은 가능하다.

public 클래스의 인스턴스 필드는 public을 지양하는 게 좋다. 

• 가변 객체를 참조하거나 final이 아닌 경우 필드의 값을 제한할 수 없다. 
• 따로 스레드 처리를 하지 않을 경우 public 인스턴스 필드는 락 획득을 할 수 없어 어느 곳에서나 접근하여 값을 변경할 수 있는 thread safe하지 않다.

예외도 존재하는데 클래스의 추상 개념을 표현하는데 꼭 필요한 구성요소로의 상수라면 public static final필드로 공개해도 좋다. * public static final String DATE_FORMAT 대문자 알파벳으로 작성하며 단어 사이에 밑줄(_)을 작성한다. 이런 타입은 불변 객체나 기본 타입 값을 참조해야한다. 

• 가변 객체를 참조할 경우 setter를 통해 final이 아닌 필드의 값은 변경될 수 있다. 이럴 경우 의도하지 않게 값을 변경할 수 있는 가능성을 열어두게 된다. *final로 인스턴스를 생성했을 때의 동작방식에 대해 살펴보면 알 수 있다.

클래스에서 public static final 배열 필드를 두거나 이 필드를 반환하는 접근자 메서드를 제공해서는 안 된다. * 길이가 0이 아닌 배열은 모두 변경 가능하기 때문이다.

• 배열을 private으로 만들고 clone()으로 복사본을 반환하는 public static final 메서드를 제공하는 방법
• 동일하게 배열을 private으로 만들고 public 불변 리스트를 추가

자바 버전 9부터는 모듈 시스템(패키지들의 묶음이며 같은 모듈 안에 패키지들은 자유롭게 공유할 수 있다.)이라는 개념이 도입되면서 public 클래스의 public, protected 멤버에 한하여 같은 모듈 내부에서만 접근 가능하도록 한정했다. 이 같은 개념을 가장 잘 활용하는 사례가 JDK인데 자바라이브러리에서 공개하지 않는 패키지들은 해당 모듈 밖에서는 절대로 접근할 수 없다. 

뒷 장에서 확인해야할 내용

한 클래스에서만 사용하는 package-private 톱레벨 클래스나 인터페이스는 이를 사용하는 클래스 안에 private static으로 중첩시켜보자

단 Serializable을 구현한 클래스에서는 그 필드들도 의도치 않게 공개 API가 될 수 있다.(아이템 86,87)