오브젝트 (역할, 책임, 협력/캡슐화와 응집도에 대하여)

모든 소프트웨어 모듈에는 세 가지 목적이 있다.
첫 번째 목적은 실행 중에 제대로 동작하는 것이다.
두 번째 목적은 변경을 위해 존재하는 것이다.
세번째 목적은 코드를 읽는 사람과 의사소통하는 것이다.
— 로버트 마틴, <클린 소프트웨어: 애자일 원칙과 패턴, 그리고 실천 방법>

 

변경에 취약한 코드란

하나의 클래스가 다른 클래스에 대한 정보(인스턴스, 메소드)를 지나치게 직접 접근할 경우 변경에 취약한 코드가 된다. 지나치게 세부적인 사실에 의존해서 동작할 경우 이러한 세부적인 사실 중 한 가지라도 바뀌면 해당 클래스뿐만 아니라 이 클래스에 의존하는 클래스들도 함께 변경해야한다.

이것은 객체 사이의 의존성과 관련된 문제로, 의존성은 변경에 대한 영향을 암시한다. 객체지향 설계는 서로 의존하면서 협력하는 객체들의 공동체를 구축하는 것으로, 애플리케이션의 기능을 구현하는 데 필요한 최소한의 의존성만 유지하고 불필요한 의존성을 제거하여야 한다.

cf) 객체 사이의 의존성이 과한 경우를 가리켜 결합도가 높다고 말한다.

자율성을 높이자

다음 코드의 문제점을 찾아보자.

public class Theater {
    private TicketSeller ticketSeller;

    public Theater(TicketSeller ticketSeller) {
        this.ticketSeller = ticketSeller;
    }

    public void enter(Audience audience) {
        if (audience.getBag().hasInvitation()) {
            Ticket ticket = TicketSeller.getTicketOffice().getTicket();
            audience.getBag().setTicket(ticket);
        } else {
            Ticket ticket = ticketSeller.getTicketOffice().getTicket();
            audience.getBag().minusAmount(ticket.getFee());
            ticketSeller.getTicketOffice().plusAmount(ticket.getFee());
            audience.getBag().setTicket(ticket);
        }
    }
}

위 Theater은 관람객의 가방과 판매원의 매표소에 직접 접근하기 때문에 코드를 이해하기 어렵다. 또한 관람객과 판매원이 자신의 일을 스스로 처리해야 한다는 우리의 직관을 벗어난다.

해결방법

Theater가 Audience와 TicketSeller에 관해 너무 세세한 부분까지 알지 못하도록 정보를 차단한다. 관람객이 스스로 가방 안의 현금과 초대장을 처리하고 판매원이 스스로 매표소의 티켓과 판매 요금을 다루게 한다. 다시말해, 관람객과 판매원을 자율적인 존재로 만든다.

public class Theater {
    private TicketSeller ticketSeller;

    public Theater(TicketSeller ticketSeller) {
        this.ticketSeller = ticketSeller;
    }

    public void enter(Audience audience) {
        ticketSeller.sellTo(audience);
    }
}

수정된 Theater 클래스 어디서도 ticketOffice에 접근하지 않는다. Theater는 ticketOffice가 TicketSeller내부에 존재한다는 사실을 알지 못한다. Theater는 단지 ticketSeller가 sellTo메시지를 이해하고 응답할 수 있다는 사실만 알고 있을 뿐이다.

Theater는 오직 TicketSeller의 인터페이스(interface)에만 의존한다. TicketSeller가 내부에 TicketOffice 인스턴스를 포함하고 있다는 사실은 구현(implementation)의 영역에 속한다.

💡 객체를 인터페이스와 구현으로 나누고 인터페이스만을 공개하는 것은 객체 사이의 결합도를 낮추고 변경하기 쉬운 코드를 작성하기 위해 따라야 하는 가장 기본적인 설계 원칙이다.

 

캡슐화와 응집도

개념적이나 물리적으로 객체 내부의 세부적인 사항을 감추는 것을 캡슐화라고 부른다. 캡슐화의 목적은 변경하기 쉬운 객체를 만드는 것이다. 캡슐화를 통해 객체 내부로의 접근을 제한하면 객체와 객체 사이의 결합도를 낮출 수 있기 때문에 설계를 좀 더 쉽게 변경할 수 있다.

밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임하는 객체를 가리켜 응집도가 높다고 말한다. 자신의 데이터를 스스로 처리하는 자율적인 객체를 만들면 결합도를 낮출 수 있을 뿐더러 응집도를 높일 수 있다.

절차지향과 객체지향

수정 전 코드에서는 Audience, TicketSeller, Bag, TicketOffice로 부터 관람객을 입장시키는 데 필요한 정보를 가져와 Theater의 enter메서드에서 모든 처리를 진행했다.

이 관점에서의 Theater의 enter 메서드는 프로세스(Process) 이며 Audience, TicketSeller, Bag, TicketOffice 는 데이터(Data)다. 이처럼 프로세스와 데이터를 별도의 모듈에 위치시키는 방식을 절차적 프로그래밍(Procedural Programming)이라고 부른다.

자신의 데이터를 스스로 처리하도록 프로세스의 적절한 단계를 Audience, TicketSeller 로 이동시키는 것처럼 데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍하는 방식을 객체지향 프로그래밍(Object-Oriented Programming) 이라고 부른다.

---

역할, 책임, 협력

협력

객체지향 시스템은 자율적인 객체들의 공동체다. 두 객체 사이의 협력은 하나의 객체가 다른 객체에게 도움을 요청할 때 시작된다. 메시지 전송(message sending)은 객체 사이의 협력을 위해 사용할 수 있는 유일한 커뮤니케이션 수단이다. 객체는 다른 객체의 상세한 내부 구현에 직접 접근할 수 없기 때문에 오직 메시지 전송을 통해서만 자신의 요청을 전달할 수 있다.

책임

객체를 설계하기 위해 필요한 문맥인 협력이 갖춰졌다고 하자. 다음으로 할 일은 협력에 필요한 행동을 수행할 수 있는 적절한 객체를 찾는 것이다. 이 때 협력에 참여하기 위해 객체가 수행하는 행동을 책임이라고 부른다. 객체의 책임은 크게 ‘하는 것’과 ‘아는 것’의 두 가지 범주로 나누어 세분화한다.

하는 것

• 객체를 생성하거나 계산을 수행하는 등의 스스로 하는 것
• 다른 객체의 행동을 시작시키는 것
• 다른 객체의 활동을 제어하고 조절하는 것

아는 것

• 사적인 정보에 관해 아는 것
• 관련된 객체에 관해 아는 것
• 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것

“객체지향 개발에서 가장 중요한 능력은 책임을 능숙하게 소프트웨어 객체에 할당하는 것”