{"time":1752650121657,"blocks":[{"id":"lN8QrkU1oD","type":"warning","data":{"title":"해당 글은 조영호님의 쓰신 Object 책을 읽고 챕터별로 정리해본 글입니다. ","message":""}},{"id":"RKuJ5Stu-m","type":"customLink","data":{"url":"https://www.inflearn.com/course/%EC%98%A4%EB%B8%8C%EC%A0%9D%ED%8A%B8-%EA%B8%B0%EC%B4%88%ED%8E%B8-%EA%B0%9D%EC%B2%B4%EC%A7%80%ED%96%A5","title":"오브젝트 - 기초편 강의 | 조영호 - 인프런","description":"조영호 | , 객체지향 설계의 핵심을 담았다!이 강의는 제가 집필한 오브젝트라는 책을 기반으로 책임 주도 설계 방법에 따라 객체 사이의 협력을 설계하고 객체지향 언어를 사용해서 구현하는 방법을 설명합니다. 책임 주도 설계 방법은 객체에게 할당할 책임을 중심으로 애플리케이션","image":"https://cdn.inflearn.com/public/files/courses/334416/cover/01jv93tqa0rq8w2m6dyzmrr1xj"}},{"id":"xG1bBLEHPd","type":"delimiter","data":{}},{"id":"9JmyXIAp5P","type":"paragraph","data":{"text":"프로그래밍할 때 흔히 빠지기 쉬운 실수 중 하나는 데이터 구조에만 지나치게 집착하는 것이다. 그렇게 하면 결국 데이터베이스의 테이블 구조를 객체로 옮겨놓는 수준에 머물러, 변경에 취약한 설계가 된다. 이전 OLAP 시스템을 운영하면서, 방대한 SQL 로 개발하던 내게 있어서는, 특히 이번 장에서 터닝포인라 할만큼 매우 도움이 되었던 부분이었다. 이 장에서는 책임 중심 설계(Responsibility-Driven Design)의 관점에서 객체 설계를 어떻게 해야 하는지 다뤄본다."}},{"id":"bNBpRqc5PY","type":"delimiter","data":{}},{"id":"LU1bpAwE4R","type":"customHeader","data":{"text":"왜 책임 중심 설계인가?"}},{"id":"GJXXM7RTq4","type":"paragraph","data":{"text":"책임 중심 설계는 데이터가 아닌 객체의 '책임'을 중심으로 설계하는 방식이다. 이를 통해 객체의 캡슐화가 높아지고, 자연스럽게 응집도는 높아지고 결합도는 낮아진다. 따라서 소프트웨어 변경에 더 유연하고 유지보수가 쉬워진다. 데이터 중심의 설계에서 책임 중심의 설계로 전환하기 위해서는 다음의 2가지 원칙을 따라야 한다"}},{"id":"0Sv4i7x-lo","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"데이터 보다 행동을 먼저 결정하라","meta":{},"items":[]},{"content":"협력이라는 문맥 안에서 책임을 결정하라","meta":{},"items":[]}]}},{"id":"zevJW9UCfD","type":"paragraph","data":{"text":"뒤에서 자세히 살펴보겟지만, 두 원칙의 핵심은 설계를 진행하는 동안 데이터가 아니라 객체의 협력에 초점을 맞추라는 것이다. 하나씩 살펴보자"}},{"id":"vAeSSOb9py","type":"delimiter","data":{}},{"id":"t5EpscO0US","type":"header","data":{"text":"데이터보다 행동을 먼저 결정하라 ","level":3}},{"id":"gy01XlGGcx","type":"paragraph","data":{"text":"객체에게 중요한 것은 데이터가 아니라 외부에 제공하는 행동이다. 클라이언트의 관점에서 객체가 수행하는 행동이란 곧 객체의 책임을 의미한다. 객체는 협력에 참여하기 위해 존재하며 협력 안에서 수행하는 책임이 객체의 존재가치를 증명한다."}},{"id":"wsJpz1fGFZ","type":"paragraph","data":{"text":"데이터는 객체가 책임을 수행하는 데 필요한 재료를 제공할 뿐이다. 객체지향 초보자들이 흔히 저지르는 실수는 객체의 행동이 아니라 데이터에 초점을 맞추는 것이다. 너무 이른 시기에 데이터에 집중하면 객체의 캡슐화가 약화되어 낮은 응집도와 높은 결합도의 객체가 만들어진다. 결과적으로 변경에 취약한 설계를 초래한다."}},{"id":"6VHATG4Eez","type":"paragraph","data":{"text":"이를 극복하기 위해 객체 설계 시 질문 순서를 바꾸는 것이 좋다. 데이터 중심 설계에서는 \"이 객체가 포함해야 하는 데이터가 무엇인가\"를 먼저 고민한 후 \"데이터를 처리하는 데 필요한 오퍼레이션은 무엇인가\"를 생각한다. 반면 책임 중심 설계는 \"이 객체가 수행해야 하는 책임은 무엇인가\"를 먼저 결정하고, 그 책임 수행에 필요한 데이터를 결정한다."}},{"id":"uNQaoEwH45","type":"delimiter","data":{}},{"id":"QGWSQaN1e4","type":"header","data":{"text":"객체의 책임과 트레이드오프","level":3}},{"id":"xRA47RiOI8","type":"paragraph","data":{"text":"책임을 어떤 객체에 할당해야 하는지는 늘 고민이다. 정답은 없고, 항상 트레이드오프가 존재한다. 상황과 요구사항의 변화 가능성을 판단하여 책임을 할당해야 한다."}},{"id":"8YbieF13Ea","type":"delimiter","data":{}},{"id":"2zO_aefH3X","type":"header","data":{"text":"협력이라는 문맥 안에서 책임을 결정하라 ","level":3}},{"id":"RQLoJlA1UL","type":"paragraph","data":{"text":"객체에게 할당된 책임의 품질은 협력에 적합한 정도로 결정된다. 객체에게 할당된 책임이 협력에 어울리지 않는다면 그 책임은 나쁜 것이다. 객체의 입장에서는 책임이 조금 어색해 보이더라도 협력에 적합하다면 그 책임은 좋은것이다. 책임은 객체의 입장이 아니라 객체가 참여하는 협력에 적합해야 한다. "}},{"id":"UaSV36lyU_","type":"paragraph","data":{"text":"협력에 적합한 책임을 찾기 위해서는 메시지를 먼저 결정하고 이를 처리할 객체를 선택해야 한다. 메시지 송신자가 메시지 수신자를 결정하는 것이 아니라 메시지가 객체를 선택해야 한다. 이 접근법은 캡슐화를 자연스럽게 촉진하며 결과적으로 높은 응집도와 낮은 결합도를 갖게 되어 변경에 유연한 설계를 가능하게 한다."}},{"id":"w-DOYQRRek","type":"paragraph","data":{"text":"결론적으로 책임 중심의 설계에서는 협력이라는 문맥 안에서 객체가 수행할 책임에 초점을 맞춘다."}},{"id":"Lq7Vy9Syam","type":"delimiter","data":{}},{"id":"ltzyFTv7tH","type":"customHeader","data":{"text":"영화 예매 시스템 설계 요구사항"}},{"id":"axeE4tHeOx","type":"header","data":{"text":"요구사항 살펴보기","level":3}},{"id":"U-cDpLVC0G","type":"paragraph","data":{"text":"이번 장에서는 온라인 영화 예매 시스템을 소개한다. 이 시스템을 통해 사용자는 원하는 영화를 쉽고 빠르게 예매할 수 있다. 여기서 중요한 개념이 두 가지 있는데, 바로 '영화'와 ‘상영’이다."}},{"id":"QA4XyyfXxM","type":"paragraph","data":{"text":"‘영화’는 제목, 상영 시간, 가격 등의 기본 정보를 담고 있는 개념이고, ‘상영’은 관객이 실제로 극장에서 영화를 보는 이벤트를 의미한다. 예를 들어, 한 영화가 하루 동안 여러 시간대에 여러 번 상영될 수 있는데, 사용자가 예매하는 건 ‘영화’가 아니라 특정 시간에 상영되는 영화, 즉 '상영'이다."}},{"id":"3P-rZ_QGbi","type":"paragraph","data":{"text":"이 시스템에서는 특정 조건을 만족하는 예매자에게 할인을 제공하는데, 이를 위해 두 가지 할인 규칙이 존재한다. 첫째는 할인 조건(Discount Condition), 둘째는 할인 정책(Discount Policy)이다."}},{"id":"98h8mxqIbq","type":"paragraph","data":{"text":"할인 조건은 말 그대로 할인 여부를 판단하는 기준이다. 이 조건은 크게 두 가지로 나뉜다.\n하나는 ‘순서 조건’으로, 예를 들어 \"하루 중 10번째로 상영되는 영화\"처럼 상영 순서를 기준으로 할인 여부를 판단한다.\n다른 하나는 ‘기간 조건’으로, 특정 요일과 시간대에 상영되는 영화를 기준으로 할인 적용 여부를 결정한다. 예를 들어 \"매주 월요일 오전 10시부터 오후 1시 사이에 상영되는 영화\"는 이 조건에 해당된다."}},{"id":"PyuqpByeKC","type":"paragraph","data":{"text":"할인 여부가 결정되면, 얼마를 할인할지는 할인 정책에 따라 정해진다. 할인 정책에는 두 가지 종류가 있다.\n첫째는 금액 할인 정책으로, 예매 요금에서 고정 금액을 빼주는 방식이다. 예를 들어 영화 정가가 9,000원이고, 금액 할인 정책이 800원이면 실제 예매가는 8,200원이 된다.\n둘째는 비율 할인 정책으로, 정가의 일정 비율을 할인하는 방식이다. 같은 영화에 10% 비율 할인을 적용하면 900원이 할인돼 실제 예매가는 8,100원이 된다."}},{"id":"qgwiZAt8Jw","type":"paragraph","data":{"text":"한 가지 주의할 점은, 영화에는 오직 하나의 할인 정책만 적용할 수 있다. 하지만 할인 조건은 여러 개를 동시에 설정할 수 있고, 순서 조건과 기간 조건을 섞는 것도 가능하다. 또한 할인 정책 자체를 아예 적용하지 않는 것도 허용된다. 이 경우엔 영화의 정가가 곧 예매 가격이 된다."}},{"id":"Vc2r81Hfqg","type":"table","data":{"withHeadings":false,"stretched":false,"content":[["영화","할인 정책","할인 조건"],["아바타 (가격 10,000 원)","금액 할인 정책(할인액: 800 원)","순번 조건(조조 상영)"],["","","순번 조건(10회 상영)"],["","","기간 조건(월요일 10:00 ~ 12:00 사이)"],["","","기간 조건(목요일 18:00 ~ 21:00 사이)"],["타이타닉(가격: 11,000 원)","비율 할인정책(할인율: 10%)","기간 조건(화요일 14:00 ~ 17:00 사이)"],["","","순번 조건(2회 상영)"],["","","기간 조건(목요일 10:00 ~ 14:00 사이)"],["스타워즈: 꺠어난 포스(가격: 10,000 원)","없음","없음 "]]}},{"id":"m83cK6LcHM","type":"delimiter","data":{}},{"id":"5F38JqNMKv","type":"header","data":{"text":"도메인 개념에서 출발하기 ","level":3}},{"id":"5F1lW-o4FT","type":"paragraph","data":{"text":"설계를 시작하기전에 도메인에 대한 개략적인 모습을 그려 보는 것이 유용하다. 도메인 안에는 무수히 많은 개념들이 존재하며 이 도메인 개념들을 책임 할당의 대상으로 사용하면 코드에 도메인의 모습을 투영하기가 좀 더 수월해진다. 따라서 어떤 책임을 할당해야 할 때 가장 먼저 고민해야 하는 유력한 후보는 바로 도메인 개념이다. "}},{"id":"6SGtmF7H69","type":"paragraph","data":{"text":"아래 그림은 영화 예매 시스템을 구성하는 도메인 개념과 개념 사이의 관계를 대략적으로 표현한 것이다. 그림을 통해 영화는 여러 번 상영될 수 있으며, 하나의 상영은 여러번 예약될 수 있다는 사실을 알 수 있다. 또한 영화는 다수의 할인 조건을 가질 수 있으며 할인 조건에는 순번 조건과 기간 조건이 존재한다는 사실 역시 표현돼 있다. 할인 조건은 순번 조건과 기간 조건으로 분류되고 영화는 금액이나 비율에 따라 할인될 수 있지만 동시에 두 가지 할인 정책을 적용할 수 없다는 사실도 알 수 있다.

"}},{"id":"SX4DAlFgVF","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/영화_예매_시스템을_구성하는_도메인_개념.png"}}},{"id":"qgX465jHeC","type":"paragraph","data":{"text":"설계를 시작하는 단계에서는 개념들의 의미와 관계가 정확하거나 완벽할 피요가 없다. 단지 우리에게는 출발점이 필요할 뿐이다. 이 단계에서는 책임을 할당받을 객체들의 종류와 관계에 대한 유용한 정보를 제공할 수 있다면 충분하다. "}},{"id":"7VOMAJAUEW","type":"paragraph","data":{"text":"따라서 시작 시점에는 그림을 설계를 시작하기 위해 참고할 수 있는 개념들의 모음 정도로 간주하라. 중요한 것은 설계를 시작하는 것이지 도메인 개념들을 완벽하게 정리하는 것이 아니다. 도메인 개념을 정리하는 데 너무 많은 시간을 들이지 말고 빠르게 설계와 구현을 진행하라 ."}},{"id":"WKyLBDf9EI","type":"delimiter","data":{}},{"id":"e5WfjmjKE3","type":"customHeader","data":{"text":"정보 전문가에게 책임을 할당하라 "}},{"id":"QGX84yZ-TV","type":"paragraph","data":{"text":"책임 주도 설계 방식의 첫 단계는 애플리케이션이 제공해야 하는 기능을 애플리케이션의 책임으로 생각하는 것이다. 메시지를 결정한 후, 이 메시지를 처리할 적합한 객체를 선택한다. 객체에게 책임을 할당하는 원칙 중 가장 중요한 것은 정보를 가장 잘 아는 객체, 즉 정보 전문가 (INFORMATION EXPERT) 에 책임을 할당하는 것이다."}},{"id":"aLFcRoqSXO","type":"paragraph","data":{"text":"영화 예매 시스템 예를 들어보자. 사용자가 영화를 예매할 때 실제로는 '상영(Screening)'을 예매한다. 따라서 영화 예매의 책임은 Screening이 맡아야 한다. Screening은 가격 계산 등 특정 작업을 처리하기 위해 Movie에게 도움을 요청하고, Movie는 다시 할인 여부를 판단하기 위해 DiscountCondition에게 메시지를 전달한다. 이와 같은 방식으로 객체들이 협력하여 메시지를 처리하게 된다."}},{"id":"NvwoMorVvd","type":"paragraph","data":{"text":"정보 전문가 패턴은 객체가 정보를 직접 저장할 필요 없이, 정보를 제공하거나 계산할 수 있는 객체에게 책임을 할당하는 방식이다. 이를 통해 객체의 자율성과 협력 구조의 명확성을 확보할 수 있다."}},{"id":"JynbXVrTif","type":"delimiter","data":{}},{"id":"7C9FboCbyq","type":"header","data":{"text":"GRASP 패턴을 활용한 책임 할당","level":3}},{"id":"OQG6Txjb8z","type":"paragraph","data":{"text":"책임을 효과적으로 할당할 때 자주 활용되는 GRASP 패턴이 있다. 여기서는 몇 가지 주요 패턴을 적용해보자"}},{"id":"4BaqiMCeFp","type":"header","data":{"text":"Creator 패턴","level":3}},{"id":"p4pPSHfCuQ","type":"paragraph","data":{"text":"어떤 객체를 생성할 책임을 할당할 때 사용한다. 영화 예매 시스템에서는 'Screening'이 'Reservation'을 생성하는 책임을 갖는 것이 자연스럽다."}},{"id":"4HEVarmpFJ","type":"header","data":{"text":"Information Expert 패턴","level":3}},{"id":"zZAVYdopSv","type":"paragraph","data":{"text":"어떤 정보를 가장 잘 아는 객체가 책임을 맡도록 하는 패턴이다. 할인 조건을 판단하는 책임은 각 조건을 잘 아는 'DiscountCondition' 객체에 할당하면 자연스럽다."}},{"id":"qAuwFPLsUv","type":"header","data":{"text":"High Cohesion (높은 응집도)","level":3}},{"id":"UPlvdldAa3","type":"paragraph","data":{"text":"'요금 계산' 같은 책임을 하나의 객체('Movie') 안에 응집시킴으로써 설계의 복잡성을 줄이고 유지보수를 쉽게 만든다."}},{"id":"GIYhZuPQI8","type":"delimiter","data":{}},{"id":"3u-LLaBhFv","type":"customHeader","data":{"text":"구체적인 책임 할당 방법"}},{"id":"jyTarRJzHT","type":"paragraph","data":{"text":"사용자에게 제공할 주요 기능은 영화 예매다. 책임의 관점에서 보면 애플리케이션은 '영화를 예매할 책임'을 가진다. 이 책임 수행을 위한 명확한 메시지는 전송하는 객체의 의도를 반영해야 한다. "}},{"id":"Xp0w9cHluQ","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"메시지를 전송할 객체는 무엇을 원하는가? ","meta":{},"items":[]}]}},{"id":"fvZrOuRFo5","type":"paragraph","data":{"text":"협력을 시작하는 객체는 미정이지만, 목표는 명확하다. 즉, 영화를 예매하는 것이다. 따라서 메시지의 이름은 '예매하라'가 적합하다."}},{"id":"EFf_UBgD80","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/예매하라.png"}}},{"id":"P0tXzd7WpG","type":"paragraph","data":{"text":"메시지를 결정했으므로 메시지에 적합한 객체를 선택해야 한다. 두번째 질문은 다음과 같다"}},{"id":"3IgL26zzDk","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"메시지를 수신할 적합한 객체는 누구인가?","meta":{},"items":[]}]}},{"id":"JVPlSCCrnh","type":"paragraph","data":{"text":"이 질문에 답하기 위해서는 객체가 상태와 행동을 함께 캡슐화하는 자율적 단위라는 점에 주목해야 한다. 책임과 책임 수행에 필요한 상태는 반드시 동일 객체 안에 존재해야 한다. 따라서 책임을 할당하는 원칙은 책임 수행에 필요한 정보를 가장 잘 알고 있는 객체에게 책임을 맡기는 것이다. 이를 GRASP에서는 INFORMATION EXPERT(정보 전문가) 패턴이라 한다."}},{"id":"b_I6hs6MI8","type":"paragraph","data":{"text":"INFORMATION EXPERT 패턴은 객체가 자신이 가지고 있는 정보와 관련된 작업을 수행해야 한다는 직관을 표현한다. 여기서 중요한 점은 정보가 데이터를 반드시 저장해야 하는 것은 아니라는 것이다. 정보를 '알고' 있으면 충분하다. 정보는 직접 저장하거나, 다른 객체로부터 얻거나, 계산해서 제공할 수도 있다."}},{"id":"p9bMeXklHc","type":"paragraph","data":{"text":"이 패턴에 따라 영화 예매에 필요한 정보를 가장 잘 알고 있는 객체는 '상영(Screening)'이다. 상영은 영화 정보, 상영 시간, 상영 순번과 같이 영화 예매에 필수적인 다양한 정보를 가지고 있다. 따라서 상영 객체에게 '예매하라' 메시지를 처리할 책임을 할당하는 것이 적절하다."}},{"id":"94bZnTXZsa","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/예매하라2.png"}}},{"id":"JGh9jiB2tg","type":"paragraph","data":{"text":"예매하라 메시지를 수신했을 때 Screening 이 수행해야 하는 작업의 흐르을 생각해보자. 이제부터는 외부의 인터페이스가 아닌 Screening 의 내부로 들어가 메시지를 처리하기 위해 필요한 절차와 구현을 고민해보는 것이다. "}},{"id":"Gdd24YMc6W","type":"paragraph","data":{"text":"이제 '예매하라' 메시지를 받은 Screening 객체가 수행할 작업 흐름을 생각해보자. 이 단계에서는 Screening 객체 내부에서 메시지 처리에 필요한 절차를 개략적으로 구상한다. 세부 구현을 고민할 필요는 없고, 책임을 수행하는데 필요한 작업을 스스로 처리할 수 있는지 여부만 판단하면 된다."}},{"id":"Cqi0cR9038","type":"paragraph","data":{"text":"만약 Screening 객체가 스스로 처리할 수 없는 작업이 있다면 외부에 도움을 요청해야 한다. 이 요청은 새로운 메시지가 되어 외부 객체의 책임으로 전환된다. 이를 통해 협력 공동체가 구성된다."}},{"id":"-uxWPLaxVP","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/예매하라3.png"}}},{"id":"jc3j2PQydl","type":"paragraph","data":{"text":"이제 메시지를 책임질 객체를 선택한다. 기본 원칙은 정보 전문가에게 책임을 할당하는 것이다. 영화 가격을 계산하는데 필요한 정보를 알고 있는 전문가는 영화(Movie) 다. 따라서 INFORMATION EXPERT 패턴에 따라 메시지를 수신할 적당한 객체는 Movie 가 될 것이다. 이제 Movie 는 영화 가격을 계산할 책임을 지게 된다."}},{"id":"kGEFzu7p2C","type":"image","data":{"caption":"","withBorder":true,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/예매하라4.png"}}},{"id":"oZydxXniBl","type":"paragraph","data":{"text":"이제 '가격을 계산하라'는 메시지를 받은 Movie 객체가 처리할 작업을 생각해보자. Movie 객체는 요금을 계산하기 위해 먼저 영화가 할인 가능한지 여부를 판단한 뒤 할인 정책에 따라 할인된 금액을 계산해야 한다. 하지만 Movie 객체는 할인 조건을 스스로 판단할 수 없으므로 '할인 여부를 판단하라' 메시지를 외부에 전송하여 도움을 요청해야 한다."}},{"id":"dUUlM_oujH","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/예매하라5.png"}}},{"id":"qmetrBgyD0","type":"paragraph","data":{"text":"이제 이 메시지를 책임질 객체를 선택할 차례다. 할인 여부를 판단하는데 필요한 정보를 가장 많이 알고 있는 객체는 무엇인가? 이 정보에 대한 전문가는 바로 할인 조건 (DiscountCondition) 이다. DiscountCondition 에게 책임을 할당하자 "}},{"id":"RFhCZEU7zc","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/예매하라6.png"}}},{"id":"k6TBuGY79h","type":"paragraph","data":{"text":"DiscountCondition 은 자체적으로 할인 여부를 판단하는 데 필요한 정보를 알고 있기 때문에 외부의 도움 없이도 스스로 할인 여부를 판단할 수 있다. 따라서 DiscountCondition 은 외부에 메시지를 전송하지 않는다. "}},{"id":"_BdYVVz8Pd","type":"paragraph","data":{"text":"Movie 는 DiscountCondition 에 전송한 할인 여부를 판단하라 메시지의 결과로 할인 가능 여부를 반환받는다. DiscountCondition 중에서 할인 가능한 조건이 하나라도 존재하면 금액 할인 정책이나 비율 할인정책에 정해진 계산식에 따라 요금을 계산한 후 반환한다. 만약 할인 가능한 조건이 존재하지 않는다면 영화의 기본 금액을 반환한다. "}},{"id":"HTnfWo0KsR","type":"paragraph","data":{"text":"지금까지 살펴본 것처럼 INFORMATION EXPERT 패턴은 객체에게 책임을 할당할 때 가장 기본이 되는 책임 할당 원칙이다. INFORMATION EXPERT 패턴은 객체란 상태와 행동을 함께 가지는 단위라는 객체지향의 가장 기본적인 원리를 책임 할당의 관점에서 표현한다. INFORMATION EXPERT 패턴을 따르는 것만으로도 자율성이 높은 객체들로 구성된 협력 공동체를 구축할 가능성이 높아지는 것이다. "}},{"id":"QBSlr2f8ix","type":"delimiter","data":{}},{"id":"c5WQTR-gTy","type":"customHeader","data":{"text":"높은 응집도와 낮은 결합도 "}},{"id":"hJsD9rXoGU","type":"paragraph","data":{"text":"설계는 트레이드오프 활동이다. 같은 기능을 구현할 방법은 무수히 많으며, 실제 설계 과정에서는 그 중 하나를 선택해야 하는 경우가 자주 발생한다. 이때는 INFORMATION EXPERT뿐만 아니라 다른 책임 할당 패턴도 함께 고려해야 한다."}},{"id":"9WylpnMpQf","type":"paragraph","data":{"text":"예를 들어, 방금 전에 설계한 영화 예매 시스템에서는 할인 요금을 계산하기 위해 Movie 와 DiscountCondition 에 할인 여부를 판단하라 메시지를 전송한다. 그렇다면 이 설계의 대안으로 Movie 대신 Screening 이 직접 DiscountCondition과 협력하게 하는 것은 어떨까? 이를 위해서는 Screening 이 DiscountCondition 에게 할인여부를 판단하라 메시지를 전송하고 반환받은 할인 여부를 Movie 에 전송하는 메시지의 인자로 전달하도록 수정해야 한다. Movie 는 전달된 할인 여부 값을 이용해 기본 금액을 이용할지, 아니면 할인 정책에 따라 할인 요금을 계산할지를 결정할 것이다. "}},{"id":"Ul6WmHsg6U","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/예매하라7(1).png"}}},{"id":"5yd3t03Tjs","type":"paragraph","data":{"text":"위 설계는 기능적인 측면에서만 놓고 보면 Movie 와 DiscountCondition 이 적접 상호작용하는 앞의 설계와 동일하다. 차이점이라면 DiscountCondition 과 협력하는 객체가 Movie 가 아니라 Screening 이라는 것 뿐이다. 따라서 기능적인 측면에서는 두 가지 중 어떤 방법을 선택하더라도 차이가 없는 것처럼 보인다. 그렇다면 왜 우리는 이 설계 대신 Movie 가 DiscountCondition 과 협력하는 방법을 선택한 것일까? "}},{"id":"5YCKvLMWHi","type":"paragraph","data":{"text":"그 이유는 응집도와 결합도에 있다. 높은 응집도와 낮은 결합도는 객체에 책임을 할당할 때 항상 고려해야 하는 기본 원리다. 책임을 할당할 수 있는 다양한 대안들이 존재한다면 응집도와 결합도의 측면에서 더 나은 대안을 선택하는 것이 좋다. 다시 말해 두 협력 패던 중에서 높은 응집도와 낮은 결합도를 얻을 수 있는 설계가 있다면 그 설계를 선택해야한다는 것이다."}},{"id":"GYJ4US9xKG","type":"paragraph","data":{"text":"GRASP 에서는 이를 LOW COUPLING (낮은 결합도) 패턴과 HIGH COHESION (높은 응집도) 패턴이라고 부른다 "}},{"id":"ov73473O7P","type":"delimiter","data":{}},{"id":"QAelL4y_I5","type":"header","data":{"text":"LOW COUPLING (결합도) 관점 평가","level":3}},{"id":"ITZIAmfbYz","type":"paragraph","data":{"text":"DiscountCondition 이 Movie 와 협력하는 것이 좋을까, 아니면 Screening과 협력하는 것이 좋을까? 해답의 실마리는 결합도에 있다. 아래 그림을 다시보자. 도메인 상으로는 Movie 는 DiscountCondition 의 목록을 속성으로 포함하고 있다. Movie 와 DiscountCondition 은 이미 결합돼 있기 때문에 Movie 를 DiscountCondition 과 협력하게 하면 설계 전체적으로 결합도를 추가하지 않고도 협력을 완성할 수 있다. "}},{"id":"5gfQ30AQHj","type":"paragraph","data":{"text":"하지만 Screening 이 DiscountCondition 과 협력할 경우에는 Screening과 DiscountCondition 사이에 새로운 결합도가 추가된다. 따라서 LOW COUPLING 패턴의 관점에서는 Screening 이 DiscountCondition 과 협력하는 것보다는 Movie 가 DiscountCondition 과 협력하는 것이 더 나은 설계 대안인 것이다. "}},{"id":"8yVBWZJbxS","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":false,"file":{"url":"https://backend.owl-dev.me/images/image(1).png"}}},{"id":"SdmK_YtxDe","type":"delimiter","data":{}},{"id":"xdY7TWXgUi","type":"header","data":{"text":"HIGH COHESION (응집도) 관점 평가","level":3}},{"id":"Vrftu6lmb3","type":"paragraph","data":{"text":"Screening 의 가장 중요한 책임은 예매를 생성하는 것이다. 만약 Screening 이 DiscountCondition 과 협력 해야 한다면 Screening은 영화 요금 계산과 관련된 책임 일부를 떠안아야 할 것이다. 이 경우 Screening 은 DiscountCondition 이 할인 여부를 판단할 수 있고 Movie 가 이 할인 여부를 필요로 한다는 사실 역시 알고 있어야 한다. "}},{"id":"QZi45AlqOE","type":"paragraph","data":{"text":"다시 말해서 얘매 요금을 계산하는 방식이 변경될 경우 Screening 도 함께 변경해야 하는 것이다. 결과적으로 Screening 과 DiscountedCondition 이 협력하게 되면 Screening 은 서로 다른 이유로 변경되는 책임을 짊어지게 되므로 응집도가 낮아질 수 밖에 없다. "}},{"id":"hj9AEQQ5jP","type":"paragraph","data":{"text":"반면 Movie 의 주된 책임은 영화 요금을 계산하는 것이다. 따라서 영화 요금을 계산하는 데 필요한 할인 조건을 판단하기 위해 Movie가 DiscountCondition 과 협력하는 것은 응집도에 아무런 해도 끼치지 않는다. 따라서 HIGH COHESION 패턴의 관점에서 MOVIE 가 DiscountedCondition과 협력하는 것이 더 나은 설계이다. "}},{"id":"tHlezzzg0R","type":"paragraph","data":{"text":"LOW COUPLING 과 HIGH COHESION 패턴은 설계를 진행하면서 책임과 협력의 품질을 검토하는데 사용할 수 있는 중요한 평가 기준이다. 책임을 할당하고 코드를 작성하는 매순간마다 LOW COUPLING 과 HIGH COHESION 의 관점에서 전체적인 설계 품질을 검토하면 단순하면서도 재사용 가능하고 유연한 설계를 얻을 수 있을 것이다. "}},{"id":"Alvc_TnA95","type":"delimiter","data":{}},{"id":"0C-t_9QMcx","type":"customHeader","data":{"text":"창조자에게 객체 생성 책임을 할당하라"}},{"id":"ps-MYNA3xg","type":"paragraph","data":{"text":"영화 예매 협력의 최종 결과물은 Reservation 인스턴스를 생성하는 것이다. 이것은 협력에 참여하는 어떤 객체에게는 Reservation 인스턴스를 생성할 책임을 할당해야 한다는 것을 의미한다. GRASP 의 CREATOR(창조자) 패턴은 이 같은 경우에 사용할 수 있는 책임 할당 패던으로서 객체를 생성할 책임을 어떤 객체에게 할당할지에 대한 지침을 제공한다. "}},{"id":"0_iaWbWbHK","type":"paragraph","data":{"text":"Reservation 을 잘 알고 있거나, 긴밀하게 사용하거나, 초기화에 필요한 데이터를 가지고 있는 개체는 무엇인가? 바로 Screening 이다. Screening 은 예매 정보를 생성하는 데 필요한 영화, 상영 시간, 상영 순번 등의 정보에 대한 전문가이며, 예매 요금을 계산하는데 필수적인 Movie 도 알고 있다. 따라서 Screening 을 Reservation 의 CREATOR 로 선택하는 것이 적절해 보인다. "}},{"id":"PvC_89lzwa","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/예매하라8.png"}}},{"id":"QibFWMPj_H","type":"paragraph","data":{"text":"대략적으로나마 영화 얘메에 필요한 책임을 객체들에게 할당했다. 현재까지의 책임 분배는 설계를 시작하기 위한 스케치에 불과하다. 실제 설계는 코드를 작성하는 동안 이뤄진다. 그리고 협력과 책임이 제대로 동작하는지 확인할 수 있는 유일한 방법은 코드를 작서앟고 실행해 보는 것 뿐이다. 올바르게 설계하고 있는지 궁금한가? 코드를 작성하라"}}],"version":"2.31.0-rc.7"}

Tag List