내 코드가 그렇게 이상한가요? - 컬렉션 : 중첩을 제거하는 구조화 테크닉

컬렉션 : 중첩을 제거하는 구조화 테크닉

내 코드가 그렇게 이상한가요? 라는 책을 보고 내가 공부한 내용이나 생각한 내용에 대해 작성하는 글이다.
7장 컬렉션 : 중첩을 제거하는 구조화 테크닉을 읽고 생각하는 내용에 대해 적어보겠다.
단, 책 내용 중 별 내용 아니라 판단하면 생략하도록 하겠다.

컬렉션 처리를 캡슐화하기

위 내용을 공부하기 위해서는 선행으로 이전 내용을 알아야 좋을 거 같다.
컬렉션 객체에 대하여 특정 기능을 하는 메서드가 있고, 해당 메서드가 서로 다른 클래스에 중복으로 구현됐을 때 문제를 해결하는 방법에 대해 설명한다.

컬렉션과 관련하여 응집도가 낮아지면 일급 컬렉션 패턴을 사용해 해결할 수 있다. 일급 컬렉션은 컬렉션 관련된 로직을 캡슐화하는 디자인 패턴이다.

클래스에는 아래 두 가지가 있어야 한다.

• 인스턴스 변수(필드)
• 인스턴스 변수에 잘못된 값이 할당되지 않게 하고(가드) 정상적으로 조작하는 메서드

클래스 설계 원리 반영하여 일급 컬렉션도 다음과 같은 요소로 구성할 수 있겠다.

• 컬렉션 자료형의 인스턴스 변수
• 컬렉션 자료형의 인스턴스 변수에 잘못된 값이 할당되지 않게 하고 정상적으로 조작하는 메서드

컬렉션 자체를 클래스로 감싸서 컬렉션을 조작할 때 해당 클래스에 접근하여 메서드를 통해 조작하게 된다면 해당 컬렉션에 대해 응집도가 떨어지게 된다.

class Party{
    private final List<Member> members;

    Party() {
        // 생성자
    }

    Party add(...) {
        // 가드를 포함한 로직
    }

    boolean isAlive(...) {
        // 조건을 포함한 기타 로직
    }
}

위 예시는 List<\Member>인 members를 조작하는 코드를 한 곳으로 모아 관리할 수 있게 하는 클래스다.
같은 로직이고 같은 목적으로 사용되는 코드의 응집도를 높여줄 수 있다.
단, 유사해 보이지만 다른 목적으로 사용되는 같은 로직인 코드의 경우는 신중하게 한 곳으로 모아야 한다.

외부로 전달할 때 컬렉션의 변경 막기

외부로 members를 전달할 때 컬렉션을 조작할 수 있다.
party.add()가 아니라 반환 받은 members.add()를 통해 조작한다면 애써 구현한 add() 메서드가 무용지물이 되기 때문에 안전하지 않는 객체가 된다

class Party{
    List<Member> members() {
        return members.unmodifiableList();
    }
}

위 방법을 통해 members를 안전하게 반환할 수 있다.

생각

보통 컬렉션을 단독으로 사용하는 경우가 있던가 싶긴 하지만 아주 없는 경우는 아니라 생각한다.
보통 나의 경우에서는 컬렉션을 사용할 때 특정 클래스의 인스턴스 변수로 두고 사용한다 때문에 해당 클래스에 매서드를 구현하고 조작하는 방법을 사용하기 때문에 생소한 내용은 아니었지만 외부 절당 시 컬렉션의 변경을 막는 방법에 대해서는 새롭게 알게 되었다.
앞으로는 더 안전한 객체를 생성할 수 있겠다.