{"time":1752650136632,"blocks":[{"id":"g_82OzqRjo","type":"warning","data":{"title":"해당 글은 조영호님의 쓰신 Object 책을 읽고 챕터별로 정리해본 글입니다. ","message":""}},{"id":"9PjQ073oCt","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":"KA9n9oFpzL","type":"delimiter","data":{}},{"id":"NwtVf2AWqZ","type":"paragraph","data":{"text":"좋은 인터페이스는 '최소한의 인터페이스' 와 '추상적인 인터페이스' 라는 조건을 만족해야한다. 최소한의 인터페이스는 꼭 필요한 오퍼레이션만을 인터페이스에 포함한다. 추상적인 인터페이스는 어떻게 수행하는지가 아니라 무엇을 하는지를 표현한다."}},{"id":"8bhdhdymEU","type":"paragraph","data":{"text":"최소주의를 따르면서도 추상적인 인터페이스를 설계할 수 있는 가장 좋은 방법은 책임 주도 설계 방법을 따르는 것이다. 책임 주도 설계 방법은 메시지를 먼저 선택함으로써 협력과는 무관한 오퍼레이션이 인터페이스에 스며드는 것을 방지한다. "}},{"id":"faoVoZCnnZ","type":"warning","data":{"title":"따라서 인터페이스는 최소의 오퍼레이션만을 포함하게 된다. 또한 객체가 메시지를 선택하는 것이 아니라, 메시지가 객체를 선택하게 함으로써 클라이언트의 의도를 메시지에 표현할 수 잇게 한다. 따라서 추상적인 오퍼레이션이 인터페이스에 자연스럽게 스며들게 된다.","message":""}},{"id":"8SzKe-srV6","type":"delimiter","data":{}},{"id":"zGtXGp_0GE","type":"paragraph","data":{"text":"퍼블릭 인터페이스의 품질에 영향을 미치는 원칙, 기법"}},{"id":"ISYLJu7T64","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"디미터 법칙","meta":{},"items":[]},{"content":"묻지 말고 시켜라","meta":{},"items":[]},{"content":"의도를 드러내는 인터페이스","meta":{},"items":[]},{"content":"명령-쿼리 분리","meta":{},"items":[]}]}},{"id":"SkgSwP4F2H","type":"delimiter","data":{}},{"id":"65dx4bZNBM","type":"customHeader","data":{"text":"디미터 법칙 (Raw of Demeter)"}},{"id":"yOsauVGttW","type":"paragraph","data":{"text":"아래 코드는 이전 4장에서 살펴본 절차적인 방식의 영화 예매 시스템 코드 중에서 할인 가능 여부를 체크하는 코드를 가져온것이다."}},{"id":"5naWxHmMP0","type":"code","data":{"code":"public class ReservationAgency {\n public Reservation reserve(Screening screening, Customer customer, int audienceCount) {\n Movie movie = screening.getMovie();\n\n boolean discountable = false;\n for (DiscountCondition condition : movie.getDiscountConditions()) {\n if (condition.getType() == DiscountConditionType.PERIOD) {\n discountable = screening.getWhenScreened().getDayOfWeek().equals(condition.getDayOfWeek()) &&\n condition.getStartTime().compareTo(screening.getWhenScreened().toLocalTime()) <= 0 &&\n condition.getEndTime().compareTo(screening.getWhenScreened().toLocalTime()) >= 0;\n } else {\n discountable = condition.getSequence() == screening.getSequence();\n }\n if (discountable) {\n break;\n }\n }\n // ...\n }\n}"}},{"id":"DrhPt00Gny","type":"paragraph","data":{"text":"이 코드의 가장 큰 단점은 ReservationAgency 의 인자로 전달된 Screening 사이의 결합도가 너무 높기 때문에 Screening 의 내부 구현을 변경할 때마다 ReservationAgency 도 함께 변경된다는 것이다. "}},{"id":"Ap8gVDbs1l","type":"paragraph","data":{"text":"문제의 원인은 ReservationAgency 가 Screening 뿐만 아니라 Movie 와 DiscountCondition 에도 직접 접근하기 때문이다. "}},{"id":"Gokq5rO941","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/image(2).png"}}},{"id":"MxVF60OXQ4","type":"paragraph","data":{"text":"만약 Screening 이 Movie 에 포함되지 않도록 변경되거나, Movie 가 DiscountCondition 을 포함하지 않도록 변경된다면 어떻게 될까? "}},{"id":"IIrbelPVv9","type":"paragraph","data":{"text":"DiscountCondition 이 내부에 sequence 를 포함하지 않게 된다면 어떤 영향이 있을 것인가? 만약 sequence 의 타입이 int 가 아니라 sequence 라는 이름의 클래스로 변경된다면? ReservationAgency 는 사소한 변경에도 이리저리 흔들리는 의존성의 집결지다. "}},{"id":"XPTNjIRocw","type":"paragraph","data":{"text":"이처럼 협력하는 객체의 내부 구조에 대한 결합으로 인해 발생하는 설계 문제를 해결하기 위해 제안된 원칙이 바로 디미터 법칙 (Law of Demeter) 이다."}},{"id":"5ef9dqtw_8","type":"paragraph","data":{"text":"디미터 법칙을 간단하게 요약하면 객체의 내부 구조에 강하게 결합되지 않도록 협력 경로를 제한하라는 것이다. Java 나 C# 같이 '.' 를 사용해서 메시지 전송을 표현하는 언어에서는 \"오직 하나의 도트만 사용하라\" 라는 말로 요약되기도 한다."}},{"id":"HHDBuwAAaA","type":"paragraph","data":{"text":"클래스 내부의 메서드가 아래 조건을 만족하는 인스턴스에만 메시지를 전송하도록 프로그래밍해야 한다라고 이해해도 무방하다. "}},{"id":"n3bhYuNcse","type":"delimiter","data":{}},{"id":"j_DXg1Prd7","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"this 객체","meta":{},"items":[]},{"content":"this 의 속성","meta":{},"items":[]},{"content":"this 의 속성인 컬렉션 요소","meta":{},"items":[]},{"content":"메서드의 매개변수","meta":{},"items":[]},{"content":"매서드 내에서 생성된 지역 객체 ","meta":{},"items":[]}]}},{"id":"Gu0La6gI4a","type":"delimiter","data":{}},{"id":"yQw0ZNeaD6","type":"paragraph","data":{"text":"4장에서 결합도 문제를 해결하기 위해 수정한 ReservationAgency 의 최종코드를 보자"}},{"id":"9TSLSxeVYC","type":"code","data":{"code":"public class ReservationAgency {\n\tpublic Reservation reserve(Screening screening, Customer customer, int audienceCount){\n\t\tMoney fee = screening.calculateFee(audienceCount);\n\n\t\treturn new Reservation(customer, screening , fee, audienceCount);\n\t}\n}"}},{"id":"cA-04g59GB","type":"paragraph","data":{"text":"이 코드에서 ReservationAgency 는 메서드의 인자도 전달된 Screening 인스턴스에게만 메시지를 전송한다. ReservationAgency는 Screening 내부에 대한 어떤 정보도 알지 못한다."}},{"id":"foa1kmeozS","type":"paragraph","data":{"text":"ReservationAgency 가 Screening 의 내부 구조에 결합돼 있지 않기 때문에 Screening의 내부 구현을 변경할 때 ReservationAgency 를 함께 변경할 필요가 없다."}},{"id":"cqJTlmkZiq","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/image(3).png"}}},{"id":"xyi9bM37v0","type":"paragraph","data":{"text":"디미터 법칙을 위반하는 코드의 전형적인 모습 "}},{"id":"BYdY5C_srN","type":"code","data":{"code":"screening.getMovie().getDiscountConditions()"}},{"id":"vxW3Bj6tC5","type":"paragraph","data":{"text":"메시지 전송자가 수신자의 내부 구조에 대해 물어보고 반환받은 요소에 대해 연쇄적으로 메시지를 전송한다. 흔히 이와 같은 코드를 기차 충돌 (train wreck) 이라고 부르는데 여러 대의 기차가 한 줄로 늘어서 충돌한 것처럼 보이기 때문이다. "}},{"id":"D1ONBMlGNR","type":"paragraph","data":{"text":"기차충돌은 클래스의 내부 구현이 외부로 노출됐을 때 나타나는 전형적인 형태 "}},{"id":"m3nh4THJrC","type":"code","data":{"code":"screening.calculateFee(audienceCount)"}},{"id":"g0stBoYnMo","type":"paragraph","data":{"text":"디미터의 법칙은 객체의 내부 구조를 묻는 메시지가 아니라 수신자에게 무언가를 시키는 메시지가 더 좋은 메시지다. "}},{"id":"0ZvX_jikea","type":"delimiter","data":{}},{"id":"fVZu2rnydS","type":"customHeader","data":{"text":"묻지 말고 시켜라 (Tell, Don't ask)"}},{"id":"hnGofHfxmv","type":"paragraph","data":{"text":"앞에서 ReservationAgency 는 Screening 내부의 Movie 에 접근하는 대신, Screening 에게 직접 요금을 계산하도록 요청했다. 요금을 계산하는데 필요한 정보를 잘 알고 있는 Screening 에 요금을 계산할 책임을 할당한 것이다 ."}},{"id":"iEPVs9lHCc","type":"paragraph","data":{"text":"디미터 법칙은, 훌륭한 메시지는 객체의 상태에 관해 묻지 말고 원하는 것을 시켜야 한다는 사실을 강조한다. "}},{"id":"ybavaYfvGh","type":"paragraph","data":{"text":"메시지 전송자는 메시지 수신자의 상태를 기반으로 결정을 내린 후 메시지 수신자의 상태를 바꿔서는 안된다. "}},{"id":"wlZX-aCfm0","type":"paragraph","data":{"text":"여러분이 구현하고 있는 로직은 메시지 수신자가 담당해야 할 책임일 것이다. 객체의 외부에서 해당 객체의 상태를 기반으로 결정을 내리는 것은 객체의 캡슐화를 위반한다."}},{"id":"IcUN66xc5e","type":"warning","data":{"title":"절차적인 코드는 정보를 얻은 후에 결정한다. 객체지향 코드는 객체에게 그것을 하도록 시킨다. ","message":""}},{"id":"KHfq2CHjib","type":"paragraph","data":{"text":"객체지향의 기본은 함께 변경될 확률이 높은 정보와 행동을 하나의 단위로 통합하는 것이다. 묻지 말고 시켜라 원칙을 따르면 객체의 정보를 이용하는 행동을 객체의 외부가 아닌 내부에 위치시키기 때문에 자연스럽게 정보와 행동을 동일한 클래스 안에 두게 된다."}},{"id":"grY1DJ184R","type":"paragraph","data":{"text":"묻지 말고 시켜라 원칙에 따르도록 메시지를 결정하다 보면 자연스럽게 정보 전문가에게 책임을 할당하게 되고 높은 응집도를 가진 클래스를 얻을 확률이 높아진다. "}},{"id":"6aWJIkWxrh","type":"delimiter","data":{}},{"id":"3eP15POd8j","type":"customHeader","data":{"text":"의도를 드러내는 인터페이스"}},{"id":"JB403Q67Dx","type":"paragraph","data":{"text":"켄트백엔 그의 기념비적인 책인 smalltalk Best Practice Patterns 에서 메서드를 명명하는 2가지 방법을 설명했다."}},{"id":"0VBCE-YrmG","type":"paragraph","data":{"text":"첫 번째 방법은 '메서드가 작업을 어떻게 수행하는지를 나타내도록 이름을 짓는 것' 이다. 이 경우 메서드의 이름은 내부의 구현 방법을 드러낸다."}},{"id":"C6Fl_Nfyvs","type":"code","data":{"code":"public class PeriodCondition {\n\tpublic boolean isSatisfiedByPeriod(Screening screening) {...}\n}\n\npublic class SequenceCondition {\n\tpublic boolean isSatisfiedBySequence(Screening screening) {...}\n}"}},{"id":"j12d-v-yEZ","type":"paragraph","data":{"text":"이런 스타일은 좋지 않은데 그 이유를 2가지로 요약할 수 있다. "}},{"id":"8hiUgj9CyF","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"메서드에 대해 제대로 커뮤니케이션하지 못한다","meta":{},"items":[]},{"content":"더 큰 문제는 메서드 수준에서 캡슐화를 위반한다는 것이다.","meta":{},"items":[]}]}},{"id":"QtGMuZKgtY","type":"delimiter","data":{}},{"id":"p27UvPEVrB","type":"paragraph","data":{"text":"메서드의 이름을 짓는 두번째 방법은 '어떻게' 가 아니라 '무엇' 을 하는지를 드러내는 것이다."}},{"id":"PL3uHJLWGF","type":"code","data":{"code":"public class PeriodCondition {\n\tpublic boolean isSatisfiedBy(Screening screening) {...}\n}\n\npublic class SequenceCondition {\n\tpublic boolean isSatisfiedBy(Screening screening) {...}\n}"}},{"id":"E8LUOhpiPR","type":"code","data":{"code":"public interface DiscountCondition {\n\tboolean isSatisfiedBy(Screening screening);\n}\n\npublic class PeriodCondition implements DiscountCondition {\n\tpublic boolean isSatisfiedBy(Screening screening) {...}\n}\n\npublic class SequenceCondition implements DiscountCondition {\n\tpublic boolean isSatisfiedBy(Screening screening) {...}\n}"}},{"id":"6wpklLLTwV","type":"code","data":{"code":"\npublic class TicketSeller{\n\tpublic void selTo(Audience audience) {...}\n}\n\npublic class Audience {\n\tpublic void buy (Ticket ticket) {...}\n}\n\npublic class Bag {\n\tpublic Long hold(Ticket ticket) {...}\n}"}},{"id":"1aBSkNRKPD","type":"paragraph","data":{"text":"디미터 법칙은 객체 간의 협력을 설계할 때 캡슐화를 위반하는 메시지가 인터페이스에 포함되지 않도록 제한한다. "}},{"id":"OhQpIJt_ZV","type":"paragraph","data":{"text":"묻지 말고 시켜라 원칙은 디미터 법칙을 준수하는 협력을 만들기 위한 스타일을 제시한다. 여기서 멈추지 마라."}},{"id":"V-pLSMZ3y0","type":"paragraph","data":{"text":"의도를 드러내는 인터페이스 원칙은 객체의 퍼블릭 인터페이스에 어떤 이름이 드러나야 하는지에 대한 지침을 제공함으로써 코드의 목적을 명확하게 커뮤니케이션 할 수 있게 해준다. "}},{"id":"YTm8XqgzEE","type":"paragraph","data":{"text":"우리는 결합도가 낮으면서도 의도를 명확하게 드러내는 간결한 협력을 원한다. 디미터 법칙과 묻지말고 시켜라 스타일, 의도를 드러내는 인터페이스가 우리를 도울 것이다."}},{"id":"0qxAqDayJ1","type":"delimiter","data":{}},{"id":"btONV0HJhm","type":"customHeader","data":{"text":"원칙의 함정 "}},{"id":"w3nn7nGNxt","type":"paragraph","data":{"text":"디미터 법칙과, 묻지 말고 시켜라 스타일은 객체의 퍼블릭 인터페이스를 깔끔하고 유연하게 만들 수 있는 훌륭한 설계 원칙이다. 하지만 절대적인 법칙은 아니다. 소프트웨어 설계에 법칙이란 존재하지 않는다. 법칙에는 예외가 없지만 원칙에는 예외가 넘쳐난다."}},{"id":"OYZP3Odv5f","type":"paragraph","data":{"text":"잊지 말아야 하는 사실은 설계가 트레이드오프의 산물이라는 것이다. 설계를 적절하게 트레이드오프 할 수 있는 능력이 숙련자와 초보자를 구분하는 가장 중요한 기준이라고 할 수 있다. "}},{"id":"bMiC7aHzHU","type":"paragraph","data":{"text":"초보자는 원칙을 맹목적으로 추종한다. 심지어 적용하려는 원칙들이 서로 충돌하려는 경우에도 원칙에 정당성을 부여하고 억지로 끼워 맞추려고 노력한다. 결과적으로 설계는 일관성을 잃어버리고 코드는 무질서 속에 파묻히며 개발자는 길을 잃은 채 방황하게 된다. "}},{"id":"1lXiEvspUK","type":"paragraph","data":{"text":"원칙이 현재 상황에 부적합하다고 판단된다면 과감하게 원칙을 무시하라, 원칙을 아는 것보다 더 중요한 것은 언제 원칙이 유용하고 언제 유용하지 않은지를 판단할 수 있는 능력을 기르는 것이다. 트레이드오프 능력을 기르기 위해 이번 장에서 설명한 원칙들을 적용할 때, 고려해볼 만한 이슈 몇가지를 살펴보자."}},{"id":"bRii4Eazmg","type":"delimiter","data":{}},{"id":"dtetuX3Ie_","type":"customHeader","data":{"text":"디미터 법칙은 하나의 도트(.)를 강제하는 규칙이 아니다"}},{"id":"bj1dAA_M2R","type":"paragraph","data":{"text":"디미터 법칙은 \"오직 하나의 도트만을 사용하라\" 라는 말로 요약되기도 한다. 따라서 대부분의 사람들은 자바8 의 IntStream 을 사용한 아래의 코드가 기차 충돌을 초래하기 때문에 디미터 법칙을 위반한다고 생각할 것이다."}},{"id":"GRY_Iajql5","type":"code","data":{"code":"IntStream.of(1, 15, 20, 3, 9).filter(x -> x > 10).distinct().count();"}},{"id":"CGsgiM_4rA","type":"paragraph","data":{"text":"하지만 이것은 디미터 법칙은 제대로 이해하지 못한 것이다. 위 코드에서 of, filter, distinct 메서드는 모두 IntStream 이라는 동일한 클래스의 인스턴스를 반환한다. 즉 이들은 IntStream 의 인스턴스를 또 다른 IntStream 의 인스턴스로 변환한다."}},{"id":"pDrCVqrU8m","type":"paragraph","data":{"text":"따라서 이 코드는 디미터 법칙을 위반하지 않는다. 디미터 법칙은 결합도와 관련된 것이며, 이 결합도가 문제가 되는 것은 객체의 내부 구조가 외부로 노출되는 경우로 한정된다. IntStream 의 내부 구조가 외부로 노출됐는가? 그렇지 않다. 단지 IntStream 을 다른 IntStream 으로 변환할 뿐, 객체를 둘러싸고 있는 캡슐은 그대로 유지된다."}},{"id":"lGJB_WHvdS","type":"paragraph","data":{"text":"하나 이상의 도트(.)를 사용하는 모든 케이스가 디미터 법칙 위반인 것은 아니다. 기차 충돌처럼 보이는 코드라도 객체의 내부 구현에 대한 어떤 정보도 외부로 노출하지 않는다면, 그것은 디미터 법칙을 준수한 것이다. "}},{"id":"12sTXJKSHj","type":"paragraph","data":{"text":"이 메서드들은 객체의 내부에 어떤 내용도 묻지 않는다. 그저 객체를 다른 객체로 변환하는 작업을 수행하라고 시킬 뿐이다. 따라서 묻지 말고 시켜라 원칙을 위반하지 않는다."}},{"id":"jJ4jelqmln","type":"paragraph","data":{"text":"여러분이 이런 종류의 코드와 마주쳐야 하는 위기의 순간이 온다면 스스로에게 다음과 같은 질문을 하기 바란다. 과연 여러개의 도트를 사용한 코드가 객체의 내부 구조를 노출하고 있는가?"}},{"id":"EfBNczbJ_r","type":"delimiter","data":{}},{"id":"chMivGWXbk","type":"customHeader","data":{"text":"결합도와 응집도의 충돌"}},{"id":"1wtqJh31p6","type":"paragraph","data":{"text":"일반적으로 어떤 객체의 상태를 물어본 후 반환된 상태를 기반으로 결정을 내리고 그 결정에 따라 객체의 상태를 변경하려는 코드는 묻지 말고 시켜라 스타일로 변경해야 한다. Thater 의 enter 메서드를 다시 살펴보자 "}},{"id":"zwz_TaAZfJ","type":"code","data":{"code":"public class Theater{\n\tpublic void enter(Audience audience){\n\t\tif (audience.getBag().hasInvitation()){\n\t\t\tTicket ticket = ticketSeller.getTicketOffice().getTicket();\n\t\t\taudience.getBag().setTicket(ticket);\n\t\t}else {\n\t\t\tTicket ticker = ticketSeller.getTicketOffice().getTicket();\n\t\t\taudience.getBag().minusAmount(ticket.getFee());\n\t\t\tticketSeller.getTicketOffice().plusAmount(ticket.getFee());\n\t\t\taudience.getBag().setTicket(ticket);\n\t\t}\n\t}\n}"}},{"id":"u_g5fN1va5","type":"paragraph","data":{"text":"Thater 는 Audience 내부에 포함된 Bag 에 대해 질문 한 후 반환된 결과를 이용해 Bag 의 상태를 변경한다. "}},{"id":"33OoSGfZfr","type":"paragraph","data":{"text":"이 코드는 분명히 Audience 의 캡슐화를 위반하기 때문에, Theater 는 Audience 의 내부 구조에 강하게 결합된다. 이 문제를 해결할 수 있는 방법은 질문하고, 판단하고, 상태를 변경하는 모든 코드를 Audience 로 옮기는 것이다. "}},{"id":"049Sz0-hW2","type":"code","data":{"code":"public class Theater{\n\tpublic void enter(Audience audience){\n\t\tif (audience.getBag().hasInvitation()){\n\t\t\tTicket ticket = ticketSeller.getTicketOffice().getTicket();\n\t\t\taudience.getBag().setTicket(ticket);\n\t\t}else {\n\t\t\tTicket ticker = ticketSeller.getTicketOffice().getTicket();\n\t\t\taudience.getBag().minusAmount(ticket.getFee());\n\t\t\tticketSeller.getTicketOffice().plusAmount(ticket.getFee());\n\t\t\taudience.getBag().setTicket(ticket);\n\t\t}\n\t}\n}"}},{"id":"xCDC7qtCgt","type":"paragraph","data":{"text":"이제 Audience 는 상태와 함께 상태를 조작하는 행동도 포함하기 때문에 응집도가 높아졌다. 이 예제에서 알 수 있는 것처럼 위임 메서드를 통해 객체의 내부 구조를 감추는 것은 협력에 참여하는 객체들의 결합도를 낮출 수 있는 동시에 객체의 응집도를 높일 수 있는 가장 효과적인 방법이다."}},{"id":"lPZSStjhm_","type":"paragraph","data":{"text":"안타깝게도 묻지 말고 시켜라와 디미터 법칙을 준수하는 것이 항상 긍정적인 결과로만 귀결되는 것은 아니다. 모든 상황에서 맹목적으로 위임 메서드를 추가하면 같은 퍼블릭 인터페이스 안에 어울리지 않는 오퍼레이션들이 공존한다. 결과적으로 객체는 상관 없는 책임들을 한꺼번에 떠안게 되기 때문에 결과적으로 응집도가 낮아진다. "}},{"id":"uYalt4wL31","type":"paragraph","data":{"text":"클래스는 하나의 변경 원인만을 가져야 한다. 서로 상관없는 책임들이 함께 뭉쳐있는 클래스는 응집도가 낮으며 작은 변경으로도 쉽게 무너질 수 있다."}},{"id":"hkKwi9gT5o","type":"paragraph","data":{"text":"영화 예매 시스템의 PeriodCondition 클래스를 살펴보자. isSatisFiedBy 메서드는 screening 에게 질의한 상영 시작 시간을 이용해 할인 여부를 결정한다. 이 코드는 얼핏 보기에는 Screening 의 내부 상태를 가져와서 사용하기 때문에 캡슐화를 위반한 것으로 보일 수 있다."}},{"id":"JfF2gALHft","type":"code","data":{"code":"public class PeriodCondition implements DiscountCondition{\n\tpublic boolean isSatisfiedBy(Screening screening){\n\t\treturn screening.getStartTime().getDayOfWeek().equals(dayOfWeek) &&\n\t\t\tstartTime.compareTo(screening.getStartTime().toLocalTime()) <= 0 &&\n\t\t\tendTime.compareTo(screening.getStartTime().toLocalTime()) >= 0;\n\t}\n}"}},{"id":"j9ofUYBfdF","type":"paragraph","data":{"text":"따라서 할인 여부를 판단하는 로직을 Screening 의 isDiscountable 메서드로 옮기고 PeriodCondition 이 이 메서드를 호출하도록 변경한다면 묻지 말고 시켜라 스타일을 준수하는 퍼블릭 인터페이스를 얻을 수 있다고 생각할 것이다 ."}},{"id":"5PPvjOdV7J","type":"code","data":{"code":"public class Screening {\n\tpublic boolean isSatisfiedBy(DayOfWeek dayofWeek, LocalTime startTime, LocalTime endTime){\n\t\treturn whenScreend.getDayOfWeek().equals(dayOfWeek) &&\n\t\t\tstartTime.compareTo(screening.getStartTime().toLocalTime()) <= 0 &&\n\t\t\tendTime.compareTo(screening.getStartTime().toLocalTime()) >= 0;\n\t}\n}\n\npublic class PeriodCondition implements DiscountCondition {\n\tpublic boolean isSatisfiedBy (Screening screening){\n\t\treturn screening.isDiscountable(dayofWeek, startTime, endTime);\n\t}\n}"}},{"id":"ZLYpga7c8E","type":"paragraph","data":{"text":"하지만 이렇게 하면 Screening 이 기간에 따른 할인 조건을 판단하는 책임을 떠안게 된다. 이것이 Screening 이 담당해야 하는 본질적인 책임인가? 그렇지 않다."}},{"id":"MvJvAG6Rhq","type":"paragraph","data":{"text":"Screening 의 본질적인 책임은 영화를 예매하는 것이다. Screening 이 직접 할인 할인 조건을 판단하게 되면 객체의 응집도는 낮아진다. 반면 PeriodCondition 의 입장에서는 할인 조건을 판단하는 책임이 본질적이다. "}},{"id":"TEBNmjvxxg","type":"paragraph","data":{"text":"게다가 Screening 은 PeriodCondition 의 인스턴스 변수를 인자로 받기 때문에 PeriodCondition 의 인스턴스 변수 목록이 변경될 경우에도 영향을 받게 된다. 이것은 Screening 과 PeriodCondition 사이의 결합도를 높인다. 따라서 Screening 의 캡슐화를 향상시키는 것보다 Screening 의 응집도를 높이고 Screening 과 PeriodCondition 사이의 결합도를 낮추는 것이 전체적인 관점에서 더 좋은 방법이다."}},{"id":"WgGS-V4KQK","type":"delimiter","data":{}},{"id":"cFJqoxXTQA","type":"customHeader","data":{"text":"책임에 초점을 맞춰라 "}},{"id":"PIeK1tm6Lh","type":"header","data":{"text":"디미터 법칙 ","level":3}},{"id":"bKVQsLfjkY","type":"paragraph","data":{"text":"협력이라는 컨텍스트 안에서 객체보다 메시지를 먼저 결정하면 두 객체 사이의 구조적인 결합도를 낮출 수 있다. 수신할 객체를 알지 못한 상태에서 메시지를 먼저 선택하기 때문에 객체의 내부 구조에 대해 고민할 필요가 없어진다. 따라서 메시지가 객체를 선택하게 함으로써 의도적으로 디미터 법칙을 위반할 위험을 최소화할 수 있다."}},{"id":"OiTYQ8bOF4","type":"header","data":{"text":"묻지말고 시켜라","level":3}},{"id":"_vjM_GaGy_","type":"paragraph","data":{"text":"메시지를 먼저 선택하면 묻지 말고 시켜라 스타일에 따라 협력을 구조화하게 된다. 클라이언트의 관점에서 메시지를 선택하기 때문에 필요한 정보를 물을 필요 없이 원하는 것을 표현한 메시지를 전송하면 된다."}},{"id":"PHb9fy1tR6","type":"header","data":{"text":"의도를 드러내는 인터페이스","level":3}},{"id":"aLzWuIP37X","type":"paragraph","data":{"text":" 메시지를 먼저 선택한다는 것은 메시지를 전송하는 클라이언트의 관점에서 메시지의 이름을 정한다는 것이다. 당연히 그 이름에는 클라이언트가 무엇을 원하는지, 그 의도가 분명하게 드러날 수 밖에 없다. "}},{"id":"Y5nYpewqqP","type":"header","data":{"text":"명령-쿼리 분리 원칙","level":3}},{"id":"TLb5oEHu6o","type":"paragraph","data":{"text":"메시지를 먼저 선택한다는 것은 협력이라는 문맥 안에서 객체의 인터페이스에 관해 고민한다는 것을 의미한다. 객체가 단순히 어떤 일을 해야 하는지뿐만 아니라 협력 속에서 객체의 상태를 예측하고 이해하기 쉽게 만들기 위한 방법에 관해 고민하게 된다. 따라서 예측 가능한 협력을 만들기 위해 명령과 쿼리를 분리하게 될 것이다. "}},{"id":"NoSrFsyaq_","type":"delimiter","data":{}},{"id":"dAUWe3HjpP","type":"paragraph","data":{"text":"1장에서 처리 단계를 중심으로 시스템을 분해하는 절차적 프로그래밍과 객체를 중심으로 시스템을 분해하는 객체지향 프로그래밍의 차이점을 살펴봄으로써 객체지향 패러다임이 어떤 장점을 가지는지 소개했다."}},{"id":"E2WGIUH4ii","type":"paragraph","data":{"text":"4장과 5장에서는 객체가 저장하는 데이터가 아니라 객체가 외부에 제공하는 책임을 기준으로 객체를 분해하는 방법이 가지는 장점을 살펴봤다."}},{"id":"7myXf3W1fG","type":"paragraph","data":{"text":"그리고 이번 장에서는 객체의 퍼블릭 인터페이스가 객체의 품질에 어떤 영향을 미치는지 살펴봤다. 여러분은 이제 훌륭한 객체지향 프로그램을 작성하기 위해 책임을 할당하는 방법과 다양한 품질 척도를 기준으로 설계를 트레이드오프하는 방법에 대해 대략적인 감을 잡았을 것이다. "}}],"version":"2.31.0-rc.7"}

Tag List