[자바 코딩의 기술] 7장 : 객체 디자인

자바의 클래스와 객체를 올바르게 기능만 동작하게 하는 것은 부족하다!

보기 좋아야 하고 사용하기도 편해야만 한다!!

7장에서는 더 객체 지향적이고 강력한 코드를 만드는데 유용하게 쓰일 자바의 보편적인 디자인 원리를 강조하겠다.

 

7.1 불 매개변수로 메서드 분할

문제 코드

    void log(String message, boolean classified) throws IOException {
        if (classified) {
            writeMessage(message, CAPTAIN_LOG);
        } else {
            writeMessage(message, CREW_LOG);
        }
    }

위 코드는 boolean의 상태에 따라 서로 다른 작업을 수행한다.

이는 동작에 문제가 없지만 읽기 불편하고 메서드를 사용하는 사람이 True와 False가 각각 무슨 의미인지 알고 있어야만 한다.

 

이 코드를 좀 더 향상 시키려면 boolean 매개변수가 실제로 어떤 역할을 하는지 알아보기 쉽게 만들어야 한다. (혼동을 줄임)

개선 코드

    void writeToCaptainLog(String message) throws IOException {
        writeMessage(message, CAPTAIN_LOG);
    }

    void writeToCrewLog(String message) throws IOException {
        writeMessage(message, CREW_LOG);
    }

위 코드처럼 boolean이 쓰인 메서드를 여러 개로 분리함으로써 코드가 향상될 수 있다.

 

*개선 방법*

1. 매개변수로 구분하던 제어 흐름 경로마다 새 메서드를 추가

2. 메서드에 의미 있는 이름을 지어주어 코드 가독성 높임

메서드가 어디에 속하며 무엇을 하는지 메서드명만 봐도 확실히 알 수 있어짐.

7.2 옵션 매개변수로 메서드 분할

옵션 매개변수도 불 매개변수 처럼 메서드 분할을 통해 코드를 개선할 수 있다.

문제 코드

class Logbook {

    static final Path CREW_LOG = Paths.get("/var/log/crew.log");

    List<String> readEntries(LocalDate date) throws IOException {
        final List<String> entries = Files.readAllLines(CREW_LOG,
                StandardCharsets.UTF_8);
        if (date == null) {
            return entries;
        }

        List<String> result = new LinkedList<>();
        for (String entry : entries) {
            if (entry.startsWith(date.toString())) {
                result.add(entry);
            }
        }
        return result;
    }
}

 

인자로 null 인 것과 null이 아닌 것이 넘어올 수 있는데 이때 서로 다른 작업이 실행된다.

호출자 입장에서 null로 인자로 넘길 때 어떤 결과가 나올지 예상하기 어렵다..

그렇기 때문에 이 부분을 리팩토링 할 수 있다.

개선 코드

class Logbook {

    static final Path CREW_LOG = Paths.get("/var/log/crew.log");

    List<String> readEntries(LocalDate date) throws IOException {
        Objects.requireNonNull(date);
        
        List<String> result = new LinkedList<>();
        for (String entry : readAllEntries()) {
            if (entry.startsWith(date.toString())) {
                result.add(entry);
            }
        }
        return result;
    }

    List<String> readAllEntries() throws IOException {
        return Files.readAllLines(CREW_LOG, StandardCharsets.UTF_8);
    }
}

'불 매개변수'를 개선한 것처럼 '옵션 매개변수' 또한 메서드를 여러 개로 분할해주면 된다.

 

*개선 방법*

1. 각각의 제어 흐름을 하나의 메서드로 표현.

2. 메서드명을 통해 무엇을 할 것인지 명확히 전달.

 

readAllEntriles()는 '모든 엔트리를 읽어온다'라는 의미를 한눈에 알 수 있고 더 이상 null을 사용하지 않아도 된다.

7.3 구체 타입보다 추상 타입

변수에 추상적인 타입을 사용할수록 코드는 더 유연해진다!

문제 코드

class Inventory {
    LinkedList<Supply> supplies = new LinkedList();

    void stockUp(ArrayList<Supply> delivery) {
        supplies.addAll(delivery);
    }

    LinkedList<Supply> getContaminatedSupplies() {
        LinkedList<Supply> contaminatedSupplies = new LinkedList<>();
        for (Supply supply : supplies) {
            if (supply.isContaminated()) {
                contaminatedSupplies.add(supply);
            }
        }
        return contaminatedSupplies;
    }
}

class Usage {
    static void main(String[] args) {
        CargoShip cargoShip = null;
        Inventory inventory = null;
        Stack<Supply> delivery = cargoShip.unload();
        ArrayList<Supply> loadableDelivery = new ArrayList<>(delivery);
        inventory.stockUp(loadableDelivery);
    }
}

위 코드는 LinkenList<>, ArraryList<> 등의 구체 타입으로 파라미터 타입이나, 변수 타입을 지정하고 있다. 이렇게 하면 여러 자료 구조 간 타입 간 변환이 잦아지고 Inventory클래스를 변경할 경우 다른 부분에도 영향을 미치게 된다....(객체 지향에 안좋음)

 

추상 타입을 쓰면 이 문제를 개선할 수 있다.

개선 코드

class Inventory {
    List<Supply> supplies = new LinkedList();

    void stockUp(Collection<Supply> delivery) {
        supplies.addAll(delivery);
    }

    List<Supply> getContaminatedSupplies() {
        List<Supply> contaminatedSupplies = new LinkedList<>();
        for (Supply supply : supplies) {
            if (supply.isContaminated()) {
                contaminatedSupplies.add(supply);
            }
        }
        return contaminatedSupplies;
    }
}

코드가 개선 된 3가지 측면을 살펴보자.

1. supplies 필드에 List 인터페이스 사용 -> 인벤토리에 제품이 어떻게 저장되는지 알 수 없어짐 (다양한 객체 넣을 수 있어짐)
2. stockUp() 메서드가 파라미터로 어떤 Collection이든 허용 -> 즉, 어떤 하위 타입이든 메서드로 전달 가능해짐.
3. getConataminatedSupplies() 구체적인 타입이 아닌 추상적인 List<> 타입을 반환함.
   -> 제품의 반환은 List형태이지만 내부적으로 어떻게 저장했는 지는 외부에 알리지 않음

class Usage {
    static void main(String[] args) {
        CargoShip cargoShip = null;
        Inventory inventory = null;
        Stack<Supply> delivery = cargoShip.unload();
        inventory.stockUp(delivery);
    }
}

stockUp 사용 시 타입 변환 없이 Stack 타입을 바로 Collection으로 받아서 사용할 수 있다.

7.4 가변 상태보다 불변 상태 사용하기

기본적으로 객체의 상태는 불변이다. 가능하면 객체를 불변으로 만들어야 잘못 사용할 경우가 적다.

문제 코드

class Distance {
    DistanceUnit unit;
    double value;

    Distance(DistanceUnit unit, double value) {
        this.unit = unit;
        this.value = value;
    }

    static Distance km(double value) {
        return new Distance(DistanceUnit.KILOMETERS, value);
    }

    void add(Distance distance) {
        distance.convertTo(unit);
        value += distance.value;
    }

    void convertTo(DistanceUnit otherUnit) {
        double conversionRate = unit.getConversionRate(otherUnit);
        unit = otherUnit;
        value = conversionRate * value;
    }
}


class Main {
    static void usage() {
        Distance toMars = new Distance(DistanceUnit.KILOMETERS, 56_000_000);
        Distance marsToVenus = new Distance(DistanceUnit.LIGHTYEARS, 0.000012656528);
        Distance toVenusViaMars = toMars;
        toVenusViaMars.add(marsToVenus);
    }
}

toMars와 toVenusViaMars는 같은 객체를 가르킨다. 따라서, toVenusViaMars.add(marsToVenus)를 실행하면 toMars객체도 변경이 일어나게 된다. (value 값은 변동)

개선 코드

final class Distance {
    final DistanceUnit unit;
    final double value;


    Distance(DistanceUnit unit, double value) {
        this.unit = unit;
        this.value = value;
    }

    Distance add(Distance distance) {
        return new Distance(unit, value + distance.convertTo(unit).value);
    }

    Distance convertTo(DistanceUnit otherUnit) {
        double conversionRate = unit.getConversionRate(otherUnit);
        return new Distance(otherUnit, conversionRate * value);
    }
}

class Main {
    static void usage() {
        Distance toMars = new Distance(DistanceUnit.KILOMETERS, 56_000_000);
        Distance marsToVenus = new Distance(DistanceUnit.LIGHTYEARS, 0.000012656528);
        Distance toVenusViaMars = toMars.add(marsToVenus)
                                        .convertTo(DistanceUnit.MILES);
    }
}

객체는 유효하지 않은 변경이 일어나지 않도록 가변성을 제한해 스스로를 보호할 수 있다.

 

생성자의 value와 unit필드에 final 키워드를 사용하면 이후로는 변경할 수 없다.

따라서, 거리를 계산하려면 매번 새로운 인스턴스가 필요하다.

 

add() 와 convertTo() 함수는 수행 후 새로운 인스턴스를 만들어 반환한다.

이렇게 하면 Distance의 불변 상태를 유지할 수 있다.

 

클래스 정의 앞에 final 키워드를 붙이는 경우는 클래스를 더 이상 확장할 수 없게 하려는 의도이다.

7.5 상태와 동작 결합하기

문제 코드

class Hull {
    int holes;
}


class HullRepairUnit {

    void repairHole(Hull hull) {
        if (isIntact(hull)) {
            return;
        }
        hull.holes--;
    }

    boolean isIntact(Hull hull) {
        return hull.holes == 0;
    }
}

상태와 동작의 결합은 객체 지향 프록그래밍의 기본 틀 중 하나이다.

위 코드는 상태와 동작이 별개의 클래스로 나뉘어 있다.

 

위와 같이 사용하면 문제는 '정보 은닉'이 불가능해지고 코드를 이해하기 더 어려워진다는 점이다.

Hull 클래스는 HullRepairUnit 바같에 있는 클래스이므로 자신의 상태에 대해 읽기와 쓰기 접근을 제공해야만 한다.

 

상태와 동작을 올바르게 결합해서 코드를 개선해보자.

개선 코드

class Hull {
    int holes;

    void repairHole() {
        if (isIntact()) {
            return;
        }
        holes--;
    }

    boolean isIntact() {
        return holes == 0;
    }
}

HullRepairUnit을 완전히 지웠다. 이제 Hull은 스스로 기능을 제공한다.

Hull 메서드는 자신의 내부 상태를 직접 처리할 수 있고 메서드 매개변수로 사용하지 않아도 된다.

또한, 게터, 세터를 통해 외부로 상태를 노출하지 않아도 된다.

 

요약하면 메서드 내에서 입력 매개변수만 다루고 자신이 속한 클래스 인스턴스 변수는 다루지 않는 경우는 유심히 봐야한다.

이것은 상태와 동작이 분리되었다는 의미이고 이러한 메서드로는 '정보 은닉'이 불가능하다.

7.6 참조 누수 피하기

문제 코드

class Inventory {

    private final List<Supply> supplies;

    Inventory(List<Supply> supplies) {
        this.supplies = supplies;
    }

    List<Supply> getSupplies() {
        return supplies;
    }
}

class Usage {

    static void main(String[] args) {
        List<Supply> externalSupplies = new ArrayList<>();
        Inventory inventory = new Inventory(externalSupplies);

        inventory.getSupplies().size(); // == 0
        externalSupplies.add(new Supply("Apple"));
        inventory.getSupplies().size(); // == 1

        inventory.getSupplies().add(new Supply("Banana"));
        inventory.getSupplies().size(); // == 2
    }
}

위 코드는 어느 부분이 문제가 될까?

 

먼저 inventory는 내부의 제품 리스트를 전혀 보호하지 않는다!

 

위 코드에서 재고 추가는 클래스 내부가 아니더라도 여러 곳에서 가능하다....

1. 외부에서 생성한 리스트를 이용해 재고 추가 -> externalSupplies.add(new Supply("Apple")); 

2. 클래스의 메서드를 이용하여 리스트 참조해 외부에서 재고 추가 -> inventory.getSupplies().add(new Supply("Banana"));

 

그렇다면 클래스 내부를 초기화한 후 조작되지 않도록 보호하려면 어떻게 해야할까??

class Inventory {

    private final List<Supply> supplies;

    Inventory(List<Supply> supplies) {
        this.supplies = new ArrayList<>(supplies);
    }

    List<Supply> getSupplies() {
        return Collections.unmodifiableList(supplies);
    }
}

class Usage {

    static void main(String[] args) {
        List<Supply> externalSupplies = new ArrayList<>();
        Inventory inventory = new Inventory(externalSupplies);

        inventory.getSupplies().size(); // == 0
        externalSupplies.add(new Supply("Apple"));
        inventory.getSupplies().size(); // == 0

        // UnsupportedOperationException
        inventory.getSupplies().add(new Supply("Banana"));
    }
}

먼저 위 코드는 전달한 리스트의 참조가 아니라 리스트 내 Supply객체로 내부 ArrayList를 채운다.

-> this.supplies = new ArrayList<>(supplies); (방어 복사)

 

그리고 getSupplies() 호출 시 -> return Collections.unmodifiableList(supplies); 로 래핑한 후 반환해서 읽기 접근만 가능하게 만든다.

 

이렇게 하면 외부에서는 내부의 리스트를 조작할 수 없으니 외부에서 내부로 영향을 주지 못한다.

7.7 널 반환하지 않기

메서드 호출 시 반환할 값이 없으면 그냥 'null'을 반환하는 프로그래머가 있다. 이것은 프로그램의 안정성을 해치는 행동이다.

문제 코드

class SpaceNations {

    static List<SpaceNation> nations = Arrays.asList(
            new SpaceNation("US", "United States"),
            new SpaceNation("RU", "Russia")
    );

    static SpaceNation getByCode(String code) {
        for (SpaceNation nation : nations) {
            if (nation.getCode().equals(code)) {
                return nation;
            }
        }
        return null;
    }
}

위 코드는 getByCode() 메서드 사용 시 code가 같은 것이 없다면 'null'을 반환한다.

 

이는 같은 국가 코드가 없다면 너무 쉽게 'NullPointerException'을 발생시킨다.

물론 호출하는 쪽에서 null을 검증할 수 있지만 누군가는 잊어버리고 예외를 발생하게 둘 수 있다..

 

따라서, null말고 다른 무언가를 반환하는 쪽으로 개선해보자.

개선 코드

class SpaceNations {

    /** Null object. */
    static final SpaceNation UNKNOWN_NATION = new SpaceNation("", "");

    static List<SpaceNation> nations = Arrays.asList(
            new SpaceNation("US", "United States"),
            new SpaceNation("RU", "Russia")
    );

    static SpaceNation getByCode(String code) {
        for (SpaceNation nation : nations) {
            if (nation.getCode().equals(code)) {
                return nation;
            }
        }
        return UNKNOWN_NATION;
    }
}

위 코드는 "널 객체 패턴"을 사용했다. null을 반환하는 대신 널 객체(null object), 즉 객체에 실질적인 값이 없음을 명시적으로 표현한 객체를 반환하는 방식이다. 

 

예제에서는 UNKOWN_NATION -> SpaceNation("", "")

 

이렇게 하면 호출자쪽에서 'NullPointerException'이 발생하지 않기 때문에 널 객체를 무시할지 예외를 던질 지 선택할 수 있다.

7.8 7장에서 배운 내용

우리는 코드 작성자가 어떤 근거로 디자인 결정을 내렸는지 알아내는데 많은 노력을 기울여야 한다.

 

코드 디자인은 항상 선택의 연속이며 그 득실에 대한 책임은 개발자의 몫이다.

 

<가독성>, <테스트 가능성>, <유지 보수성>, <성능> 등의 트레이드 오프를 고려해 개발자는 올바른 결정을 내려야 한다.