Effective Java 맛보기 3탄

클래스와 인터페이스

1. 클래스와 멤버의 접근 권한을 최소화 하라.

   • 프로그램 요소의 접근성은 가능한 한 최소한으로 하라. 꼭 필요한 것만 골라 최소한의 public API를 설계하자. 그 외에는 클래스, 인터페이스, 멤버가 의도치 않게 API로 공개 되는 일이 없도록 해야 한다. public 클래스는 상수용 public static final 필드 외에는 어떠한 public 필드도 가져서는 안된다. public static final 필드가 참조하는 객체가 불변인지 확인하라.

2. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라.

   • public 클래스는 절대 가변 필드를 직접 노출해서는 안된다. 불변 필드라면 노출해도 덜 위험하지만 완전히 안심할 수는 없다. 하지만 package-private 클래스나 private 중첩 클래스에서는 종종(불변이든 가변이든) 필드를 노출하는 편이 나을 때도 있다.

3. 변경 가능성을 최소화하라.

4. 상속보다는 컴포지션을 사용하라.

   • 상속은 강력하지만 캡슐화를 해친다는 문제가 있다. 상속은 상위 클래스와 하위 클래스가 순수한 is -a 관계일 때만 써야 한다. is-a 관계일때도 안심할 수만은 없는게, 하위 클래스의 패키지가 상위 클래스와 다르고, 상위 클래스가 확장을 고려해 설계되지 않았다면 여전히 문제가 될 수 있다. 상속의 취약점을 피하려면 상속 대신 컴포지션과 전달을 사용하자. 특히 래퍼 클래스로 구현할 적당한 인터페이스가 있다면 더욱 그렇다.래퍼 클래스는 하위 클래스보다 견고하고 강력하다.

5. 상속을 고려해 설계하고 문서화 하라. 그러지 않았다면 상속을 금지하라.

   • 상속용 클래스를 설계하기란 결코 만만치 않다 클래스 내부에서 스스로를 어떻게 사용하는지(자기사용 패턴) 모두 문서로 남겨야 하며, 일단 문서화한 것은 그 클래스가 쓰이는 한 반드시 지켜야 한다. 그러지 않으면, 그 내부 구현 방식을 믿고 활용하던 하위 클래스를 오동작하레 만들 수 있다. 다른 이가 효율 좋은 하위 클래스를 만들수 있도록 일부 메서드를 protected로 제공해야 할 수도 있다. 그러나 클래스를 확장해야 할 명확한 이유가 떠오르지 않으면 상속을 금지하는 편이 나을 것이다. 상속을 금지하려면 클래스를 final 로 선언하거나 생성자 모두를 외부에서 접근할 수 없도록 만들면 된다. 

6. 추상 클래스보다는 인터페이스를 우선하라.

   • 일반적으로 다중 구현용 타입으로는 인터페이스가 가장 적합하다. 복잡한 인터페이스라면 구현하는 수고를 덜어주는 골격 구현을 함께 제공하는 방법을 꼭 고려해보자. 골격 구현은 '가능한 한' 인터페이스의 디폴드 메서드로 제공하여 그 인터페이스를 구현한 모든 곳에서 활용하도록 하는 것이 좋다. '가능한 한' 이라고 한 이유는, 인터페이스에 걸려 있는 구현상의 제약 때문에 골격 구현을 추상 클래스로 제공하는 경우가 더 흔하기 때문이다.

7.  인터페이스는 구현하느 쪽을 생각해 설계하라.

8. 인터페이스는 타입을 정의하는 용도로만 사용하라.

   • 인터페이스는 타입을 저의하는 용도로만 사용해야 한다. 상수 공개용 수단으로 사용하지 말자.

9. 태그 달린 클래스보다는 클래스 계층구조를 활용하라.

   • 태그 달린 클래스를 써야 하는 상황은 거의 없다. 새로운 클래스를 작성하는데 태그 필드가 등장한다면 태그를 없애고 게층구조로 대처하는 방법을 생각해 보자. 기존 클래스가 태그 필드를 사용하고 있다면 계층구조로 리팩터링하는 걸 고민해 보자.

10. 멤버 클래스는 되도록 static 으로 만들라.

    • 중첩 클래스에는 네가지가 있으며, 각각의 쓰임이 다르다. 메서드 밖에서도 사용해야 하거나 메서드 안에 정의하기엔 너무 길다면 멤버 클래스로 만든다. 멤버 클래스의 인스턴스 각각이 바깥 인스턴스를 참조한다면 비정적으로, 그렇지 않다면 정적으로 만들자. 중첩 클래스가 한 메서드 안에서만 쓰이면서 그 인스턴스를 생성하는 지점이 단 한 곳이고 해당 타입으로 쓰기에 적합한 클래스나 인터페이스가 이미 있다면 익명 클래스로 만들고, 그렇지 않으면 지역 클래스로 만들자.

11. 톱레벨 클래스는 한 파일에 하나만 담아라.

    • 교훈은 명확하다. 소스 파일 하나에는 반드시 톱레벨 클래스(혹은 톱레벨 인터페이스)를 하나만 담자. 이 규칙만 따른다면 컴파일러가 한 클래스에 대한 정의를 여러 개 만들어 내는 일은 사라진다. 소스 파일을 어떤 순서로 컴파일하든 바이너리 파일이나 프로그램의 동작이 달라지는 일은 결코 일어나지 않을 것이다.

4대 중첩클래스

내부클래스 (Inner Class)
정적 중첩 클래스 (Static Nested Class)
지역 클래스(Method Local Inner Class)
익명 클래스(Anonymous Inner Class)

클래스 상속 : is-a 관계
인터페이스 구현 : can-do 관계
컴포지션 : has-a 관계

참조서적 및 페이지 : 

이펙티브 자바 Effective Java 3/E (http://www.yes24.com/Product/Goods/65551284)

https://scarlett.tistory.com/entry/자바공부-1-콤포지션-Composition

https://ryulib.tistory.com/316