4-1 상속, 인터페이스, 클래스의 권한 최소화(+Java9 모듈)

접근제어자를 적극적으로 활용하라. (전부다 Public으로 만들지 마라)

 

잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다. 오직 API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작 방식 에는 전혀 개의치 않는다. 정보 은닉, 혹은 캡슐화라고 하는 이 개념은 소프트 웨어 설계의 근간이 되는 원리다.

 

# public 클래스에는 필드 접근자를 사용하지 마라.

getter setter를 사용하라는 말입니다. 불변 필드라고 해도 굳이 노출시켜서 캡슐화를 꺨 필요는 없습니다.

물론 inner private 클래스의 경우는 필요하다면 굳이 getter로 접근하는 것 보다, 필드로 바로 접근해도 됩니다.

 

 

# 변경 가능성(side-effect)를 최소화하라

• 필요없는 setter 메서드는 제공하지 마십시오.
• 상속받을 일이 없는 클래스를 확장할 수 없도록 제한하십시오. (final 클래스, private 생성자)
• 가능한 모든 필드를 final과 private로 선언하십시오.

 

# 상속보다는 컴포지션(필드로 받아오기)를 사용하라.

상속은 하위 클래스가 is-a 관계일 때, 즉 처음 설계부터 상속으로 기능을 확장하고자 할 때 사용하세요.

굳이 필요없는 클래스들을 상속관계로 만들지 말고, 필드로 가지고 있으세요. 상위 클래스가 확장을 고려하지 않았다면 문제가 될 수 있고 필요없는 상속은 캡슐화를 해칩니다.

• 상속할 클래스의 API에 결함이 없는가?
• 결함이 있다면, 자식 클래스의 API까지 전파돼도 괜찮은가?
• is-a 관계라고 해도 문서화 되지 않았거나 확장을 목적으로 만들지 않았다면 컴포짓(데코레이터) 패턴을 사용하자

Composit(Decorator)는 자식 클래스를 생성자 인자로 넘겨 필드에 가지고 있는 방법입니다. new Beverage(new Cream(New Mocha))) 처럼 사용. 

 

 

# 상속을 고려해 설계하고, 문서화하라. (그러지 않았다면 상속을 하지마라)

상속용 클래스를 설계하는건 어려운 일입니다. 필요없다면 반드시 final class로 상속을 방지하세요.

문서화하지 않고 대충 만들었다가 내부 구현 방식을 믿고 활용하던 하위 클래스를 오작동 할 수 있습니다. 복잡한 상속관계에서 하위 클래스에서 상위 클래스의 문제를 찾는건 결코 쉬운일이 아닙니다.

• 상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지 문서로 남겨야 한다.
  (@implSpec : 자바 개발팀이 내부적으로 자바독의 커스텀태그 기능을 사용하는 규약)
• 클래스의 내부 동작 과정 중간에 끼어들 수 있는 훅을 잘 선별하여 protected메서드 형태로 공개해야 할 수도 있다.
• 상속용으로 설계한 클래스는 배포 전에 반드시 하위 클래스를 만들어 검증해야 한다.
• 상속용 클래스의 생성자는 직접적으로든 간접적으로든 재정의 가능 메서드를 호출해서는 안된다.

 

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

상속보다 인터페이스를 사용하는게 더 좋습니다. 계층구조가 없고, 다중 상속에 안전한 하니까요.

거기에 추가로 가능하면 클래스의 골격 구조 구현은 인터페이스와 default, private(java9의 오버라이딩 방지 메서드)를 이용하는게 좋습니다.

 

가능하면 이라는 말을 붙인 이유는, 구현상 인터페이스 제약 때문에 추상 클래스를 사용하는 경우도 있기 때문입니다.

public class VendingMachine extends AbstractVending {
    @Override
    public void chooseProduct() {
        System.out.println("음료수를 선택 한다.");
    }
}

public interface VendingService {
    void start();
    void chooseProduct();
    void stop();
    void process();
}

public abstract class AbstractVending implements VendingService{

    @Override
    public void process() { // default 메서드를 이렇게 사용할 수는 없으니까요.
        start();
        chooseProduct();
        start();
    }
    
    @Override
    public void start() {
        System.out.println("음료수 선택 시작");
    }

    @Override
    public void stop() {
        System.out.println("음료수 선택 끝");
    }
}

 

 

# 인터페이스는 구현하는 입장을 고려해서 설계하라.

default 메서드를 추가하는 경우, 기존의 해당 인터페이스를 사용하는 구현체에서 잘 동작할지는 보장할 수 없습니다. 항상 인터페이스를 설계할 때에는 `이미 구현되었거나, 구현하고자하는 객체`의 입장을 고려해서 설계하세요.

 

만약 default메서드를 재정의하지않고 그대로 사용하게 만들고 싶다면 Java9의 private 인터페이스 메서드도 있습니다.

 

 

 

# 인터페이스를 상수용으로 사용하지 마라. (타입을 정의하는 용도로 사용)

인터페이스에 상수를 사용할 수 있다고해서, 상수용 유틸 객체를 interface로 만드는건 좋지않습니다. 애초에 인터페이스는 내부구현입니다. 내부 구현을 굳이 클래스의 공용 API (상수)로 노출시키는건 나쁜 방법입니다.

public interface Constants { // NOPE!! 유틸 클래스를 따로 만드십시오.
    static final double AVG = 6.2345235123;
    static final double AVG = 9.11111115222;
    static final double AVG = 1.3542345235;
}

 

 

 

# 태그(주석)가 달린 범용 클래스를 설계하지 마라. 계층 구조를 이용하라

아래와 같이 태그가 달린 클래스를 써야하는 상황은 거의 없습니다.

만약 이렇게 쓰고있다면 리팩토링을 통해 태그를 없애고 상속을 이용해 계층구조로 만들어야 합니다.

// 상속을 이용한 계층구조로 분리해야하는 클래스.
// 태그를 이용해서 상속없이 대충 구현하였다. 리펙토링이 필요하다.
public class Animal {
   enum Type{ DOG, CAT }// ??? 뭐야 이건?
   
   final Type type;
   
   //dog에서만 쓰는 필드..?
   final String name;
   
   //cat에서만 쓰는 필드...???
   final int age;
   
   //dog용 생성자
   public Animal(String name){
       this.name = name;
   }
   
   //cat용 생성자
   public Animal(int age){
       this.age = age;
   }
}

 

 

# 멤버 클래스 (inner 클래스)는 static으로 만들어라.

멤버 클래스의 인스턴스가 outer 클래스의 필드(인스턴스)를 참고한다면 non-static으로 만들어야 합니다.

다만 가능하면 static으로만 사용하는게 좋습니다. static을 가지면 outer 클래스의 참조가 필요없어집니다.

• 비정적 멤버 클래스는 숨은 참조 (outer 인스턴스)를 가지게되고 이는 더 많은 비용과 메모리를 사용합니다.
• GC가 outer 클래스의 인스턴스를 수거 못해서 메모리 누수가 발생하기 쉽습니다. (이런 문제를 찾기도 어렵습니다.)

 

 

# 한 파일 (.java)파일에는 한 클래스만 담으세요.

inner 클래스를 말하는게 아닙니다. Top level 클래스에서는 한 파일에 한 클래스만 담으세요.

애초에 자바 컴파일러는 파일 단위(.java)가 아닌 클래스 단위(CLASS)로 바이트코드 파일(.class)를 생성합니다. 한 자바코드에 여러 클래스를 담게되면 수정하지도 않은 다른 클래스를 같이 컴파일 해야합니다.

 

 

# Java 9의 모듈 시스템

아직 사용하기 이르긴하지만, Java9 부터 하나 이상의 패키지를 가진 `모듈`이라는 개념이 추가되었다. Java9 이후부터 자바 앱은 반드시 자바 모듈로 패키징 되도록 변경할 예정이라고 합니다.
(Gradle 과 비슷한 자바 자체의 모듈시스템이라고 생각하면 됩니다.)

• 이름이 무엇인가? (module name)
• 이 모듈은 어떤것을 제공하는가? (export)
• 이 모듈을 사용하려면 어떤것들이 필요한가 ? (require)
• 이 모듈이 참조하고 있는 모듈들을 외부의 다른 모듈에서 사용 가능한가? (opens)

module-info.java에 작성할 내용들 (아래)

// 모듈은 패키지와 만드는 방법이 같다. 폴더처럼 구성하면 된다.
// 다만 모듈 루트 디렉토리 안에는 아래와 같은 자바코드를 반드시 작성해야 한다.
module com.modules.example {
    // 사용하는 필요한 모듈 정의
    requires com.other.modules;

    // 외부에 노출할 모듈 정의.
    exports com.modules.example; // 하위 패키지 포함 안되고 example 바로 하위에 있는 것만

    exports com.modules.example.a.b; // 부모 패키지(a) export 안 하고 (b)만 export 가능

}

 

패키지 단위로 캡슐화하고, 필요한 모듈을 JVM start-up 타임에 검사한다. 이전에는 missing classes (존재하지 않는 클래스)를 사용하는 시점에 런타임 에러를 발생시켰지만, 이제 JVM이 시작하는 시점에 이를 모듈의 정보로 확인해줍니다.

 

Java 8의 경우, 모든 패키지들이 사용 가능해서 보안상 노출이 되지말아야할 패키지도 모든 개발자가 접근 가능했습니다. 그래서 Java9부터 개발자가 사용하지말아야할 패키지를 모듈 내부에 숨길 수 있습니다.

 

즉 모듈 시스템을 통해 Java9에서는 접근제어자가 아래와 같이 세분화 됩니다.

• 외부에 모두 Public (public to everyone who reads this module (exports))
• 특정 모듈에만 Public (public to some modules that read this module (exports to))
• 모듈 내부만 Public (public to every other class within the module itself)
• private
• default
• protected

아직은 Java8이 대세이기 때문에 사용하지는 않지만, 궁금하다면 Project Jigsaw를 참고하자.

Java 9 와 Project Jigsaw 소개 1