[오브젝트 1장] - 프로그래밍 패러다임

[오브젝트 1장] - 프로그래밍 패러다임

 

 

 패러다임의 시대

 

현대의 패러다임은 '한 시대의 사회 전체가 공유하는 이론이나 방법, 문제의식 등의 체계'를 의미. 우주를 바라보는 관점이 천동설에서 지동설로 변화한 사건이 예시. 이 책에서 이야기하는 패러다임은 절차형 패러다임 -> 객체지향 패러다임으로의 변화를 가리킴.

 

 

 

 프로그래밍 패러다임

 

어떤 프로그래밍 패러다임을 사용하느냐에 따라 우리가 해결할 문제를 바라보는 방식과 프로그램을 작성하는 방법이 달라진다. 

 

프로그래밍 패러다임은 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 함으로써 불필요한 부분에 대한 의견 충돌을 방지한다.

 

프로그래밍에서 패러다임은 서로 다른 패러다임이 하나의 언어 안에서 공존함으로써 서로의 장단점을 보완한다. 

 

 

 

 객체, 설계

 

설계에 관해 설명할 때 가장 유용한 도구는 이론으로 덕지덕지 치장된 개념과 용어가 아니라 '코드' 그 자체다. 추상적인 개념과 이론은 훌륭한 코드를 작성하는 데 필요한 도구일 뿐이다.

 

개발자는 구체적인 코드를 만지며 손을 더럽힐 때 가장 많은 것을 얻어가는 존재다.

 

즉 이론보다는 실무다.

 

 

 

 티켓 판매 애플리케이션 구현하기

 

소극장을 구현하는 클래스는 Theather다. 

 

public class Theather {
    private TicketSeller ticketSeller;
    
    public Theather(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는 Audience가 Bag을 가지고 있고, Bag에는 티켓이 있는 이러한 사항들은 클라이언트를 더욱 복잡하게 만든다. 

 

마지막으로 제일 큰 문제는 변경에 취약하다는 것이다. 

만약 관람객이 가방이 아닌 다른 곳에 티켓을 보관했다면? 관람객이 현금이 아닌 신용카드를 이용한다면? enter메서드를 전부 변경해야 하는 문제가 생긴다. 

다른 객체를 변경했을 때 그와 연결되어 있는 객체를 변경해야 한다면 이것은 '의존성'과 관련된 문제가 있는 것이다.  

 

목표는 최소한의 의존성만 유지하고 불필요한 의존성을 제거하는 것이다. 

 

객체 사이의 의존성이 과한 경우를 '결합도'가 높다고 말한다. 객체 사이의 결합도를 낮추는 것이 핵심이다. 

 

 

 설계 개선하기

 

TicketOffice에 대한 접근을 Theather에서 하지 않고 TicketSeller 안에만 존재하게 한다. 이렇게 함으로써 TicketSeller는 티켓을 꺼내거나 판매 요금을 적립하는 요금을 처리하는 '자율적인 존재'가 된다. 

 

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

 

이렇게 다른 객체들도 자율적으로 처리할 수 있도록 구현을 숨기고 퍼블릭 인터페이스만 드러내어 객체들끼리 소통하도록 만들어 준다. 이를통해 다른 객체가 내부 구현을 변경하더라도 이와 소통하고 있는 객체들은 변경할 필요가 없도록 만들게 된다.

 

밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임하는 객체를 가리켜 '응집도가 높다'고 말한다. 

객체의 응집도를 높이기 위해서는 객체 스스로 자신의 데이터를 책임져야 한다. 자신이 소유하고 있지 않은 데이터를 이용해 작업을 처리하는 객체에게 어떻게 연관성 높은 작업들을 할당할 수 있겠는가? 

 

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

 

 

 

 절차지향과 객체지향

 

프로세스: enter

데이터: Audience, Bag, TicketSeller

 

프로세스의 데이터를 별도의 모듈에 위치시키는 방식을 '절차적 프로그래밍'이라고 한다.

 

절차적 프로그래밍의 세계에서는 관람객과 판매원이 수동적인 존재. -> 데이터 변경으로 인한 영향을 지역적으로 고립시키기 어려워짐. 

 

변경하기 쉬운 설계는 한 번에 하나의 클래스만 변경할 수 있는 설계다. 절차적 프로그래밍은 프로세스가 필요한 모든 데이터에 의존해야 한다는 근본적인 문제점 때문에 변경에 취약하다. 

 

이를 해결하기 위해서는 프로세스와 데이터를 동일한 모듈에 놓아야 한다. 이를 '객체지향 프로그래밍'이라고 부른다. 

 

하지만 자율성을 부여하기 위한 프로그래밍을 하다보면 새로운 의존성이 추가될 수도 있다. 이는 트레이드오프 시점이 온 것이다. 이럴 때는 상황에 따라서 객체 간 결합도를 높이는 대신 자율성을 낮출 수도 있고, 그 반대가 될 수도 있다. 어떤 경우에도 모든 사람을 만족시킬 설계는 만들 수 없다. 

설계는 균형의 예술이다. 훌륭한 설계는 적절한 트레이드오프의 결과물이다. 

 

재밌는 사실은 Bag과 TicketOffice는 실제에서는 자율적인 존재가 아니라는 것이다. 그럼에도 이들을 자율적인 존재로 취급하고 객체를 설계해야 한다. 실세계의 생명력이 없는 존재라고 하더라도 객체지향 셰게로 오면 생명과 지능을 가진 싱싱한 존재로 다시 태어나는 것이다. 

 

한 편의 애니메이션을 만든다고 생각해보자. 다른 사람의 코드를 읽고 이해하는 동안에는 애니메이션을 보고 있다고 생각해보자. 그럼 코드 치는게 더 즐거워 진다.

 

 

 

 객체지향 설계

 

설계란 코드를 배치하는 것이다.

 

좋은 설계는 오늘 완성해야 하는 기능을 구현하는 코드를 짜야 하는 동시에 내일 쉽게 변경할 수 있도록 짜야 한다. 왜냐하면 요구사항은 항상 변경되고, 버그가 추가될 가능성이 높기 때문이다. 코드를 수정하지 않으면 버그가 일어나지 않지만 수정은 불가피하다. 이러한 불가피함을 회피하려는 이유는 두려움 때문이다. 이 두려움은 요구사항 변경으로 인해 버그를 추가할 지 모른다는 불확실성에 기인한다. 

 

1장을 요약하면

훌륭한 객체지향 설계란 협력하는 객체 사이의 의존성을 적절하게 관리하는 설계다. 캡슐화와 퍼블릭 인터페이스를 통해 구현 사항을 감추고 변경의 두려움을 없애든, 데이터와 프로세스를 동일 모듈에 위치하여 자율적인 객체를 만들든 이들이 적절하게 협력하며 애니메이션을 구축하면 훌륭한 객체지향 설계가 된다.