객체지향 프로그래밍

핵심 내용 및 느낀점

소프트웨어 모듈이 가져야 하는 세 가지 기능

1. 실행 중에 제대로 동작하는 것 (-> 당연한 거임.)
2. 변경을 위해 존재하는 것 (-> 기능이 추가되거나 버그 발생 시 수정해야 함.)
3. 코드를 읽는 사람과 의사소통 하는 것 (-> 퇴사자의 코드도 우린 읽어야 함.)

왜

취업을 하고, 실무를 위해 많은 도메인을 접하면서 2번과 3번의 중요성을 정말 많이 깨달았다.
대부분의 기업에서는 이미 운영하는 서비스가 있기 때문에, 이에 대한 운영 업무 처리와 새 프로젝트 이렇게 병행해서 진행하곤 한다.

내가 현재 다니고 있는 회사도 규모가 꽤 있으므로, 레거시 코드를 자바로 변환하는 팀이라던지, 아예 새로운 기능을 개발하는 팀이라든지, 인프라를 바꾸는 팀이라던지, 운영 업무를 담당하는 팀이라던지 다양하게 존재한다.

다양한 팀들이 공통된 함수를 건드려야하는 상황이 발생한다. 이는 다른 말로 하면, 우리 팀 외에 누가 이 코드를 건드리고 있는 지 모른다는 뜻이다. 이는 코드 변경이나 삭제에 훨씬 더 주의를 기울이게 된다. 괜히 잘못 수정했다가 운영 건에서 오류가 발생할 수도 있다. 그리고 당장은 나오지 않더라도 다양한 예외 상황이나 문제 상황이 발생할 수 있다. (오늘도 발견함...ㅎ 사수님과 나...그리고 다른 팀 사람들도 다들 이 예외 상황에 당황하는 중)

또한, 개발자는 이직이 잦은 직무로, 코드를 작성했던 사람이 퇴사자인 경우도 종종 있다. 코드를 왜 이렇게 작성했는 지 질문하기 전에 주석과도 같은 보조 장치가 있어, 다른 사람이 나의 코드를 읽기 쉽게 도와주는 것은 필수적이다.

정리

1) 객체는 수동적인 존재로 있으면 안된다. 객체의 자율성을 높여라!

2) 객체 사이의 의존성 (결합도)를 낮춰라! 어떻게? 로직을 옮기자. 하나의 클래스에서 다른 클래스들에서 사용하는 메서드 이것저것 다 불러오지 말자!

의존성 0으로 가는 것은 불가능하다. 어느 정도의 트레이드 오프를 생각하자.
그러면, 변경에 용이한 코드가 된다.

영화 예매 시스템 구현하기

소스코드

https://github.com/eternity-oop/object/tree/master/chapter02

상황 분석

사용자는 온라인 영화 예매 시스템을 이용해 쉽고 빠르게 보고 싶은 영화를 예매할 수 있다. 영화의 제목, 상영시간, 가격 정보와 같이 기본적인 정보를 가르킬 때는 '영화'라는 단어를 사용한다. '상영'은 실제로 관객들이 영화를 관람하는 사건을 표현하며, 상영일자, 시간, 순번 등을 위해 사용한다.
특정한 조건을 만족하는 예매자는 요금을 할인받을 수 있다. 할인액을 결정하는 두 가지 규칙이 존재한다. 하나는 할인 조건(discount condition)이고, 다른 하나는 할인 정책(discount policy)이라고 부른다.

첫번째 도전

관람객과 판매원이 소극장의 통제를 받는 수동적인 존재로 묘사된다.

관람객이 현금과 초대장을 보관하기 위해 항상 가방을 가지고 다닌다? 가방 안 가지고 온다면?
판매원이 매표소에서만 티켓을 판매한다고 가정한다? 인터넷으로 예매한다면?

이처럼 예외 상황이 발생했을 때, 한 가지 클래스만 바꾸는 것이 아니라, 이 클래스에 의존하는 다른 클래스들도 바꿔야한다면?

이것이 바로 의존성(dependency)! 객체 사이에는 최소한의 의존성만 유지하고 불필요한 의존성은 줄이는 것이 좋다.

따라서, 객체 사이의 결합도를 낮춰 변경이 용이한 설계를 만드는 것이 중요하다.

두번째 도전

첫번째 도전에 비해서 객체의 자율성을 높이고, 의존도를 낮췄다.

개념적으로/물리적으로 객체 내부의 세부적인 사항을 감춰(캡슐화), 객체 간의 결합도를 낮춘다. 이는 결과적으로 변경하기 쉬운 객체를 만들어준다.

또한, 객체를 인터페이스와 구현으로 나누어, 객체 사이의 결합도를 낮추고 변경하기 쉬운 코드를 만든다.

세번째 도전

두번째 도전도 나쁘진 않았으나, 책임을 이동시킴으로써, 더 나은 모습을 보인다.
위는 절차적 프로그래밍의 예시이고, 아래는 책임이 분산된 객체지향 프로그래밍이다.

절차 지향적 프로그래밍과는 다르게 객체 지향 프로그래밍은 각 객체로 책임이 이동한다.

네번째 도전?

같은 기능도 다양한 방식으로 구현할 수 있다. 하지만, 위의 예시처럼 객체의 자율성을 높이고 객체 간의 결합도를 낮추는 데는 한계가 있다. 우리는 이 한계를 잘 파악하고, 어느정도 선에서 설계를 마무리해야할 것이다.

설계는 균형의 예술이다.
훌륭한 설계는 적절한 트레이드오프의 결과물이라는 사실을 명심하라.