캡슐화?

캡슐화란, 변경 될 수 있는 것은 어떤것이라도 감춘다는 것이다.

 

이상적으로 캡슐화가 잘되어 있다고 말하는 설계는, 응집도는 높고 결합도는 낮다. 

다른 말로는 확장에는 열려있고, 수정에 대해서는 닫혀있다.(개방 폐쇄 원칙, OCP)

 

각 객체들은 스스로 역할과 책임을 충실히 하기 때문에, 기능이 변경되어도 수정할 수 있는 부분을 최소한으로 할 수 있다.

즉, 캡술화의 핵심은 변경될 수 있는 부분은 외부로 최대한 노출시키지 않고 협력에 의한 인터페이스로(메시지)만 소통을 하는 것이다.

 

잘못된 예제 (너무 많은 참견을 하는 객체)

 

극장 이라는 클래스를 보자

관객이 초대권이 있냐 없냐에 따라서 분기되고 있으며 중요한 부분은 아래 코드다.

Ticket ticket = ticketSeller.getTicketOffice().getTicket();

 

TicketSeller -> getTicketOffice -> getTicket 객체를 다리 건너 건너 티켓을 가져오고 있는데 이것에 문제점은 캡슐화를 적절하게 하지 못해 변경에 굉장히 취약하다는 점이다. Theater 객체에서 enter 역할은 관람객을 입장시키면 된다. 근데 티켓을 가져오기 위해 건너 건너 참조하여 데이터를 가져와서 setTicket 하는 행위는 Theater에 역할이 아니다. 이렇게 역할이 아닌 Theater 객체에서 코드를 사용한 것처럼 여기 저기 사용하게 된다면 관련 코드 변경이 발생 할 시 여기 저기 코드를 수정해야 하고 이것은 변경에 취약한 설계가 되는 것이다.

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 에서가 아닌 TicketSeller 객체에서 하는 것이다.

이것이 바로 협력이라는 키워드 안에서 적절한 역할을 할 만한 객체를 찾는 행위이다.

다른 말로는 INFORMATION EXPERT 패턴 이라고 부르기도 하며, 이를 통해 한결 변경에 용이하며, 가독성 또한 향상된 코드를 발견할 수 있다.

 

public class Theater {
    private TicketSeller ticketSeller;

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

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

 

가장 중요한 것은 Theater 객체에서는 더이상 TicketOffice 객체를 몰라도 이전 기능을 그데로 수행 한다는 것이다.
TicketOffice 객체를 모른다는 것은 TicketOffice 객체가 변경 되어도 영향이 미치치 않는다는 것이다.

 

참고자료

• 객체지향의 사실과 오해 - 조영호
• 오브젝트 - 조영호