이펙티브 자바 - 4장

JeongJun Min·2024년 10월 12일

JAVA

목록 보기
3/7
post-thumbnail

클래스와 인터페이스

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

자바의 핵심이자 객체 지향의 가장 중요한 특성인 추상화에는 클래스와 인터페이스가 있다. 클래스 내부 데이터와 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼는지에 따라 잘 설계된 컴포넌트인지 구별한다. 이러한 기능을 정보 은닉, 캡슐화라고 한다.

정보 은닉의 장점
1. 시스템 개발 속도를 높인다.
2. 시스템 관리 비용을 낮춘다.
3. 성능 최적화에 도움을 준다.
4. 소프트웨어 재사용성을 높인다.
5. 큰 시스템을 제작하는 난이도를 낮춰준다.

자바는 정보 은닉을 위한 다양한 장치를 제공한다.

접근 제어 메커니즘

  • 접근 제한자 (private, proteched, public)
  • 가능 한 가장 낮은 접근 수준을 부여해야 한다.
    • priavate : 멤버를 선언한 톱레벨 클래스(가장 바깥 쪽 클래스)만 접근 가능
    • package-private(default) : 멤버가 소속된 패키지 안의 모든 클래스에서 접근 가능
    • protected : 이 멤버를 선언한 클래스의 하위 클래스(다른 패키지도)에서도 접근 가능
    • public : 모든 곳에서 접근 가능

🤔 무조건 priavate로 헤야 좋을까?

public 클래스에서 멤버의 접근 수준을 package-private에서 protected로 바꾸는 순간 접근할 수 있는 대상 범위가 엄청나게 넓어진다.

그러나 멤버 접근성을 좁히지 못하게 방해하는 제약이 하나 있다. 바로 상위 클래스의 메서드를 재정의할 때 그 접근 수준을 상위클래스에서보다 좁게 설정 할 수 없다는 것이다.

테스트를 위해 private 멤버를 package-private까지 풀어주는 것은 허용할 수 있지만 그 이상은 안 된다.

public 클래스의 인스턴스 필드는 되도록 public이 아니어야 한다.

final이 아닌 인스턴스 필드를 public으로 선언하면, 그 필드에 담을 수 있는 값을 제한함을 잃는다. (불변식을 보장 할수 x) 또, 필드가 수정될 때 다른 작업을 할 수 없으므로 public 가변 필드를 갖는 클래스는 일반적으로 스레드 안전하지 않다.

정적 필드 또한 마찬가지다. 예외적으로 해당 클래스가 표현하는 추상 개념을 완성하는 데 꼭 필요한 구성요소로써 상수라면 public static final 필드로 공개해도 좋다.

길이가 0이 아닌 배열은 모두 변경 가능하다.

클래스에서 public static final 배열 필드를 두거나 이 필드를 반환하는 접근자 메서드를 제공하면 안 된다. 

public static final Thing[] VALUES = {...};

해당 코드에서 public을 priavate로 바꾸고 public 불변 리스트를 추가해야 한다.

또는 방어적 복사인 복사본을 반환하는 public 메서드를 추가하는 것이 좋다.

모듈 시스템

자바 9에서 추가된 모듈 시스템으로 두 가지 암묵적 접근 수준이 추가되었다.

  • 모듈은 패키지들의 묶음이다.
  • 자신에 속한 패키지 중 공개(export)할 것들을 선언한다.
  • public 혹은 protected 필드여도 해당 패키지를 공개하지 않았다면 모듈 외부에서 접근할 수 없다.

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

class Point {
    public double x;
    public double y;
}

해당 코드에는 여러 가지 문제가 존재한다.

  • API를 수정하지 않고는 내부 표현을 바꿀 수 없다.
  • 불변식을 보장할 수 없다.
  • 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 없다.
class Point{
    private double x;
    private double y;

    public Point(double x, double y){
        this.x = x;
        this.y = y;
    }

    public double getX(){
        return x;
    }
    public double getY(){
        return y;
    }
    public void setX(double x){
        return this.x = x;
    }
    public void setY(double y){
        return this.y = y;
    }
}

패키지 밖에서 접근할 수 있는 클래스라면 접근자를 통해 클래스 내부 표현 방식을 언제든 바꿀 수 있다(유연성).

package-private 클래스, private 중첩 클래스라면 데이터 필드를 노출한다 해도 하등의 문제가 없다.

데이터 필드를 노출해도 그 클래스가 표현하려는 추상 개념만 올바르게 표현한다면 문제가 없다.

접근자 방식보다 더 깔끔하고, 패키지 밖 코드를 신경쓰지 않고 데이터 표현 방식을 바꿀 수 있다.

변경 가능성을 최소화하라

불변 클래스란?

그 인스턴스의 내부 값을 수정할 수 없는 클래스다. 불변 클래스는 가변 클래스보다 설계하고 구현하고 사용하기 쉬우며, 오류가 생길 여지도 적고 훨씬 안전하다.

클래스를 불변으로 만드는 규칙
1. 객체의 상태를 변경하는 메서드를 제공하지 않는다.
2. 클래스를 확장할 수 없도록 한다.
3. 모든 필드를 final로 선언한다.
4. 모든 필드를 private로 선언한다.
5. 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다.

불변 클래스 특징

  • 함수형 프로그래밍을 통해 프로그래밍을 하면 불변이 되는 영역의 비율이 높아지는 장점을 누릴 수 있다,
  • 불변 객체는 생성된 시점의 상태를 파괴될 때 까지 그대로 간직한다. 또한 근본적으로 스레드 안전하여 따로 동기화할 필요 없다.
  • 불변 객체는 자유롭게 공유할 수 있음은 물론, 불변 객체끼리는 내부 데이터를 공유할 수 있다.
  • 불변 객체는 그 자체로 실패 원자성을 제공한다.

불변 클래스에도 단점은 있다. 값이 다르면 반드시 독립된 객체로 만들어야 한다는 것이다.

값의 가짓수가 많다면 모두 만드는 데 큰 비용을 치러야 한다.

가변 동반 클래스

이를 해결 하기위해 다단계 연산들을 예측하여 기본 기능으로 제공하는 방법이다. 각 단계마다 객체를 생성하지 않아도 된다. 대표적인 가변 동반 클래스 예로 String 클래스의 StringBuilder와 StringBuffer가 있다.

불변 클래스를 만드는 또 다른 설계 방법

불변 클래스는 자신을 상속하지 못하게 해야 하므로 final 클래스로 선언하는 것이다. 더 유연한 방법으로 모든 생성자를 private 혹은 package-priavate로 만들고 public 정적 팩터리를 제공하는 방법이 있다.

  • Getter가 있다고 무조건 Setter를 구현하지 말자
  • 클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다.
  • 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이자.
  • 생성자는 불변식 설정이 모두 완료된, 객체를 생성해야 한다.

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

상속은 코드를 재사용하는 강력한 수단이지만, 항상 최선인 것은 아니다.

일반적인 구체 클래스를 패키지 경계를 넘어, 즉 다른 패키지의 구체 클래스를 상속하는 일은 위험하다.

매서드와 달리 상속은 캡슐화를 깨뜨린다

상위 클래스가 어떻게 구현되느냐에 따라 하위 클래스의 동작에 이상이 생길 수 있다. 상위 클래스는 릴리스마다 내부 구현이 달라질 수 있으며, 그 여파로 코드 한 줄 건들이지 않은 하위 클래스가 오동작할 수 있다.

또한 다음 릴리스에서 상위 클래스에 새로운 메서드를 추가할 경우 하위 클래스에서 재정의하지 못한 그 새로운 메서드를 사용해 허용되지 않은 원소를 추가할 수 있게 된다.

위 두 문제를 해결하기 위해 기존 클래스를 확장하는 대신, 새로운 클래스를 만들고 private 필드로 기존 클래스의 인스턴스를 참조하게 하자. 기존 클래스가 새로운 클래스의 구성요소로 쓰인다는 듯에서 이러한 설계를 컴포지션이라 한다.

새 클래스의 인스턴스 메서드들은 기존 클래스의 대응하는 메서드를 호출해 그 결과를 반환한다. 이 방식을 전달(forwarding)이라 한다.

새 클래스의 메서드들을 전달 메서드(forwarding method)라 부른다.

상속은 반드시 하위 클래스가 상위 클래스의 “진짜” 하위 타입인 상황에서만 쓰여야 한다.
컴포지션을 써야 할 상황에서 상속을 사용하는 건 내부 구현을 불필요하게 노출하는 꼴이다.

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

상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지 문서로 남겨야 한다.

메서드가 재정의 가능 메서드라면 그 사실을 호출하는 메서드의 API 설명에 적시해야 한다.

덧붙여서 어떤 순서로 호출하는지 각각의 호출 결과가 이어지는 처리에 어떤 영향을 주는지도 담아야 한다.

API 문서의 메서드 설명 끝에서 종종 ‘Implemenation Requirements’ 로 시작하는 절을 볼 수 있는데, 그 메서드의 내부 동작 방식을 설명하는 곳이다.
@implSpec 태그를 붙여주면 자바독 도구가 생성해준다.

내부 메커니즘을 문서로 남기는 것만이 상속을 위한 설계의 전부는 아니다. 효율적인 하위 클래스를 큰 어려움 없이 만들 수 있게 하려면 클래스의 내부 동작 과정 중간에 끼어들 수 있는 훅(hook)을 잘 선별하여 protected 메서드 형태로 공개해야 할 수도 있다.

상속용 클래스를 설계할 때 어떤 메서드를 protected로 노출해야 할지는 어떻게 결정할까?

안타깝게도 실제 하위 클래스를 만들어 시험해보는 것이 ‘유일’이다. protected 메서드 하나하나가 내부 구현에 해당하므로 그 수는 가능한 한 적어야 한다. 한편으로는 너무 적게 노출해서 상속으로 얻는 이점마저 없애지 않도록 주의해야 한다.

꼭 필요한 protected 멤벌르 놓쳤다면 하위 클래스를 작성할 떄 그 빈자리가 확연히 드러난다.

상속용으로 설계한 클래스는 배포 전에 반드시 하위 클래스를 만들어 검증해야 한다.

상속용 클래스의 생성자는 직접적으로든 간접적으로든 재정의 가능 메서드를 호출해서는 안 된다.

clone과 readObject 메서드는 생성자와 비슷한 효과를 낸다(새로운 객체를 만든다.)

따라서 상속용 클래스에서 Cloneable이나 Serializable을 구현할지 정해야 한다면, 이들은 구현할 때 따르는 제약도 생성자와 비슷하다는 점에 주의하자.

readObject
자바로 구현된 시스템 간에 데이터를 주고 받는 방법으로 자바 직렬화(Serializable)이 있다.
기본적으로 직렬화 또는 역직렬화 과정에서 별도의 처리가 필요할 경우 writeObject와 readObject 메서드를 사용한다.

상속용으로 설계되지 않은 클래스는 상속을 금지해야 한다.

상속을 금지하는 방법중 첫 번째는 final 클래스를 선언하는 방법이다. 두 번째는 모든 생성자를 private나 package-private로 선언하고 public 정적 팩터리를 만들어주는 방법이다.

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

자바가 제공하는 다중 구현 메커니즘은 인터페이스와 추상 클래스, 이렇게 두 가지다. 자바는 단일 상속을 지원하니 , 추상 클래스의 경우 새로운 타입을 정의하는데 커다란 제약을 안게 된다. 반면 인터페이스가 선언한 메서드를 모두 정의하고 그 일반 규약을 잘 지킨 클래스라면 다른 어떤 클래스를 상속했든 같은 타입으로 취급된다.

기존 클래스에도 손쉽게 새로운 인터페이스를 구현해 넣을 수 있다

인터페이스가 요구하는 메서드를 추가하고 , 클래스 선언에 implements 구문만 추가하면 끝이다.

반면 기존 클래스 위에 새로운 추상 클래스를 끼워넣기는 어려운 게 일반적이다 두 클래스가 같은 추상 클래스를 확장하길 원한다면, 그 추상 클래스 계층구조상 두 클래스의 공통 조상이어야 한다.

인터페이스는 믹스인(mixin) 정의에 안성맞춤이다.

믹스인(mixin)

다른 클래스의 부모클래스가 되지 않으면서 다른 클래스에서 사용할 수 있는 메서드를 포함하는 클래스이다.

class Vehicle {
    String name;

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

    public void startEngine() {
        System.out.println("broom broom");
    }

    public void blowHorn() {
        System.out.println("honk!");
    }
}

class MotoCycle extends Vehicle {
    int wheel;

    public MotoCycle(String name) {
        super(name);
        this.wheel = 2;
    }
}

class CycleCar extends Vehicle {
    int wheel;

    public CycleCar(String name) {
        super(name);
        this.wheel = 4;
    }
}

이처럼 이동수단이라는 클래스가 있고, 자동차와 오토바이는 시동과 경적을 상속받아 사용했지만, 여기에 자전거가 추가되면 자전거는 시동을 걸 수 없으므로 startEngine()를 제거하고 각각 자동차와 오토바이에 붙여줘야 한다.

이 때 믹스인을 통해 다른 클래스에 상속되어 쓰일 목적으로만 사용하여 startEngine() 를 믹스인으로 구현할 수 있다.

interface Engine {
    default void startEngine() {
        System.out.println("broom broom");
    }
}

class MotoCycle extends Vehicle implements Engine {
    public MotoCycle(String name) {
        super(name);
    }
}

class CycleCar extends Vehicle implements Engine {
    public CycleCar(String name) {
        super(name);
    }
}

자바는 다중 상속을 지원하지 않아 인터페이스로 정의하여 사용할 수 있다.

출처: https://code-anthropoid.tistory.com/265

인터페이스로는 계층구조가 없는 타입 프레임워크를 만들 수 있다

계층적으로 정의하면 수많은 개념을 구조적으로 잘 표현할 수 있지만, 현살에는 계층을 엄격히 구분하기 어려운 개념도 있다.

ex) 가수 인터페이스, 작곡가 인터페이스

현실에는 작곡도 하는 가수가 제법 있다. 따라서

public interface SingerSongWriter extends Singer, Songwriter{

}

SingerSongWriter라는 인터페이스를 만들어 사용할 수 있다.

이 정도의 유연성이 항상 필요하지는 않지만, 같은 구조를 클래스로 만들려면 가능한 조합 전부를 각각의 클래스로 정의한 거대한 계층구조가 만들어 질 것이다. 이러한 거대한 클래스 계층구조에는 공통 기능을 정의해 놓은 타입이 없으니, 매개변수 타입만 다른 메서드들을 수없이 많이 가진 클래스를 낳을 수 있다.

인터페이스의 메서드 중 구현 방법이 명백한 것이 있다면, 그 구현을 디폴트 메서드로 제공해 프로그래머들의 일감을 덜어줄 수 있다.

Default 메서드
인터페이스에 있는 구현 메서드

public interface Interface {
   // 추상 메서드 
    void abstractMethodA();
    void abstractMethodB();

	// default 메서드
    default int defaultMethodA(){
    	...
    }
}

디폴트 메서드에도 제약은 있다.

  • equals나 hashCode 같은 Object의 메서드를 제공해서는 안 된다.
  • 인스턴스 필드를 가질 수 없다.
  • public이 아닌 정적 멤버도 가질 수 없다.
  • 여러분이 만들지 않은 인터페이스에는 디폴트 메서드를 추가할 수 없다.

인터페이스와 추상 골격 구현 클래스를 함께 제공하는 식으로 인터페이스와 추상 클래스의 장점을 모두 취하는 방법도 있다

인터페이스로 타입을 정의하고, 필요하면 디폴트 메서드 몇 개도 함께 제공한다. 골격 구현 클래스는 나머지 메서드들까지 구현한다. (템플릿 메서드 패턴)

템플릿 메서드 패턴

상위 클래스에서 뼈대 역할에 해당하는 템플릿 메서드를 정의한다. 이후, 템플릿 메서드에 포함된 메서드들의 구체적인 구현은 하위 클래스가 담당하게 된다.

골격 구현 클래스는 추상 클래스처럼 구현을 도와주는 동시에, 추상 클래스로 타입을 정의할 때 따라오는 심각한 제약에서는 자유롭다.

골격 구현 클래스를 우회적으로 이용할 수도 있다. 인터페이스를 구현한 클래스에서 해당 골격 구현을 확장한 private 내부 클래스를 정의하고, 각 메서드 호출을 내부 클래스의 인스턴스에 전달하는 것이다.

골격 구현 작성은 상대적으로 쉽다. 단순 구현은 골격 구현의 작은 변종이다. 단순 구현도 골격 구현과 같이 상속을 위해 인터페이스를 구현한 것이지만, 추상 클래스가 아니란 점이 다르다.

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

자바 8 전에는 기존 구현체를 깨뜨리지 않고는 인터페이스에 메서드를 추가할 방법이 없었다.

자바 8 이후부터 디폴트 메서드를 통해 기존 인터페이스에 메서드를 추가했지만 위험이 완전히 사라진 것은 아니다.

디폴트 메서드는 구현 클래스에 대해 아무것도 모른 채 합의 없이 무작정 사용될 뿐이다.

생각할 수 있는 모든 상황에서 불변식을 해치지 않는 디폴트 메서드를 작성하기란 어려운 법이다.

자바 8의 Collection 인터페이스에 추가된 removeIf 메서드를 예로 Collection 인터페이스를 구현한 SynchronizedCollection 클래스는 동기화를 통해 한 스레드만 동작을 해야 하지만 removeIf의 구현은 동기화에 대한 아무것도 모르므로 락 객체를 사용할 수 없다. 따라서 여러 스레드가 공유하는 환경에서 한 스레드가 removeIf를 호출하면 ConcurrentModificationException이 발생하거나 다른 예기치 못한 결과로 이루어질 수 있다.

또한 디폴트 메서드는 컴파일에 성공하더라도 기존 구현체에 런타임 오류를 일으킬 수 있다.

기존 인터페이스에 디폴트 메서드로 새 메서드를 추가하는 일은 꼭 필요한 경우가 아니면 피해야한다.

디폴트 메서드는 인터페이스로부터 메서드를 제거하거나 기존 메서드의 시그니처를 수정하는 용도가 아님을 명심해야 한다. 이런 형태로 인터페이스를 변경하면 반드시 기존 클라이언트를 망가뜨리게 된다.

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

클래스가 인터페이스를 구현한다는 것은 자신의 인스턴스로 무엇을 할 수 있는지를 클라이언트에 얘기해 주는 것이다. 인터페이스는 오직 이 용도로만 사용해야 한다. 

public interface PhysicalConstants{
      static final double AVOGARDROS_NUMBER = 6.022_140_857e23;
      static final double BOLTZMANN_CONSTANT = 1.380_648_52e-23;
      static final double ELECTRON_MASS = 9.109_383_56e-3;
}

클래스 내부에서 사용하는 상수는 외부 인터페이스가 아니라 내부 구현에 해당한다. 따라서 상수 인터페이스를 구현하는 것은 이 내부 구현을 클래스의 API로 노출하는 행위다.

final이 아닌 클래스가 상수 인터페이스를 구현한다면 모든 하위 클래스의 이름공간이 그 인터페이스가 정의한 상수들로 오염되어 버린다.

상수를 공개할 목적이라면 더 합당한 선택지가 몇 가지 있다. 특정 클래스나 인터페이스와 강하게 연관된 상수라면 그 클래스나 인터페이스 자체에 추가해야 한다. ex) Integer와 Double에 선언된 MIN_VALUE와 MAX_VALUE 상수

열거 타입으로 나타내기 적합한 상수라면 열거 타입으로 만들어 공개하면 된다. 그것도 아니라면 유틸리티 클래스에 담아 공개하자.

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

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

두 가지 이상의 의미로 표현할 수 있으며, 현재 표현하는 의미를 태그 값으로 알려주는 클래스를 본 적이 있을 것이다.

class Figure {
    enum Shape { RECTANGLE, CIRCLE };

    // 태그 필드 
    final Shape shape;

    // shape가 RECTANGLE일때만 사용
    double length;
    double width;

    // shape이 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);
        }
    }
}

태그 달린 클래스에는 단점이 한가득이다. 우선 열거타입, 선언, 태그 필드 switch 문 등 쓸데없는 코드가 많다.

여러 구현이 한 클래스에 혼합돼 있어서 가독성도 나쁘다.메모리도 많이 사용한다.

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

클래스 계층 구조를 활용하는 서브타이핑(subtyping)

abstract class Figure {
    abstract double area();
}

class Circle extends Figure {
    final double radius;

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

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

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; }
}
  1. 계층 구조의 루트가 될 추상 클래스 정의하고, 태그 값에 따라 동작이 달라지는 메서드들은 추상 메서드로 선언한다.
  2. 태그 값에 상관없이 동작이 일정한 메서드들은 일반 메서드로 추가한다.
  3. 모든 하위 클래스에서 공통으로 사용하는 데이터 필드도 전부 루트 클래스로 올린다.
  4. 루트 클래스를 확장한 구체 클래스를 의미별로 정의한다.
  5. 각 하위 클래스에 각자 의미에 해당하는 데이터 필드를 넣는다.
  6. 루트 클래스가 정의한 추상 메서드를 하위 클래스에서 각자 의미에 맞게 구현한다.

클래스 계층구조는 태그 달린 클래스의 단점을 모두 날려버린다. 간결하고 명확하며, 코드에 포함된 쓸데없는 코드도 모두 사라졌다. 자연스러운 계층 관계를 반영할 수 있어서 유연성은 물론 컴파일타임 타입 검사 능력을 높여준다는 장점도 있다.

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

중첩 클래스란 다른 클래스 안에 정의된 클래스를 말한다. 중첩 클래스는 자신을 감싼 바깥 클래스에서만 쓰여야 하며 그 외의 쓰임새가 있다면 톱레벨 클래스로 만들어야 한다.

중첩 클래스의 종류

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

정적 멤버 클래스

다른 클래스 안에 선언되고, 바깥 클래스의 private 멤버에도 접근할 수 있다는 점만 제외하고는 일반 클래스와 똑같다.

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

(비정적) 멤버 클래스

비정적 멤버 클래스의 인스턴스는 바깥 클래스의 인스턴스와 연결되며, 비정적 멤버 클래스의 인스턴스 메서드에서 정규화된 this를 사용해 바깥 인스턴스의 메서드를 호출하거나 참조를 가져올 수 있다.

비정적 멤버 클래스는 어댑터를 정의할 때 자주 쓰인다. 즉, 어떤 클래스의 인스턴스를 감싸 마치 다른 클래스의 인스턴스처럼 보이게 하는 뷰로 사용하는 것이다. 예컨대 Map 인터페이스의 구현체들은 보통 자신의 컬렉션 뷰를 구현할 때 비정적 멤버 클래스를 사용한다.

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

static을 생략하면 바깥 인스턴스로의 숨은 외부 참조를 갖게 된다. 이 참조를 저장하려면 시간과 공간이 소비된다.

더 심각한 문제는 가비지 컬렉션이 바깥 클래스의 인스턴스를 수거하지 못하는 메모리 누수가 생길 수 있다.

익명 클래스

익명클래스는 이름이 없다. 또 바깥 클래스의 멤버도 아니다. 멤버와 달리, 쓰이는 시점에 선언과 동시에 인스턴스가 만들어진다. 오직 비정적인 문맥에서 사용될 때만바깥 클래스의 인스턴스를 참조할 수 있다. 정적 문맥에서라도 상수 변수 이외의 정적 멤버는 가질 수 없다.

선언한 지점에서만 인스턴스를 만들 수 있고, instanceof 검사나 클래스의 이름이 필요한 작업은 수행할 수 없다. 여러 인터페이스를 구현할 수 없고, 인터페이스를 구현하는 동시에 다른 클래스를 상속할 수도 없다. 익명 클래스를 사용하는 클라이언트는 그 익명 클래스가 상위 타입에서 상속한 멤버 외에는 호출할 수 없다.

자바가 람다를 지원하기 전에는 익명 클래스를 주로 사용했지만, 이제는 람다에게 그 자리를 물려줬다.

지역 클래스

네 가지 중첩 클래스 중 가장 드물게 사용된다. 지역 클래스는 지역 변수를 선언할 수 있는 곳이면 실질적으로 어디서든 선언할 수 있고, 유효 범위도 지역변수와 같다. 멤버 클래스 처럼 이름이 있으며, 반복해서 사용할 수 있다.

익명 클래스처럼 비정적 문맥에서 사용될 떄만 바깥 인스턴스를 참조할 수 있으며, 정적 멤버는 가질 수 없고, 가독성을 위해 짧게 작성해야한다.

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

소스 파일 하나에 톱레벨 클래스를 여러 개 선언해도 되지만, 그중 어느 것을 사용할지는 어느 소스파일을 먼저 컴파일하냐에 따라 달라진다.

// Utensil.java
class Utensil {
      static final String NAME = "pan";
}

class Dessert {
        static final String NAME = "cake";
}

// Dessert.java
class Utensil {
      static final String NAME = "pot";
}

class Dessert {
        static final String NAME = "pie";
}

public class Main {
      public static void main(String[] args){
          System.out.println(Utensil.NAME + Dessert.NAME);
    }
}

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

톱레벨 클래스들을 서로 다른 소스 파일로 분리하거나 굳이 여러 톰레벨 클래스를 한 파일에 담고 싶다면 정적 멤버 클래스를 사용하는 방법을 고민해볼 수 있다.

public class Test{
  public static void main(String[] args){
    System.out.println(Utensil.NAME + Dessert.NAME);
  }
  private static class Utensil {
    static final String NAME = "pan";
  }
  private static class Dessert {
    static final String NAME = "cake";
  }
}
profile
JeongJun Min
개발계발
이전 포스트

이펙티브 자바 - 3장

다음 포스트

이펙티브 자바 - 5장

0개의 댓글