[Effective Java 3/E] 4장 클래스와 인터페이스

📋 목차.

4. 클래스와 인터페이스
    .아이템 15 - 클래스와 멤버의 접근 권한을 최소화하라.
    .아이템 16 - public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라
    .아이템 17 - 변경 가능성을 최소화하라
    .아이템 17 - 변경 가능성을 최소화하라
    .아이템 18 - 상속보다는 컴포지션을 사용하라
    .아이템 19 - 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라
    .아이템 20 - 추상 클래스보다는 인터페이스를 우선하라
    .아이템 21 - 인터페이스는 구현하는 쪽을 생각해 설계하라
    .아이템 22 - 인터페이스는 타입을 정의하는 용도로만 사용하라
    .아이템 23 - 태그 달린 클래스보다는 클래스 계층구조를 활용하라
    .아이템 24 - 멤버 클래스는 되도록 static으로 만들라
    .아이템 25 - 톱레벨 클래스는 한 파일에 하나만 담으라.

---

✔️ 내용.

 

4. 클래스와 인터페이스

 

 추상화의 기본 단위인 클래스와 인터페이스는 자바 언어의 심장과도 같다. 클래스와 인터페이스를 쓰기 편하고, 견고하며, 유연하게 만드는 방법을 안내한다.

---

.아이템 15 - 클래스와 멤버의 접근 권한을 최소화하라.

 

 어설프게 설게된 컴포넌트와 잘 설계된 컴포넌트의 가장 큰 차이는 바로 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼느냐다. 잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다.

오직 API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작 방식에는 전혀 개의치 않는다. 정보 은닉, 혹은 캡슐화라고 하는 이 개념은 소프트웨어 설계의 근간이 되는 원리다.

 

 정보 은닉의 장점

 - 시스템 개발 속도 향상. 
여러 컴포넌트를 병렬로 개발할 수 있기 때문

 - 시스템 관리 비용을 낮춤
각 컴포넌트를 더 빨리 파악하여 디버깅할 수 있고, 다른 컴포넌트로 교체하는 부담도 적기 때문

 - 정보 은닉 자체가 성능을 향상해 주지는 않지만, 최적화에는 도움을 준다.
 완성된 시스템을 프로파일링해 최적화할 컴포넌트를 정한 다음(아이템 67), 다른 컴포넌트에 영향을 주지 안혹 해당 컴포넌트만 최적화할 수 있기 때문

 - 소프트웨어 재사용성을 높인다.
외부에 의존하지 안호 독자적으로 동작할 수 있는 컴포넌트라면 그 컴포넌트와 함께 개발되지 않은 낯선 환경에서도 유용하게 쓰일 가능성이 크다.

 - 큰 시스템을 제작하는 난이도를 낮춰준다.
시스템 전체가 아직 완성되지 않은 상태에서도 개별 컴포넌트의 동작을 검증할 수 있기 때문이다.

 

 자바는 정보 은닉을 위한 다양한 장치를 제공한다. 그중 접근 제어 메커니즘은 클래스, 인터페이스, 멤버의 접근성을 명시한다.

 

 기본 원칙은 간단하다. 모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 한다. 즉, 소프트웨어가 올바로 동작하는 한 항상 가장 낮은 접근 수준을 부여해야 한다.

 

 Top 레벨(가장 바깥) 클래스와 인터페이스에 부여할 수 있는 접근 수준은 package-private와 public 두 가지이다. 외부에서 쓸이유가 없다면 package-private으로 선언하자. 그러면 이들은 API가 아닌 내부 구현이 되어 언제든 수정할 수 있다. 즉, 클라이언트에 아무런 피해 없이 다음 릴리스에서 수정, 교체, 제거할 수 있다. 반면, public으로 선언한다면 API가 되므로 하위 호환을 위해 영원히 관리해야 한다.

 

한 클래스에서만 사용하는 package-private Top레벨 클래스나 인터페이스는 이를 사용하는 클래스 안에 private static으로 중첩시켜보자(아이템 24), Top 레벨로 두면 같은 패키지의 모든 클래스가 접근할 수 있지만, private static으로 중첩시키면 바깥 클래스 하나에서만 접근할 수 있다. 

 

 클래스의 공개 APi를 세심히 설계한 후, 그 외의 모든 멤버는 private로 만들자. 그런 다음 오직 같은 패키지의 다른 클래스가 접근해야 하는 멤버에 한해 package-private으로 풀어주자. 권한을 풀어주는 일을 자주 하게 된다면 여러분 시스템에서 컴포넌트를 더 분해해야 하는 것은 아닌지 다시 고민해 보자. prviate와 package-private 멤버는 모두 해당 클래스의 구현에 해당하므로 보통은 공개 APi에 영향을 주지 않는다. 단, Serializable을 구현한 클래스에서는 private 같은 필드들도 의도치 않게 공개 API가 될 수도 있다.(아이템 86,87)

 

 public 클래스에서는 멤버의 접근 수준을 package-private에서 protected로 바꾸는 순간 그 멤버에 접근할 수 있는 대상 범위가 엄청 넓어진다. public 클래스의 protected 멤버는 공개 API로 영원히 지원돼야 한다. 또한 내부 동작 방식을 API 문서에 적어 사용자에게 공개해야 할 수도 있다.(아이템 19) 따라서 protected 멤버의 수는 적을수록 좋다.

 

 상위클래스의 메서드를 재정의할 때는 그 접근 수준을 상위 클래스에서보다 좁게 설정할 수 없다. 이 제약은 상위 클래스의 인스턴스는 하위 클래스의 인스턴스로 대체해 사용할 수 있어야 한다는 리스코프 치환 원칙을 지키기 위해 필요하다.

 

 단지 코드를 테스트하려는 목적으로 클래스, 인터페이스, 멤버의 접근 범위를 넓히려 할 때가 있다. 적당한 수준까지는 넓혀도 괜찮다. 예로, public 클래스의 private 멤버를 package-private까지 풀어주는 것은 허용할 수 있지만, 그 이상은 안 된다. 즉, 테스트만을 위해 클래스 인터페이스, 멤버를 공개 API로 만들어서는 안 된다. 다행히 이렇게 해야 할 이유도 없다. 테스트 코드를 테스트 대상과 같은 패키지에 두면 package-private 요소에 접근할 수 있기 때문이다.

 

 public 클래스의 인스턴스 필드는 되도록 public이 아니어야 한다(아이템 16) public 가변 필드를 갖는 클래스는 일반적으로 스레드 세이프 하지 않다.

 

 final을 사용한다 하더라도 배열 필드를 두거나 이 필드를 반환하는 접근자 메서드를 제공해서는 안된다. 접근자를 제공하면 내용을 수정할 수 있게 된다.

public static final Thing[] VALUES = {new Thing(), new Thing()};

 

해결책은 두 가지다.

 첫 번째 방법은 public배열을 private로 만들고 public 불변 list를 추가한다.

 

public static final List<Thing> VALUES_LIST = Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES));

 

 두 번째는 배열을 private로 만들고 복사본을 반환하는 public 메서드를 추가하는 방법이다(방어적 복사)

    public static final Thing[] values(){
        return PRIVATE_VALUES.clone();
    }

 

핵심 정리

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

---

 

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

 

 패키지 바깥에서 접근할 수 있는 클래스라면 접근자를 제공한다.

 

public class Point {

    private double x; // 접근자와 변경자 메서드를 활용해 데이터를 캡슐화한다., public 클래스는 절대 가변 필드를 직접 노출해서는 안된다.
    private double y; // public X

    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){
        this.x = x;
    }
    public void setY(double y){
        this.y = y;
    }
}

 

 하지만 package-private 클래스 혹은 private 중첩 클래스라면 데이터 필드를 노출해도 하등 문제가 없다. 클래스가 표현하려는 추상 개념만 올바르게 표현해 주면 된다.  이 방식은 클래스 선언 면에서나 이를 사용하는 클라이언트 코듬 면에서나 접근자 방식보다 훨씬 깔끔하다.

 

// package-private class
class PackagePrivateClass {
    // 이 필드는 같은 패키지 내에서 직접 접근 가능
    public String packagePrivateField;
}

public class MainClass {
    // private nested class
    private static class PrivateNestedClass {
        // 이 필드는 MainClass 내에서 직접 접근 가능
        public String privateNestedField;
    }

    public static void main(String[] args) {
        PackagePrivateClass obj1 = new PackagePrivateClass();
        obj1.packagePrivateField = "Hello, package-private!";  // 같은 패키지 내에서 직접 접근 가능

        PrivateNestedClass obj2 = new PrivateNestedClass();
        obj2.privateNestedField = "Hello, private nested!";  // MainClass 내에서 직접 접근 가능

        System.out.println(obj1.packagePrivateField);
        System.out.println(obj2.privateNestedField);
    }
}

 

 public 클래스의 필드가 불변이라면 직접 노출할 때의 단점이 조금은 줄어들지만, 결코 좋은 생각이 아니다. API를 변경하지 않고는 표현 방식을 바꿀 수 없고, 필드를 읽을 때 부수 작업을 수행할 수 없다는 단점은 여전하다. 단, 불변식은 보장할 수 있게 된다. 다음 Time 클래스는 각 인스턴스가 유효한 시간을 표현함을 보장한다.

 

public class Time {
    
    private static final int HOURS_PER_DAY = 24;
    private static final int MINUTES_PER_HOUR = 60;

    public final int hour;
    public final int minute;

    public Time(int hour, int minute){
        if(hour < 0 || hour >= HOURS_PER_DAY)
            throw new IllegalArgumentException("시간: " + hour);
        if(minute < 0 || minute >= MINUTES_PER_HOUR)
            throw new IllegalArgumentException("분: " + minute);
        this.hour = hour;
        this.minute = minute;
    }
}

 

핵심 정리

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

 

---

 

.아이템 17 - 변경 가능성을 최소화하라

 

 불변 클래스란 간단히 말해 그 인스턴스의 내부 값을 수정할 수 없는 클래스로 예로 BigInteger, BigDecimal 등이 있다.

클래스를 불변으로 만들려면 다음 다섯 가지 규칙을 따르면 된다.

 

1. 객체의 상태를 변경하는 메서드(변경자)를 제공하지 않는다.

 

2. 클래스를 확장할 수 없도록 한다.

 

 - 하위 클래스에서 부주의하게 혹은 나쁜 의도로 객체의 상태를 변하게 만드는 사태를 막아준다. 상속을 막는 대표적인 방법은 클래스를 final로 선언하는 것이지만, 그 외 방법도 곧 나온다.

 

3. 모든 필드를 final로 선언한다. 

 

 - 시스템이 강제하는 수단을 이용해 설계자의 의도를 명확히 드러내는 방법이다. 새로 생성된 인스턴스를 동기화 없이 다른 스레드로 건네도 문제없이 동작하게끔 보장하는 데도 필요하다

 

4. 모든 필드를 private으로 선언한다. 

 

 - 필드가 참조하는 가변 객체를 클라이언트에서 직접 전근해 수정하는 일을 막아준다. 기술적으로는 기본 타입 필드나 불변 객체를 참조하는 필드를 public final로만 선언해도 불변 객체가 되지만, 이렇게 하면 다음 릴리스에서 내부 표현을 바꾸지 못하므로 권하지는 않는다. 

 

5. 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다.

 

 - 클래스에서 가변 객체를 참조하는 필드가 하나라도 있다면 클라이언트에서 그 객체의 참조를 얻을 수 없게 해야 한다. 생성자, 접근자, readObject 메서드(아이템 88) 모두에서 방어적 복사를 수행하라.

 

public final class Complex {
    
    private final double re;
    private final double im;
    
    public Complex(double re, double im){
        this.re = re;
        this.im = im;
    }
    
    public double realPart(){
        return re;
    }
    
    public double imaginaryPart(){
        return im;
    }
    
    public Complex plus(Complex c){
        return new Complex(re + c.re, im + c.im);
    }
    
    public Complex minus(Complex c){
        return new Complex(re - c.re, im - c.im);
    }
    
    public Complex times(Complex c){
        return new Complex(re * c.re - im * c.im, re * c.im + im * c.re);
    }
    
    public Complex dividedBy(Complex c){
        double tmp = c.re * c.re + c.im * c.im;
        return new Complex((re * c.re + im * c.im) / tmp, (im * c.re - re * c.im) / tmp);
    }
    
    @Override
    public boolean equals(Object o){
        if(o == this)
            return true;
        if(!(o instanceof Complex))
            return false;
        Complex c = (Complex) o;
        
        return Double.compare(re, c.re) == 0 && Double.compare(im, c.im) == 0;
    }
    
    @Override
    public int hashCode(){
        int result = 17 + hashDouble(re);
        result = 31 * result + hashDouble(im);
        return result;
    }
    
    private int hashDouble(double val){
        long longBits = Double.doubleToLongBits(re);
        return (int) (longBits ^ (longBits >>> 32));
    }    
}

 

 위의 예제는 피연산자에 함수를 적용해 결과를 반환하지만, 피연산자 자체는 그대로는 함수형 프로그래밍 패턴을 사용했다. 이 방식으로 프로그래밍하면 코드에서 불변의 영역 비율이 높아져 장점을 누릴 수 있다. 불변 객체는 생성된 시점의 상태를 파괴될 때까지 그대로 간직한다. 모든 생성자가 클래스 불변을 보장한다면 그 클래스를 사용하는 자가 가변 객체의 변화에 의한 복잡성을 생각하지 않아도 된다.

 

 또한 불변객체는 근본적으로 스레드 안전하여 따로 동기화할 필요 없다. 즉, 불변 객체는 안심하고 공유할 수 있다.

추가로 불변 클래스의 자주 사용되는 정적 팩터리(아이템 1)를 제공하게 되면 여러 클라이언트가 인스턴스를 공유하여 메모리 사용량과 GC 비용이 줄어든다. 새로운 클래스를 설계할 때 public 생성자 대신 정적 팩토리를 만들어두면, 클라이언트를 수정하지 않고도 필요에 따라 캐시 기능을 나중에 덧 붙일 수 있다.

 

 불변 객체는 그 자체로 실패 원자성을 제공한다(아이템 76).  상태가 절대 변하지 않으니 잠깐이라도 불일치 상태에 빠질 가능성이 없다.

 

 불변 객체는 자유롭게 공유할 수 있음은 물론, 불변 객체끼리는 내부 데이터를 공유할 수 있다. 예로 BigInteger 클래스는 내부 값의 부호(sign)와 크기(magnitude)를 따로 표현한다. 부호를 int 변수, 크기(절댓값)는 int 배열을 사용한다. 한편 negate 메서드는 크기가 같고 부호만 반대인 새로운 BigInteger를 생성하는데, 이때 배열은 비록 가변이지만 복사하지 않고 원본 인스턴스와 공유해도 된다. 그 결과 새로 만든 BigInteger 인스턴스도 원본 인스턴스가 가리키는 내부 배열을 그대로 가리킨다.

 

public class BigInteger extends Number implements Comparable<BigInteger> {
    final int signum;
    final int[] mag;
    ...
}

negate()

    public BigInteger negate() {
        return new BigInteger(this.mag, -this.signum);
    }

 

 불변 클래스에도 단점이 있다. 값이 다르면 반드시 독립된 객체로 만들어야 한다는 것이다. 값의 가짓수가 많다면 이들을 모두 만드는 데 큰 비용을 치러야 한다.

 예로 백만 비트짜리 BigIntger에서 비트 하나를 바꿔야 한다고 하면. 

BigIntger moby = ...;
moby = moby.flipBit(0);

 flipBit 메서드는 새로운 BigIntger 인스턴스를 생성한다. 원본가 단지 한 비트만 다른 백만 비트짜리 인스턴스를 말이다.

이로 인해 성능 문제가 불거진다.

    public BigInteger flipBit(int n) {
        if (n < 0) {
            throw new ArithmeticException("Negative bit address");
        } else {
            int intNum = n >>> 5;
            int[] result = new int[Math.max(this.intLength(), intNum + 2)];

            for(int i = 0; i < result.length; ++i) {
                result[result.length - i - 1] = this.getInt(i);
            }

            result[result.length - intNum - 1] ^= 1 << (n & 31);
            return valueOf(result);
        }
    }

 

 이를 해결하는 방법으로 두 가지가 있는데 첫 번째는 다단계 연산(multistep operation)들을 예측하여 기본기능으로 제공하는 방법이다. 예로 BigInteger는 모듈러 지수 같은 다단계 연산 속도를 높여주는 가변 동반 클래스(companion class)를 package-private으로 두고 있다. 

 클라이언트의 복잡한 연산들을 정확히 예측할 수 있다면 package-private의 가변 동반 클래스만으로 충분하다.

대표적인 예 String 클래스의 가변 동반 클래스는 StringBuilder이다.

 

 

 자신을 상속받지 못하는 다음 방법으로는 생성자를 private 혹은 package-private으로 두고 모든 생성자를 정적 팩토리를 제공하는 방법이다.

public final class Complex {

    private final double re;
    private final double im;

    private Complex(double re, double im){
        this.re = re;
        this.im = im;
    }
    public static Complex valueOf(double re, double im){
        return new Complex(re, im);
    }

 

직렬화 주의사항

Serializable을 구현하는 불변 클래스의 내부에 가변 객체를 참조하는 필드가 있다면 readObject나 readResolve 메서드를 반드시 제공하거나, ObjectOutputStream.writeUnshared와 ObjectInputStrea.readUnshared 메서들를 사용해야 한다. 플랫폼이 제공하는 기본 직렬화 방법이면 충분하더라도 말이다. 그렇지 않으면 공격자가 이 클래스로부터 가변 인스턴스를 만들어 낼 수 있다.(아이템 88)

 

 클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다. 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이자. 다른 합당한 이유가 없다면 모든 필드는 private final이어야 한다. 객체가 가질 수 있는 상태의 수를 줄이면 그 객체를 예측하기 쉬워지고 오류가 생길 가능성이 줄어들기 때문이다.

---

 

.아이템 18 - 상속보다는 컴포지션을 사용하라

 

상속은 코드를 재사용하는 강력한 수단이지만, 항상 최선은 아니다. 메서드 호출과 달리 상속은 캡슐화를 깨뜨린다. 상위 클래스가 어떻게 구현되느냐에 따라 하위 클래스의 동작에 이상이 생길 수 있다. 상위 클래스는 릴리스마다 내부 구현이 달라질 수 있으며, 그 여파로 코드 한 줄 건드리지 않은 하위 클래스가 오동작할 수 있다.

 

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

 

public class InstrumentedSet<E> extends ForwardingSet<E> {

    private int addCount = 0;

    public InstrumentedSet(Set<E> s) {
        super(s);
    }

    @Override
    public boolean add(E e) {
        addCount++;
        return super.add(e);
    }

    @Override
    public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return super.addAll(c);
    }

    public int getAddCount() {
        return addCount;
    }
}

// 전달 클래스
public class ForwardingSet<E> implements Set<E> {

    private final Set<E> set;

    public ForwardingSet(Set<E> set){
        this.set = set;
    }
    
    @Override
    public int size() {
        return set.size();
    }

    @Override
    public boolean isEmpty(){
        return set.isEmpty();
    }
    ...
}

 

 다른 Set 인스턴스를 감싸고 있다는 뜻에서 InstrumentedSet 같은 클래스를 래퍼 클래스라 하며, 다른 Set에 계측 기능을 덧씌운다는 뜻에서 데코레이터 패턴이라고 부른다. 컴포지션과 전달의 조합은 넓은 의미로 위임이라고 부른다. 단, 엄밀히 따지면 래퍼 객체가 내부 객체에 자기 자신의 참조를 넘기는 경우만 위임에 해당한다.

 래퍼 클래스는 단점이 거의 없다. 한 가지, 래퍼 클래스가 콜백 프레임워크와는 어울리지 않는다는 점만 주의하면 된다. 콜백 프레임 워크에서는 자기 자신의 참조를 다른 객체에 넘겨서 다음 호출 때 사용하도록 한다. 내부 객체는 자신을 감싸고 있는 래퍼의 존재를 모르니 대신 자신(this)의 참조를 넘기고 콜백 때는 래퍼가 아닌 내부 객체를 호출하게 된다. 이를 Self 문제라고 한다.

 

 상속은 반드시 하위 클래스가 상위 클래스의 '진짜' 하위 타입인 상황에서만 사용해야 한다. 클래스 B가 클래스 A와 is-a 관계일 때만 클래스 A를 상속해야 한다. 클래스 A를 상속하는 클래스 B를 작성하려 한다면 'B가 정말 A인가?'라고 자문해 보자. 대답이 아니라면 A를 private 인스턴스로 두고, A와는 다른 API를 제공해야 하는 상황이 대다수다.

 

핵심 정리

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

---

 

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

 

 

 상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지(자기 사용) 문서로 남겨야 한다.  API 설명, 어떤 순서로 호출하는지, 각각의 호출 결과가 이어지는 처리에 어떤 영향을 주는지 담아야 한다.('재정의 가능'이란 public과 protected 메서드 중 final이 아닌 모든 메서드를 뜻한다).  더 넓게 말하면, 재정의 가능 메서드를 호출할 수 있는 모든 상황을 문서로 남겨야 한다.

 API 문서 중 메서드 설명 끝에서 종종 "Implementation Requirements"로 시작하는 절은 메서드 내부 동작 방식을 설명하는 곳이다.

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

 

 상속용 클래스를 시험하는 방법은 직접 하위 클래스를 만들어보는 것이 유일하며 반드시 만들어서 검증해봐야 한다.

상속용 클래스의 생성자는 직접적이든 간접적이든 재정의 가능 메서드를 호출해서는 안된다. 상위 클래스의 생성자가 하위 클래스의 생성자보다 먼저 실행되므로 재정의 한 메서드가 하위 클래스의 생성자보다 먼저 호출된다. 이때 재정의한 메서드가 하위 클래스의 생성자에서 초기화하는 값에 의존한다면 의도대로 동작하지 않을 것이다.

 

public class Super {

    // 잘못된 예 - 생성자가 재정의 가능 메서드를 호출한다.
    public Super() {
        overrideMe();
    }

    public void overrideMe() {
    }
}

public class Sub extends Super {

    // 초기화되지 않은 final 필드. 생성자에서 초기화한다.
    private final Instant instant;

    public Sub() {
        instant = Instant.now();
    }

    // 재정의 가능 메서드. 상위 클래스의 생성자가 호출한다.
    @Override
    public void overrideMe() {
        System.out.println("instant = " + instant);
    }

    public static void main(String[] args) {
        Sub sub = new Sub();
        // 상위 클래스 생성이 먼저 진행 되기 때문에 instant는 null이다.
        sub.overrideMe();
    }
}

// 실제 출력 값

instant = null
instant = 2023-05-16T12:20:54.766884300Z

 

 Cloneable과 Serializable 인터페이스는 상속용 설계의 어려움을 한층 더해준다. clone과 readObject 모두 직접적이든 간접적으로든 재정의 가능 메서드를 호출해서는 안된다.. readObject의 경우 하위 클래스의 상태가 미처 다 역직렬화되기 전에 재정의한 메서드부터 호출하게 된다. clone의 경우 하위 클래스의 clone 메서드가 복제본의 상태를 수정하기 전에 재정의한 메서드를 호출한다. 어느 쪽이든 프로그램 오작동으로 이어질 것이다.

 

 이러한 문제들을 해결하는 가장 좋은 방법은 상속용으로 설계하지 않은 클래스는 상속을 금지하는 것이다.

금지하는 방법은 두 가지이다. 쉬운 방법 한 가지는 클래스를 final로 선언하는 방법이다. 두 번째는 모든 생성자를 private이나. package-private으로 선언하고 public 정적 팩토리를 만들어주는 방법이다.

 

핵심 정리

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

---

.아이템 20 - 추상 클래스보다는 인터페이스를 우선하라

 

 인터페이스는 믹스인(mixin) 정의에 안성맞춤이다. 믹스인이랑 클래스가 구현할 수 있는 타입으로, 믹스인을 구현한 클래스에 원래의 '주된 타입' 외에도 특정 선택적 행위를 제공한다고 선언하는 효과를 준다. 예로 Comparable은 자신을 구현한 클래스의 인스턴스들끼리는 순서를 정할 수 있다고 선언하는 믹스인 인터페이스이다. 추상 클래스로는 믹스인을 정의할 수 없다. 기존 클래스에 덧씌울 수 없기 때문이다. 클래스는 두 부모를 섬길 수 없고, 클래스 계층구조에는 믹스인을 삽입하기에 합리적인 위치가 없기 때문이다.

 

 인터페이스는 기능을 향상하는 안전하고 강력한 수단이 된다.

 

 인터페이스와 추상 골격 구현 클래스를 함께 제공하는 식으로 인터페이스와 추상 클래스의 장점을 모두 취하는 방법도 있다. 인터페이스로 타입을 정의하고 골격 구현 클래스는 메서드를 구현한다. 단순히 골격 구현을 확장하는 것만으로 이 인터페이스를 구현하는데 필요한 일이 대부분 완료된다. 바로 템플릿 메서드 패턴이다.

 관례로 인터페이스 이름이 interface라면 그 골격 구현 클래스의 이름은 AbstractInterface로 짓는다. 예로 컬렉션 프레임워크의 AbstradctCollection, AbstractSet 등이 핵심 컬렉션 인터페이스의 골격 구현이다.

public abstract class AbstractMap<K, V> implements Map<K, V> {
    transient Set<K> keySet;
    transient Collection<V> values;

    protected AbstractMap() {
    }
    ...

 단순 구현은 골격 구현의 작은 변종으로 AbstractMap.SimpleEntiry가 좋은 예따. 단순 구현도 골격 구현과 같이 상속을 위해 인터페이스를 구현한 것이지만, 추상 클래스가 아니란 점이 다르다. 쉽게 말해 동작하는 가장 단순한 구현이다. 필요에 따라 그대로 사용가능하고 확장도 가능하다.

public static class SimpleEntry<K, V> implements Map.Entry<K, V>, Serializable {
        private static final long serialVersionUID = -8499721149061103585L;
        private final K key;
        private V value;
        ...

 

핵심 정리

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

---

 

.아이템 21 - 인터페이스는 구현하는 쪽을 생각해 설계하라

 

 자바 8 이전에는 기존 구현체를 깨뜨리지 않고 인터페이스에 메서드를 추가할 방법이 없었지만 디폴트 메서드로 인해 추가가 가능해졌다. 하지만 기존 구현체들과 매끄럽게 연동되리라는 보장은 없다. 자바 7 까지는 모든 클래스가 '현재의 인터페이스에 새로운 메서드가 추가될 일은 영원히 없다'라고 가정하고 작성됐기 때문이다.

 

 자바 8 핵심 컬렉션 인터페이스들에 다수의 디폴트 메서드가 추가되었는데. 주로 람다(7장)를 활용하기 위해서다. 디폴트 메서드는 코드 품질이 높고 범용적이라 대부분 상황에서 잘 작동한다. 하지만 생각할 수 있는 모든 상황에서 불변식을 해치지 않는 디폴트 메서드를 작성하기는 어렵다.

 

 - 자바 8에서 추가된 Collection 인터페이스의 removeIf 디폴트 메서드

    default boolean removeIf(Predicate<? super E> filter) {
        Objects.requireNonNull(filter);
        boolean removed = false;
        Iterator<E> each = this.iterator();

        while(each.hasNext()) {
            if (filter.test(each.next())) {
                each.remove();
                removed = true;
            }
        }

        return removed;
    }

 

 위와 같은 디폴트 메서드가 모두 어울려지는 것은 아니다 예로 SynchronizedCollection으로 동기화 과정에서 문제가 발생가능하다. 위의 removeIf는 동기화의 lock과 관련된 사항은 일체 모르므로 예기치 못한 결과를 발생할 수 있다.

 

  따라서, 기존 인터페이스에 디폴트 메서드로 새 메서드를 추가하는 일은 꼭 필요한 경우가 아니라면 피하자. 하지만 새로운 인터페이스를 만드는 경우라면 디폴트 메서드는 아주 유용한 수단이다.

---

 

.아이템 22 - 인터페이스는 타입을 정의하는 용도로만 사용하라

 

  인터페이스는 자신을 구현한 클래스의 인스턴스를 참조할 수 있는 타입 역할을 한다. 오직 이용도로 사용해야 한다. 이 지침에 맞지 않은 예로 상수 인터페이스가 존재한다. 상수를 뜻하는 static final 필드로만 가득 차나 인터페이스이다. 

 

 - 상수 인터페이스 안티패턴 (인터페이스의 잘못 사용한 예)

public interface PhysicalConstants {

    // 아보가드로 수 (1/몰)
    static final double AVOGADROS_NUMBER = 6.022_140_857e23;

    // 볼츠만 상수 (J/K)
    static final double BOLTZMANN_CONSTANT = 1.380_648_52e-23;

    // 전자 질량 (kg)
    static final double ELECTRON_MASS = 9.109_383_56e-31;
}

- 내부 구현을 클래스의 API 노출 -> 사용자에게 혼란

- 클라이언트 코드가 내부 구현에 해당하는 위의 상수들에게 종속될 위험

 

 위와 같이 상수를 공개할 목적이라면 사용 클래스나 인터페이스 자체에 추가하거나, 열거 타입으로 공개하거나(아이템 34) 이도 아니라면 인스턴스화할 수 없는 유틸리티 클래스(아이템 4)에 담아 공개하자.

 

 - 유틸리티 클래스 버전

public class PhysicalConstantUtils {
    private PhysicalConstantUtils() {} // 인스턴스화 방지

    // 아보가드로 수 (1/몰)
    public static final double AVOGADROS_NUMBER = 6.022_140_857e23;

    // 볼츠만 상수 (J/K)
    public static final double BOLTZMANN_CONSTANT = 1.380_648_52e-23;

    // 전자 질량 (kg)
    public static final double ELECTRON_MASS = 9.109_383_56e-31;
}

 

핵심 정리

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

---

 

.아이템 23 - 태그 달린 클래스보다는 클래스 계층구조를 활용하라

 

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

 

- 원과 사각형을 표현할 수 있는 클래스

 

// 태그 달린 클래스 - 클래스 계층구조보다 훨씬 나쁘다!
public 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);
        }
    }
}

 

단점 

 - 열거 타입 선언, 태그 필드, switch 문 등 쓸데없는 코드가 많다.

 - 여러 구현이 한 클래스에 혼합돼 있어서 가독성이 나쁘다.

 - 다른 의미를 위한 코드도 언제나 함께 하기 때문에 메모리도 많이 사용한다.

 - 필드들을 final 선언하기 위해서는 해당 의미에 쓰이지 않는 필드들까지 생성자에서 초기화해야 한다. - 불필요한 코드 생성

 - 또 다른 의미 추가를 위해 코드가 수정되어야 한다.

 

즉, 태그 달린 클래스는 장황하고, 오류를 내기 쉽고, 비효율 적이다. 클래스 계층 구조를 어설프게 흉내 냈을 뿐이다.

 

클래스 계층 구조로 변환 과정

1. 계층 구조의 루트(root)가 될 추상 클래스 정의

2. 태그 값에 따라 동작이 달라지는 메서드들을 루트 클래스의 추상메서드로 선언 - area() 메서드

3. 태그 값과 상관없이 동작이 일정한 메서드들을 루트 클래스의 일반 메서드로 추가

4. 모든 하위 클래스에서 공통으로 사용하는 데이터 필드들도 루트 클래스로 올린다.

5. 루트 클래스를 확장한 구체 클래스를 의미별로 하나씩 정의 - Figure 클래스를 확장한 Circle 클래스, Rectangle 클래스

6. 루트 클래스가 정의한 추상 메서드들을 각자의 의미에 맞게 구현

 

 - 클래스 계층 구조로 변환된 코드

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;
    }
}

 

 유연성, 확장성 증가

 

 - 정사각형 추가될 경우

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

    @Override
    public double area() {
        return super.area();
    }
}

 

핵심 정리

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

---

 

.아이템 24 - 멤버 클래스는 되도록 static으로 만들라

 

 중첩 클래스(nested class)란 다른 클래스 안에 정의된 클래스를 말한다. 중첩 클래슨느 자신을 감싼 바깥 클래스에서만 쓰여야 하며, 그 외의 쓰임새가 있다면 톱레벨 클래스로 만들어야 한다. 중첩 클래스의 종류는 정적 멤버 클래스, (비 정적) 멤버 클래스, 익명 클래스, 지역 클래스, 이렇게 네 가지이다. 이 중 첫 번째를 제외한 나머지는 내부 클래스(inner class)에 해당한다. 

 

 1. 정적 멤버 클래스

 

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

 

public class OuterClass {
    private static int outerData = 0;

    public static class StaticNestedClass {

        public void display() {
            System.out.println("Outer data: " + outerData);
        }

        public static void staticMethod() {
            System.out.println("Static method in StaticNestedClass");
        }
    }
}

 

2. 비정적 멤버 클래스

 

  - 정적 클래스와 구문상 static 차이이지만 의미상 차이는 크대. 비정적 멤버 클래스의 인스턴스는 바깥 클래스의 인스턴스와 암죽적으로 연결된다. 그래스 비정적 멤버 클래스의 인스턴스 메스드에서 정규화된 this를 사용해 바깥 인스턴스의 메서드를 호출하거나 바깥 인스턴스 참조를 가져올 수 있다.

public class OuterClass {
    private static int outerData = 0;

    public void outerMethod() {
        System.out.println("Outer method called");
    }

    public class InnerClass {

        public void innerMethod() {
            System.out.println("Inner method called");

            // 바깥 인스턴스의 메서드 호출
            outerMethod();

            // 바깥 인스턴스의 참조 가져오기
            OuterClass.this.outerData = 20;
            System.out.println("Updated outer data: " + OuterClass.this.outerData);
        }
    }
}

    public static void main(String[] args) {
        OuterClass outerObj = new OuterClass();
        OuterClass.InnerClass innerObj = outerObj.new InnerClass();

        innerObj.innerMethod();
    }

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

 

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

 

 3. 익명 클래스

 

  - 응용제 제약이 많고 코드가 길게 되면 가독성이 떨어진다. 람다이전에는 즉석에서 작은 함수 객체나 처리 객체(process object)를 만드는 데 사용했지만. 람다가 등장하며 람다에서 자주 사용된다(아이템 42). 또 다른 주 쓰임으로 정적 팩토리 메서드 구현할 때다.

 

public interface Anonymous {
    void anonymousMethod();
}

    public static void main(String[] args) {

        Anonymous anonymous = new Anonymous() {
            @Override
            public void anonymousMethod() {
                System.out.println("Anonymous Method");
            }
        };
    }

 

4. 지역 클래스

 

 - 가장 드물게 사용되며 지역변수와 비슷하게 사용. 감독 성을 위해 짧게 작성

 

    public static void main(String[] args) {
        
        class LocalClass {
            public void localMethod() {
                System.out.println("Local Method");
            }
        }
    }

 

핵심 정리

 중첩 클래스에는 네 가지가 있으며, 쓰임이 각각 다르다.
메서드 밖에서도 사용해야 하거나 메서드 안에 정의하기엔 너무 길다면 멤버 클래스로 만든다.
멤버 클래스의 인스턴스 각각이 바깥 인스턴스를 참조한다면 비정적으로, 그렇지 않으면 정적으로 만들자.

중첩 클래스가 한 메서드 안에서만 쓰이면서 그 인스턴스를 생성하는 지점이 단 한 곳이고 해당 타입으로 쓰기에 적합한 클래스나 인터페이스가 이미 있다면 익명클래스로 만들고, 그렇지 않으면 지역 클래스로 만들다.

---

 

.아이템 25 - 톱레벨 클래스는 한 파일에 하나만 담으라.

 

 소스 파일 하나에 톱레벨 클래스를 여러 개 선언하면 어느 소스 파일을 먼저 컴파일 하나야 따라 사용하는 게 달라진다.

 

    public static void main(String[] args) {
        System.out.println(Utensil.NAME + " " + Dessert.NAME);
    }
    
// 두 클래스가 한파일1 - Dessert.java
class Utensil {
    static final String NAME = "pan";
}

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

// 두 클래스가 한파일2 - Utensil.java
class Utensil {
    static final String NAME = "pan";
}

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

 

- 위의 같은 경우는 중복정의로 컴파일 오류 발생!

 

 해결 책은 단순히 톱레벨 클래스들을 서로 다른 소스파일로 분리하면 된다. 

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";
    }
}

 

핵심 정리

 소스 파일 하나에는 반드시 톱레벨 클래스(혹은 톱레벨 인터페이스)를 하나만 담자.

---

 

📝 느낀점.

 클래스와 인터페이스에 관하여 여럿 지식들을 습득하였다. 적재적소에 인터페이스 추상화, 클래스등을 사용하면 좋을 것 같다.