1. 할수있는 한 모든 비검사 경고를 제거하자

제네릭을 사용하기 시작했을 때 볼 수 있는 수많은 컴파일러 경고

• 비검사 형변환 경고
• 비검사 메서드 호출 경고
• 비검사 매개변수화 가변인수 타입 경고
• 비검사 변환 경고

새로 작성한 코드가 한번에 깨끗하게 컴파일되리라 기대하지는 말자

Java7 부터 제네릭 타입추론이 가능해졌다.

Set<Lark> exaltation = new HashSet<>();

할 수 있는 한 모든 비검사 경고를 제거하라 : 모두 제거하면 타입 안정성이 보장된다.
런타임에 ClassCastException이 발생할 일이 없고, 내가 의도한대로 잘 동작한다.

2. @SuppressWarning

a. 경고를 제거할 수는 없지만 타입 안전하다고 확신할 수 잇을 때 @SuppressWarning으로 경고를 숨기자

• 검증 없이 경고 숨길 때 : 경고없이 컴파일이 되어도 런타임에 여전히 ClassCastException을 던질 수 있다.
• 안전한데 안숨길 때 : 진짜 문제를 알리는 새로운 경고가 나와도 눈치채지 못할 수 있다.

b. 가능한 한 좁은 범위에 적용하자 : 변수 선언, 짧은 메서드, 생성자
범위가 필요이상으로 넓어지면, 지역변수를 하나 선언하고 그 변수에 애너테이션을 달아준다.

c. @SuppressWarning("unchecked") 애너테이션을 사용할 때 그 경고를 무시해도 안전한 이유를 항상 주석으로 남겨야한다.
다른사람이 코드를 이해하는데 도움이 되고, 다른사람이 그 코드를 잘못 수정할 경우를 막는다.

1. 용어정리

public class<T> Example{
     private T member; 
}

• 제네릭 클래스[인터페이스] : 클래스[인터페이스] 선언에 타입 매개변수(type parameter)가 쓰인다. Example.class
• 제네릭 타입(Generic Type) : 제네릭 클래스와 제네릭 인터페이스를 통틀어 이르는 말. Example<T>
• 매개변수화 타입(parameterized Type) : 각각의 제네릭 타입은 parameterizedType을 선언함. Example<String>
• 타입 매개 변수(Type parameter) : 제네릭 선언에 사용된 매개변수 <T>
• formalType : Example<E>
• actualType : Example<String>
• 로타입(raw type) : 제네릭 타입에서 타입 매개변수를 전혀 사용하지 않았을 때. Example
  로타입은 제네릭 전후 코드의 호환을 위한 것이며, 동작하지만 좋은 예는 아니다.

2. 제네릭의 타입 안정성

오류는 가능한 한 발생 즉시, 이상적으로는 컴파일 타임에 발견하는 것이 좋다.

a. 로타입의 단점 : 컴파일 타임에 타입 정보를 알지 못한다.

ClassCastException과 같은 런타임에야 알아챌 수 있는 에러를 만들기 쉽다.

실제로 아래 예제는, 로타입의 사용으로 인해 컴파일 타임에는 문제가 없으나, 실제 런타임에는 ClassCastException이 터진다.
Integer값을 String값으로 캐스팅하려 했기 때문이다.

public class Raw {
    public static void main(String[] args) {
        List<String> strings = new ArrayList<>();
        unsafeAdd(strings, Integer.valueOf(42));
        String s = strings.get(0); // 컴파일러가 자동으로 형변환 코드를 넣어준다.
    }

    private static void unsafeAdd(List list, Object o) {
        list.add(o);
    }
}

b. 제네릭의 장점 : 컴파일 타임에 타입 선언이 녹아든다.

컴파일러가 타입선언에 대해 인지하고 있기 때문에, 아무런 경고 없이 컴파일되면 의도대로 동작할 것임을 보장한다.

public class Raw {
    public static void main(String[] args) {
        List<String> strings = new ArrayList<>();
        unsafeAdd(strings, "42");   // 컴파일 타임에 에러를 체크해주어서 바꿀 수 있다.
        String s = strings.get(0);
    }

    private static <T> void unsafeAdd(List<T> list, T o) { // 제네릭 선언
        list.add(o);
    }
}

컴파일러가, 컬렉션에서 원소를 넣는 모든 곳에 보이지 않는 형변환을 추가하여 절대 실패하지 않음을 보장하였다.

++ 추가 내용

3. 로타입은 절대로 사용하지 말자.

제네릭이 안겨주는 안정성과 표현력을 모두 잃게된다.

a. 로타입이 만들어진 이유 - 호환성

기존 코드를 모두 수용하면서 제네릭을 사용하는 새로운 코드와 맞물려돌아가게 하기 위해서이다.
호환성 : 로타입 지원 + 제네릭 구현시 소거(erasure) 방식을 이용

List vs List<Object>

• List : 로타입 - 제네릭타입에서 완전 발은 떼었다.
• List<Object> : 임의 객체를 허용하는 매개변수화 타입 - 타입에 대한 정보를 컴파일러에 알려주었다.
• 제네릭의 하위타입 규칙 : List<String>은 로타입인 List의 하위타입이지만, List<Object>의 하위타입은 아니다.

로타입을 사용하면 타입 안정성을 잃게된다.

4. 타입 안전 + 유연 : 비한정 와일드카드 타입

비한정 와일드카드 타입(unbounded wildcard type) : 제네릭 타입을 쓰고 싶지만, 실제 타입 매개변수가 무엇인지 신경쓰고 싶지 않을 때 사용한다. Set<E>의 비한정 와일드카드 타입은 Set<?>

static int numElementsInCommon(Set<?> s1, Set<?> s2){...}

와일드카드 타입은 안전하고 로타입은 안전하지 않다.

• 로타입 : 아무 원소나 넣을 수 있어 타입 불변식을 훼손하지 쉽다.
• 와일드카드 타입 : Collection<?>에는 어떤 원소도 넣을 수 없다. (null 외에는)

  컴파일 타임에 오류메세지를 볼 수 있다.
  컬렉션의 타입 불변식을 훼손하지 못하게 막고, 컬렉션에서 꺼낼 수 있는 객체의 타입도 알수 없게 한다.

5. 로타입의 규칙예외

a. class 리터럴에는 로타입을 사용한다

자바 명세 자체가 class 리터럴에 매개변수화 타입을 사용하지 못하게 하였다.

• 허용 : List.class, String[].class, int.class
• 불가 : List<String>.class, List<?>.class

b. Instanceof 연산자는 로타입을 사용한다.

instanceof 연산자는 비한정 와일드카드 타입 이외의 매개변수화 타입에는 적용할 수 없다.

로타입이든 비한정적 와일드카드 타입이든 instanceof는 똑같이 동작한다. : <?> 코드만 지저분해지므로 로타입

런타임에는 제네릭 타입정보가 지워진다.

if(o instanceof Set){            // 로타입
  Set<?> s = (Set<?>) o;    // 와일드카드 타입
}

6. 용어정리

소스파일 하나에 톱레벨 클래스를 여러개 선언하더라도 자바 컴파일러는 불평하지 않는다.

• 다만 위와 같이 이름이 중복되는 경우 컴파일 에러가 발생하게된다.
• 컴파일러에 어느 소스파일을 먼저 건네느냐에 따라 동작이 달라지므로 반드시 바로잡아야한다.

해결책

• 톱레벨 클래스들을 서로 다른 소스 파일로 분리한다
• 다른 클래스에 딸린 부차적인 클래스라면 정적 멤버 클래스를 사용한다.

  private으로 선언하여 접근 범위도 최소로 관리하자

1. 중첩클래스란

중첩 클래스(nested class) : 다른 클래스 안에 정의된 클래스

• 정적 멤버 클래스
• (비정적) 멤버 클래스
• 익명 클래스
• 지역클래스

정적 멤버 클래스를 제외한 나머지는 내부 클래스라고 한다 (inner class)

2. 정적 멤버 클래스

일반 클래스와 다른점

• 다른 클래스 안에 선언된다.
• 바깥 클래스의 private 멤버에도 접근할 수 있다.

다른 정적 멤버와 똑같은 접근 규칙을 적용받는다.

바깥 클래스와 함께 쓰이는 public 도우미 클래스로 사용된다.

public class Calculator{
  public enum Operator{ // 열거타입도 정적 멤버 클래스이다
    PLUS(),MINUS()
  }
  public static class Operator{ // 대부분 이처럼 선언

  }
}

3. 비정적 멤버 클래스

정적 멤버 클래스와의 차이

• 구문상 차이 : static이 있고 없고 차이
• 의미상 차이 : 비정적 멤버 클래스의 인스턴스와 바깥 클래스의 인스턴스와 연결된다.
• 정규화된 this를 이용해 바깥 인스턴스의 인스턴스 메서드 호출이 가능하다. 클래스명.this

개념상 중첩 클래스의 인스턴스가 바깥 클래스의 인스턴스와 독립적으로 존재할 수 있다면 정적 멤버 클래스로 만들어야한다.

비정적 멤버클래스는 바깥 인스턴스 없이는 생성할 수 없다.

public class NestedNonStaticExample {
    private final String name;

    public NestedNonStaticExample(String name) {
        this.name = name;
    }

    public String getName() {
        // 비정적 멤버 클래스와 바깥 클래스의 관계가 확립되는 부분
        NonStaticClass nonStaticClass = new NonStaticClass("nonStatic : ");
        return nonStaticClass.getNameWithOuter();
    }

    private class NonStaticClass {
        private final String nonStaticName;

        public NonStaticClass(String nonStaticName) {
            this.nonStaticName = nonStaticName;
        }

        public String getNameWithOuter() {
            // 정규화된 this 를 이용해서 바깥 클래스의 인스턴스 메서드를 사용할 수 있다.
            return nonStaticName + NestedNonStaticExample.this.getName();
        }
    }
}

비정적 멤버 클래스의 인스턴스와 바깥 인스턴스 사이의 관계는 멤버 클래스가 인스턴스화될 때 확립되며, 더이상 변경할 수 없다.

드물게 직접 [바깥 인스턴스의 클래스].new MebmerClass(agrs) 를 호출해 수동으로 만든다. 그러나 이 관계정보는 비정적 멤버 클래스의 인스턴스 안에 만들어져 메모리 공간을 차지하며, 생성시간도 더 걸린다.

NestedNonStaticExample nestedNonStaticExample = new NestedNonStaticExample("name");
nestedNonStaticExample.new NonStaticPublicClass();

비정적 멤버 클래스의 쓰임 : 어댑터의 역할

• 어떤 클래스의 인스턴스를 감싸 마치 다른 클래스의 인스턴스처럼 보이게 하는 뷰로 사용한다.
• Map 인터페이스의 구현체 : 컬렉션 뷰를 구현할 때 비정적 멤버 클래스를 사용
• 컬렉션 인터페이스 구현체 : 자신의 반복자 구현

멤버 클래스에서 바깥 인스턴스에 접근할 일이 없다면 무조껀 static을 붙여서 정적 멤버클래스로 만들자

• 숨은 외부 참조를 갖게되며, 이 참조를 저장하기 위한 시간과 공간이 소비된다.
• GC가 바깥 클래스의 인스턴스를 수거하지 못하는 메모리 누수가 생길 수 있다.

4. 익명 클래스

• 이름이 없다!
• 바깥 클래스의 멤버도 아니다.
• 쓰이는 시점에 선언과 동시에 인스턴스가 만들어진다.
• 비정적인 문맥에서 사용될 때만 바깥 클래스의 인스턴스 참조가 가능하다
• 상수 정적변수 (static final) 외에는 정적 변수를 가질 수 없다.

public class AnonymousExample {
    private double x;
    private double y;

    public double operate() {
        Operator operator = new Operator() {
            @Override
            public double plus() {
                System.out.printf("%f + %f = %f\n", x, y, x + y);
                return x + y;
            }
            @Override
            public double minus() {
                System.out.printf("%f - %f = %f\n", x, y, x - y);
                return x - y;
            }
        };
        return operator.plus();
    }
}

interface Operator {
    double plus();
    double minus();
}

익명 클래스의 제약사항

• 선언한 지점에서만 인스턴스를 만들수 있다.
• Instanced 검사, 클래스 이름이 필요한 검사를 할 수 없다.
• 여러 인터페이스를 구현할 수 없다. 구현과 동시에 다른클래스 상속도 불가능하다.
• 익명 클래스 사용 클라이언트는 사용하는 익명 클래스가 상위타입에서 상속한 멤버외에는 호출이 불가능하다
• 표현식 중간에 등장해 10줄이 넘어가면 가독성이 좋지 않다.

사용 예시

• 람다(자바7) 등장 이전에는 작은 함수 객체나 처리 객체 구현에 사용되었다 : 람다를 쓰자
• 정적 팩터리 메서드를 구현할 때 사용되기 도한다.

5. 지역클래스

• 가장 드물게 사용된다.
• 지역변수를 선언할 수 있는 곳이면 어디서든 선언할 수 있다
• 지역변수와 유효범위가 같다
• 멤버 클래스 유사도 : 이름이 있고 반복해서 사용이 가능하다
• 익명 클래스 유사도 : 비정적 문맥에서 사용할 때만 바깥 인스턴스 참조가 가능하다
• 익명 클래스 유사도 : 정적 멤버는 가질 수 없고, 가독성을 위해 짧게 작성한다.

public class LocalExample {
    private int number;

    public LocalExample(int number) {
        this.number = number;
    }

    public void foo() {
        // 지역변수처럼 선언해서 사용할 수 있다.
        class LocalClass {
            private String name;

            public LocalClass(String name) {
                this.name = name;
            }

            public void print() {
                // 비정적 문맥에선 바깥 인스턴스를 참조 할 수 있다.
                System.out.println(number + name);
            }
        }
        LocalClass localClass = new LocalClass("local");
        localClass.print();
    }
}

1. 태그 달린 클래스

• 쓸데없는 코드가 너무 많다 : 열거 타입선언, 태그 필드, switch문
• 장황하고 오류를 내기 쉽고 비효율적이다.
• 클래스 계층 구조를 어설프레 흉내낸 것이다.

class Figure {
    enum Shape { RECTANGLE, CIRCLE };
    // 태그 필드 - 현재 모양을 나타낸다.
    final Shape shape;

    // 다음 필드들은 모양이 사각형(RECTANGLE)일 때만 쓰인다.
    double length;
    double width;

    // 다음 필드는 모양이 원(CIRCLE)일 때만 쓰인다.
    double radius;

    // 원용 생성자
    Figure(double radius) {
        shape = Shape.CIRCLE;
        this.radius = radius;
    }

    // 사각형용 생성자
    Figure(double length, double width) {
        shape = Shape.RECTANGLE;
        this.length = length;
        this.width = width;
    }

    double area() {
        switch(shape) {
            case RECTANGLE:
                return length * width;
            case CIRCLE:
                return Math.PI * (radius * radius);
            default:
                throw new AssertionError(shape);
        }
    }
}

2. 클래스 계층 구조로의 리팩터링

a. root가 될 추상 클래스를 정의하자

b. 태그에 따라 행동이 달라지던 메서드는 추상 메서드로 구현하자 : 그렇지않으면 일반메서드

c. 공통된 필드는 모두 root 클래스로 올리자

d. 구체 클래스에서 추상클래스를 의미에 맞게 정의하자

abstract class Figure {
    abstract double area();
}

class Rectangle extends Figure {
    final double length;
    final double width;

    Rectangle(double length, double width) {
        this.length = length;
        this.width  = width;
    }
    @Override double area() { return length * width; }
}

class Circle extends Figure {
    final double radius;

    Circle(double radius) { this.radius = radius; }

    @Override double area() { return Math.PI * (radius * radius); }
}

class Square extends Rectangle {
    Square(double side) {
        super(side, side);
    }
}

인터페이스의 용도 : 자신의 인스턴스로 무엇을 할 수 있는지를 클라이언트에 얘기해준다.

상수인터페이스는 만들지 말자

• 외부 인터페이스가아닌 내부구현에 해당하며 클래스의 API로 노출하는 행위이다.

상수를 공개하고 싶을때

• 연관된 클래스나 인터페이스에서 공개 : Integer.MIN_VALUE
• Enum
• 인스턴스화 할수 없는 유틸 클래스

  public final class StringConstants{
    public static final String BRANK = "";
    private StringConstants(){}
  }

생각할 수 있는 상황에서 불변식을 해치지 않는 디폴트 메서드 작성은 어렵다.

• 디폴트 메서드는 구현 클래스에 대해 아무 것도 모른채 합의 없이 무작정 '삽입'될 뿐이다.
• Java8 : 컬렉션 인터페이스 다수에 디폴트 메서드 추가
• 범용적으로 구현되어있지만, 모든 구현체와 어울리는 것은 아니다.

1. SynchronizedCollection

아파치 버전

• 클라이언트가 제공한 객체로 락을 거는 능력을 추가로 제공
• 모든 메서드에서 주어진 락 객체로 동기화한 후 내부 컬렉션 객체에 기능 위임
• removeIf : 재정의 되어있지 않았음 (동기화에 대해 모르는 상태)

2. 인터페이스 설계에 주의하자

a. 디폴트 메서드

• 디폴트 메서드는 (컴파일에 성공하더라도) 기존 구현체에 런타임 오류를 일으킬 수 있다.
• 꼭 필요한 경우가 아니면 디폴트 메서드로 새 메서드를 추가하는 일은 꼭 필요한 경우가 아니면 피하자
• 새로운 인터페이스를 만들때는 아주 유용한 수단이다
• 기존 메서드를 제거하거나 수정하는 용도가 아니다.
• 클라이언트에 영향이 어마어마하게 가기 때문이다.

b. 설계 시 주의

디폴트 메서드가 생겼더라도 인터페이스를 설계할 때는 여전히 세심한 주의를 기울여야한다.

• 인터페이스 설계시 검증을 위해 최소 3가지의 구현체를 만들어보자
• 인터페이스를 릴리즈한 후라도 결함을 수정하는게 가능한 경우도 있지만, 절대 이 가능성에 기대지 말자.