0. 개요
이 글은 오브젝트(조영호 저)의 1장의 내용과 그 내용을 읽고 든 내 생각을 정리한 글이다.
오브젝트의 1장은 '극장과 티켓 판매' 라는 간단한 코드 예시를 통해 객체지향 프로그래밍이 무엇인지, 그리고 왜 필요한지에 대해 설명한다.
그리고 1장에 들어가기 전에 '패러다임' 이라는 개념을 통해 객체지향을 공부해야 하는 또 다른 이유를 설명한다.
이제 자세한 내용을 살펴보자.
1. 패러다임
우리는 왜 객체지향에 대해 공부해야 하는 걸까??
객체지향 패러다임이라는 말이 무슨 뜻인지, 그리고 어떻게 생겨난 것인지 찾아보면 그 이유를 알 수 있다.
프로그래밍 패러다임이라는 용어를 처음 사용한 로버트 플로이드(Robert W. Floyd)가 정의한 프로그래밍 패러다임은 이렇다.
프로그래밍 패러다임은 특정 시대의 어느 성숙한 개발자 공동체에 의해 수용된 프로그래밍 방법과 문제 해결 방법, 프로그래밍 스타일이라고 할 수 있다.
즉, 어떤 프로그래밍 패러다임을 사용하느냐에 따라 우리가 해결할 문제를 바라보는 방식과 프로그램을 작성하는 방법이 달라진다.
프로그래밍 패러다임은 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 함으로써 불필요한 부분에 대한 의견 충돌을 방지한다. 또한 프로그래밍 패러다임을 교육시킴으로써 동일한 규칙과 방법을 공유하는 개발자로 성장할 수 있도록 준비시킬 수 있다.
그렇기에 우리가 다른 사람들과 소통할 수 있는 개발자가 되고자 한다면 프로그래밍 패러다임을 익혀야 하는 것이다. 그리고 현재 대세인 프로그래밍 패러다임은 객체지향 패러다임이다.
하지만 그렇다고 객체지향 패러다임이 완벽하다는 것은 아니다.
초기의 프로그래밍 패러다임은 절차형 패러다임이었다. 시간이 지나며 절차형 패러다임의 단점을 보완하며 객체지향 패러다임이 대세가 되었고, 최근에는 객체지향 패러다임을 보완한 관점지향 패러다임이 조금씩 거론되고 있다.
이처럼 프로그래밍 패러다임은 기존의 패러다임의 단점을 보완하며 점점 발전해나가고 있다. 그렇기에 객체지향 패러다임을 익히되, 객체지향이 적합하지 않은 상황에서는 언제라도 다른 패러다임을 적용할 수 있도록 준비하고 있어야 한다.
2. 객체지향에서의 객체
이 책의 1장에서는 '극장과 티켓 판매' 라는 간단한 코드 예시를 통해 객체지향에 대해 설명한다.
이 예시에서 객체는 Theater, TicketSeller, Audience, TicketOffice, Bag, Ticket, Invitation 이렇게 총 7가지가 존재한다.
객체지향에서는 우리의 직관에 따라 객체들이 자율성을 가지고 스스로 자신을 책임져야 한다고 한다. 그런데 뭔가 이상하다. 현실에선 사람인 TicketSeller, Audience 말고는 모두 자율성을 가질 수 없다. 그럼 우리의 직관에 어긋나는게 아닌가?
하지만 객체지향 세계에서는 모든 객체를 '의인화'해서 생각한다. 이 차이를 이해해야 객체지향에서 각 객체가 자기 스스로를 책임져야 한다는 걸 이해할 수 있다.
3. 왜 객체지향적으로 만드는가?
로버트 마틴은 <클린 소프트웨어: 애자일 원칙과 패턴, 그리고 실천 방법> 에서 소프트웨어 모듈이 가져야 하는 세 가지 기능에 관해 설명한다. 모듈은 제대로 실행돼야 하고, 변경이 용이해야 하며, 이해하기 쉬워야 한다.
객체지향적으로 설계할 때의 장점은 여러 가지가 있다. 그 중 이 책의 1장에서 나온 이유는 '변경에 유연하게 대응할 수 있다' 이다. 객체지향 설계는 위에서 언급한 모듈이 가져야 할 조건 중 두 번째와 세 번째를 만족하기 쉽도록 만들어준다.
객체지향적으로 설계하면 각 객체들이 자신의 역할을 하기 때문에 다른 설계에 비해 코드를 이해하기 쉽다. 또한 각 객체가 스스로를 책임지기 때문에 변경 사항이 생겨도 웬만해선 해당 일을 책임지는 객체만 수정하면 된다.
이것이 객체지향적으로 설계를 하는 이유이다.
4. 완벽한 정답은 없다
'극장과 티켓 판매' 예시를 수정하면서 트레이드오프에 관한 이야기가 나온다.
어떤 기능을 설계하는 방법은 한 가지 이상일 수 있다. 그리고 동일한 기능을 한 가지 이상의 방법으로 설계할 수 있기 때문에 결국 설계는 트레이드오프의 산물이다. 어떤 경우에도 모든 사람들을 만족시킬 수 있는 설계를 만들 수는 없다.
저자는 설계를 균형의 예술이라 표현한다.
전적으로 동의한다. 그리고 실무에 들어가면 그 균형에는 단순히 개발과 관련된 내용 뿐 아니라 회사의 운영과 관련된 다양한 요소들이 섞이게 된다. 비용, 시간, 인력 등 말 그대로 현실과 타협해야 하는 순간들이 계속 생길 것이다. 어쩌면 눈물을 머금고 개발 부채가 생기는 걸 지켜봐야 할 수도 있다. 그런 상황에서 적절한 결정을 내리는 것이 좋은 개발자, 좋은 리더의 자질이 아닐까 생각이 든다.