프로그래밍에 대한 고찰 및 생각

[1][오브젝트] - 객체, 설계 본문

책/오브젝트

[1][오브젝트] - 객체, 설계

Source 2022. 1. 8. 18:01

오브젝트의 가장 첫번째 챕터인 "객체, 설계" 파트에서는 극장에서의 티켓판매 시스템을 중심으로 좋은 설계가 무엇이고, 어떤 설계가 문제인지, 그래서 객체지향 설계가 무엇이고 왜 필요한지에 대해 설명한다.

 

01. 좋은 설계란?

이 책에서는 좋은 소프트웨어 모듈 설계에 있어서 다음 3가지를 만족해야 한다고 설명한다.

 

1. 잘 작동해야 한다.

2. 변경이 용이해야 한다.

3. 쉽게 읽고 이해할 수 있어야 한다.

 

그간 소프트웨어 모듈을 설계할 때 1번, 잘 작동하는 것에 모든 초점을 맞추어 설계하였다.

 

예전에는 무언가 조잡해 보이지만 코드를 실행 했을 때 "잘 작동하니까 나름 문제 없는 코드지!" 라는 생각을 했었다. 

 

그러다가 코드리뷰를 통해 잘 작동하는 것을 넘어서 좋은 설계를 하기 위한 조언들을 받으면서 잘 작동하는 것 이상의 필요한 조건들이 있음은 느꼈다. 그러나 그것이 무엇인지는 잘 알지 못했다.

 

그 해답이 2,3번 인 것 같다.

 

물론 2,3번에 대한 필요성을 전혀 몰랐던 것은 아니다. 변경이 쉽고 이해하기 쉽게 짜야하는 것은 알고 있는데(말은 쉽다) 구체적으로 그것을 실현하기 위해 어떤 방법론을 도입하여야 하는지는 알지 못했다.

 

02. Low Coupling

이 책에서 강조하는 내용 중 하나는 결합도(Coupling)을 낮추는 것이다. 

 

결합도가 높다는 것은 무엇일까?

 

public class Theater {
	
    ...

    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 라는 객체는 Audience 라는 청중을 입장시키는 역할을 한다.

 

이때 Ticket을 가져오는 부분을 보자.

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

TicketSeller로부터, TicketOffice로 부터 티켓을 가져온다. 

여기만 봐도 Theater는 TicketSeller, TicketOffice, Ticket 와 모두 연관이 된다.

위의 객체들중 하나라도 수정이 된다면 Theater에도 영향을 미칠 수 있다는 것이다.

 

어떻게 해결 할까?

 

03. 객체 책임의 분리

public class Theater {
 
 	...

    // 손님 입장에만 관여하고 TicketSeller에게 다음 권한을 위임
    public void enter(Audience audience){
        ticketSeller.sellTo(audience);
    }
}

Theater의 역할은 그저 Audience 청중을 입장시키는 것이다. Theater가 굳이 TicketOffice, Bag, Audience의 데이터와 함수들을 알고 있을 필요가 없다.

 

따라서 위처럼 청중이 입장했을 때, TicketSeller 에게 청중을 넘겨주고 다음 역할(초대장이 있는지 확인, 티켓 구매, 정산 등)에 대한 역할을 위임하는 것이다.

 

이렇게 되면 Theater에서는 그 이후에 TicketSeller가 어떤 방식으로 초대장을 확인하고, Audience가 티켓을 구매하고, Bag에서 정산은 어떻게 이루어지는지 알 필요가 없고 결국 결합도를 낮추게 된다.

 

이로인해 결국 자율성이 높아지게 된다.

 

또한 이후에 Audience가 현금이 아닌 카드나 포인트를 이용한다거나, TicketSeller가 돈을 TicketOffice가 아닌 은행에 보관한다고 해도 전혀 영향을 받지 않는다.

 

이렇게 객체와 연관된 작업만 수행하고 연관되지 않은 작업은 다른 객체에게 위임하는 것을 응집도(Cohesion)가 높다고 한다.

 

객체를 자율적으로 만들면 응집도는 높아지고, 결합도는 줄어든다. (High Cohesion Low Coupling)

 

결국 외부의 간섭을 최대한 배제하고 메세지(위 코드의 경우 sellTo()) 를 통해서 협력하는 자율적인 객체들의 공동체를 만드는 것이 훌륭한 객체지향 설계를 얻을 수 있는 지름길이다.

 

 

04. 절차적 프로그래밍, 객체지향 프로그래밍

변경하기 이전의 코드는 절차적 프로그래밍(Procedual Programming) 이다.

이처럼 구현을 하게되면 Theater가 모든 클래스를 제어하기 때문에 의존성이 많아진다.

 

이것을 현재처럼 자신의 데이터를 스스로 처리하게 변경하고 데이터와 프로세스를 동일한 모듈 내에 위치하도록 프로그래밍 하는 것을 객체지향 프로그래밍(Object Oriented Programming) 이라고 한다.

 

즉 책임을 분리하는 것이다.

- Theater 는 관람객의 입장만을 책임지고

- TicketSeller 는 티켓 판매만을 책임지고

- Audience 는 티켓 구매만을 책임지는 것이다.

 

05. Trade-Off

Trade-Off 라는 단어는 프로그래밍 세계 뿐만 아니라 현실세계에서도 자주 마주친다. 어떠한 행위에 있어서 항상 장점과 단점이 공존한다. 

 

치킨을 먹는다면 기분이 좋다는 장점이 있지만, 살이 찐다는 단점이 있다.

닭가슴살을 먹는다면 기분은 안좋겠지만, 살이 덜 찐다는 장점이 있다.

 

우리는 항상 Trade-Off 속에서 가장 현명한 답을 찾아간다.

 

이러한 Trade-Off 는 객체지향 설계에서도 피해갈 수 없었다.

 

나는 설계에 있어서 가장 우위에 있는 설계 비법이 존재할 것이라고 믿었지만 현실은 그렇지 않았다. 

 

설계의 방법은 다양하고, 제각각의 장단점을 가지고 있다. 

 

마지막 변경에서는 TicketOffice의 자율성을 높히는 대신, Audience와의 결합도가 증가했다. 다음의 구절이 인상깊었다.

 

어떤 설계에 있어서 기능설계하는 방법은 한가지 이상일 수 있고 모든 사람들을 만족시킬 수 있는
설계를 만들 수는 없다.
설계는 균형의 예술이다. 훌륭한 설계는 적절한 트레이드 오프의 결과물이다.
이러한 트레이드오프 과정이 설계를 어려우면서도 흥미진진한 작업으로 만드는 것이다.
- Object 33page -

 

06. 정리하자면

우리는 주어진 요구사항에 맞추어서 기능이 동작하도록 코드를 짜는 동시에 추가적인 요구사항에 쉽게 대처할 수 있는(변경이 용이한) 코드를 짜야한다. 요구사항은 항상 변화하고, 코드가 변경되면 오류의 위험에 노출되기 때문에 유연한 코드를 작성하는 것은 굉장히 중요하다.

 

07. 무엇을 배웠는가?

극장 예제를 통해 객체지향이란 무엇이고, 왜 필요한지에 대해 알게 되었다. 특히 객체의 역할 분리와, 결합도를 낮춘다는 것이 무엇인지 와닿았다. 

 

또한 코드를 작성할 때 잘 작동하는 것은 기본이고, 이후에 수정하기 용이한(동시에 이해하기 좋은) 코드를 작성하는 것을 항상 염두하고 프로그래밍을 해야겠다.

 

+ 그리고 책에서 코드들이 자주 나오는데 눈으로만 보는 것보단 실제로 작성해보는 것이 더 직관적으로 이해가 되었다. 코드를 개선해 나가면서 다음 개선점을 책을 보지 않고 미리 내가 시도해 보기도 하였는데 이해하는데 큰 도움이 되었다. 학습을 할 때 내가 귀찮을 수록 더 오래 기억에 남는것으로 알고있는데 그 예가 이것이 아닐까 싶다. 최대한 귀찮게 공부하자!

 

 

' > 오브젝트' 카테고리의 다른 글

[2][오브젝트] - 객체지향 프로그래밍  (0) 2022.02.08
[0][오브젝트] - 시작  (0) 2022.01.08