{"time":1752647306988,"blocks":[{"id":"zBY1wGDj9B","type":"warning","data":{"title":"해당 글은 조영호님의 쓰신 Object 책을 읽고 챕터별로 정리해본 글입니다. ","message":""}},{"id":"j0WUfW_ewZ","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":"9thLdiWo4g","type":"delimiter","data":{}},{"id":"lYMV76E_U7","type":"paragraph","data":{"text":"잘 설계된 객체지향 어플리케이션은 작고 응집도 높은 객체들로 구성된다. 작고 응집도 높은 객체란 책임의 초점이 명확하고 한 가지 일만 잘 하는 객체를 의미한다. 이런 작은 객체들이 단독으로 수행할 수 있는 작업은 거의 없기 때문에 일반적인 애플리케이션의 기능을 구현하기 위해서는 다른 객체에게 도움을 요청해야 한다. 이런 요청이 객체 사이의 협력을 낳는다."}},{"id":"qveINfYUNI","type":"delimiter","data":{}},{"id":"P-GcC6OAus","type":"header","data":{"text":"런타임 의존성과 컴파일타임 의존성","level":2}},{"id":"BzA36jA82e","type":"paragraph","data":{"text":"의존성 관련해서 다뤄야 하는 또 다른 주제는 런타임 의존성( run-time dependency) 과 컴파일 타임 의존성(compile-time dependency) 의 차이다. "}},{"id":"x_coajZmZr","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"런타임은 말 그래도 애플리케이션이 실행되는 시점을 가리킨다","meta":{},"items":[]},{"content":"컴파일 타임은 작성된 코드를 컴파일 하는 시점을 가리키지만 문맥에 따라서는 코드 그 자체를 가리키기도 한다 ","meta":{},"items":[]}]}},{"id":"1Td5q0oPyz","type":"delimiter","data":{}},{"id":"JOxzwK4ilf","type":"paragraph","data":{"text":"객체지향 애플리케이션에서 런타임의 주인공은 객체다. 따라서 런타임 의존성이 다루는 주제는 객체 사이의 의존성이다. 반면 코드 관점에서 주인공은 클래스다. 따라서 컴파일타임 의존성이 다루는 주제는 클래스 사이의 의존성이다. "}},{"id":"hElAo5Ggp1","type":"paragraph","data":{"text":"여기서 중요한 것은 런타임 의존성과 컴파일타임 의존성이 다를 수 있다는 것이다. 사실 유연하고 재사용 가능한 코드를 설계하기 위해서는 두 종류의 의존성을 서로 다르게 만들어야한다."}},{"id":"IgPYi74UeL","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/스크린샷_2025-07-16_오후_2.26.45.png"}}},{"id":"taJIuWKHoz","type":"paragraph","data":{"text":"Movie 클래스는 AmountDiscountPolicy 와 PercentDiscountPolicy 클래스로 향하는 어떤 의존성도 존재하지 않는다. Movie 클래스는 오직 추상 클래스인 DiscountPolicy 클래스에만 의존한다."}},{"id":"aILTTyh0PL","type":"paragraph","data":{"text":"하지만 런타임 의존성을 살펴보면 상황이 완전히 달라진다. 금액 할인 정책을 적용하기 위해서는 AmountDiscountPolicy 의 인스턴스와 협력해야 하고 비율 할인 정책을 적용하기 위해서는 PercentDiscountPolicy 의 인스턴스와 협력해야 한다. "}},{"id":"Hdk5OY0-8q","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/스크린샷_2025-07-16_오후_2.33.04.png"}}},{"id":"Brz6XmLL4u","type":"paragraph","data":{"text":"Movie 클래스가 AmountDiscountPolicy 와 PercentDiscountPolicy 클래스 둘 모두에 의존하도록 만드는 것은 좋은 방법이 아닌데, 이것은 Movie 의 전체적인 결합도를 높일 뿐만 아니라 새로운 할인 정책을 추가하기 어렵게 만들기 때문이다. "}},{"id":"6I7hQb4q5W","type":"paragraph","data":{"text":"이 둘 클래스의 인스턴스를 함께 협력할 수 있게 만드는 더 나은 방법은 Moive 클래스가 두 클래스 중 어떤 것도 알지 못하게 만드는 것이다. 대신 두 클래스 모두를 포괄하는 DiscountPolicy 라는 추상 클래스에 의존하도록 만들고 이 컴파일 타임 의존성을 실행 시에 PercentDiscountPolicy 나 AmountDiscountPolicy 인스턴스에 대한 런타임 의존성으로 대체해야 한다. "}},{"id":"bmwCNbTMi7","type":"delimiter","data":{}},{"id":"hDaS_qwQgz","type":"header","data":{"text":"컨텍스트 독립성","level":2}},{"id":"dxKa4JQ8PI","type":"paragraph","data":{"text":"유연하고 확장 가능한 설계를 만들기 위해서는 컴파일타임 의존성과 런타임 의존성이 달라야 한다."}},{"id":"htxGb-nGHu","type":"paragraph","data":{"text":"구체 클래스에 의존하는 것은 클래스의 인스턴스가 어떤 문맥에서 사용될 것인지를 구체적으로 명시하는 것과 같다. Moive 클래스 안에 PercentDiscountPolicy 클래스에 대한 컴파일타임 의존성을 명시적으로 표현하는 것은 Movie 가 비율 할인 정책이 적용된 영화의 요금을 계산하는 문맥에서 사용될 것이라는 것을 가정하는것이다. "}},{"id":"35l5M9nSMq","type":"paragraph","data":{"text":"이와 달리 Movie 클래스에 추상 클래스인 DiscountPolicy 에 대한 컴파일타임 의존성을 명시하는 것은 Movie 가 할인 정책에 따라 요금을 계산하지만 구체적으로 어떤 정책을 따르는지는 결정하지 않았다고 선언하는 것이다. 이 경우 구체적인 문맥은 컴파일타임 의존성을 어떤 런타임 의존성으로 대체하느냐에 따라 달라질 것이다. "}},{"id":"tyXSpceAQG","type":"paragraph","data":{"text":"클래스가 특정 문맥에 강하게 결합될수록 다른 문맥에서 사용하기는 더 어려워진다. 클래스가 사용될 특정한 문맥에 대해 최소한의 가정만으로 이뤄져 있다면 다른 문맥에서 재사용하기가 더 수월해진다. 이를 '컨텍스트 독립성'이라고 부른다."}},{"id":"Z_3eACQhVy","type":"delimiter","data":{}},{"id":"ejgjnUY5PG","type":"header","data":{"text":"의존성 해결하기 ","level":2}},{"id":"63xVnPz8bc","type":"paragraph","data":{"text":"컴파일타임 의존성을 실행 컨텍스트에 맞는 적절한 런타임 의존성으로 교체하는 것을 '의존성 해결' 이라고 부른다. 의존성을 해결하기 위해서는 일반적으로 다음과 같은 3가지 방법을 사용한다"}},{"id":"iSpJy4WptS","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"객체를 생성하는 시점에 생성자를 통해 의존성 해결 ","meta":{},"items":[]},{"content":"객체 생성 후 setter 메서드를 통해 의존성 해결 ","meta":{},"items":[]},{"content":"메서드 실행 시 인자를 이용해 의존성 해결 ","meta":{},"items":[]}]}},{"id":"bHKDYmXNfV","type":"paragraph","data":{"text":"사용과 생성의 책임을 분리하고, 의존성을 생성자에 명시적으로 드러내고, 구체 클래스가 아닌 추상 클래스에 의존하게 함으로써 설계를 유연하게 만들 수 있다. 그리고 그 출발은 객체를 생성하는 책임을 객체 내부가 아니라 클라이언트로 옮기는 것에서 시작했다는 점을 기억하라. 이 예제는 올바른 객체가 올바른 책임을 수행하게 하는 것이 훌륭한 설계를 창조하는 기반이라는 사실을 잘 보여준다. "}},{"id":"c1KR_uVIuQ","type":"delimiter","data":{}},{"id":"NQ75RLGDMT","type":"header","data":{"text":"가끔은 생성해도 무방하다 ","level":2}},{"id":"z3Gs28cRog","type":"paragraph","data":{"text":"클래스 안에서 객체의 인스턴스를 직접 생성하는 방식이 유용한 경우도 있다. 주로 협력하는 기본 객체를 설정하고 싶은 경우가 여기에 속한다. 예를 들어, Movie 가 대부분의 경우에는 AmountDiscountPolicy 의 인스턴스와 협력한다고 가정해보자."}},{"id":"7blgtPRj11","type":"paragraph","data":{"text":"이런 상황에서 모든 경우에 인스턴스를 생성하는 책임을 클라이언트로 옮긴다면 클라이언트들 사이에 중복코드가 늘어나고 Movie의 사용성도 나빠질 것이다. "}},{"id":"KOMUwq0Rzb","type":"paragraph","data":{"text":"이 문재를 해결하는 방법은 기본 객체를 생성하는 생성자를 추가하고 이 생성자에서 DiscountPolicy 의 인스턴스를 인자로 받는 생성자를 체이닝 하는 것이다. 다음은 title 과 runningTime 을 인자로 받는 생성자를 추가한 Movie 클래스를 나타낸 것이다."}},{"id":"YxAXiswg9L","type":"code","data":{"code":"publc class Movie {\n\tprivate DiscountPolicy discountPolicy;\n\n\tpublic Movie(String title, Duration runningTime, Money fee){\n\t\tthis(title, runningTime, fee, new AmountDiscoutPolicy(..));\n\t}\n\n\tpublic Movie(String title, Duration runningTime, Money fee, DiscountPolicy discountPolicy){\n ...\n\t\tthis.discountPolicy = discountPolicy;\n\t}\n}"}},{"id":"ytHDz1KdvT","type":"paragraph","data":{"text":"추가된 생성자 안에서 AmountDiscountPolicy 클래스의 인스턴스를 생성한다는것을 알 수 있다. 여기서 눈여겨 볼 부분은 첫번째 생성자의 내부에서 두번째 생성자를 호출한다는 것이다. 다시 말해 생성자가 체인처럼 연결된다. 이제 클라이언트는 대부분의 경우에 추가된 간략한 생성자를 통해 AmountDiscountPolicy 의 인스턴스와 협력하게 하면서도 컨텍스트에 적절한 DiscountPolicy 의 인스턴스로 의존성을 교체할 수 있다. "}},{"id":"eNfptbCC6d","type":"paragraph","data":{"text":"이 예는 설계가 트레이드오프 활동이라는 사실을 다시 한번 상기시킨다. 여기서 트레이드오프의 대상은 결합도와 사용성이다. 구체 클래스에 의존하게 되더라도 클래스의 사용성이 더 중요하다면 결합도를 높이는 방향으로 코드를 작성할 수 있다. 그럼에도 가금적 구체 클래스에 대한 의존성을 제거할 수 있는 방법을 찾아보기 바란다. "}},{"id":"OL04gF8dey","type":"delimiter","data":{}},{"id":"HrtPjRa64y","type":"header","data":{"text":"컨텍스트 확장하기 ","level":2}},{"id":"22jXZ781n1","type":"paragraph","data":{"text":"지금까지 Movie 의 설계가 유연하고 재사용 가능한 이유에 대해 장황하게 설명했다. 이제 실제로 Movie 가 유연하다는 사실을 입증하기 위해 지금까지와는 다른 컨텍스트에서 Movie 를 확장해서 재사용하는 두 가지 예를 살펴보겠다."}},{"id":"k-Ujd2YqxJ","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"하나는 할인 혜택을 제공하지 않는 영화의 경우이고,","meta":{},"items":[]},{"content":"다른 하나는 다수의 할인 정책을 중복해서 적용하는 영화를 처리하는 것이다.","meta":{},"items":[]}]}},{"id":"hb1uziE_KA","type":"delimiter","data":{}},{"id":"VLq0sSySiW","type":"paragraph","data":{"text":"첫번째 할인 혜택을 제공하지 않는 영화의 예매 요금을 계산하는 경우다. 쉽게 생각할 수 있는 방법은 discountPolicy 에 어떤 객체도 할당하지 않는 것이다. 다음과 같이 discountPolicy 에 null 값을 할당하고 실제로 사용할 때는 null 이 존재하는지 판단하는 방법을 사용할 수 있다.."}},{"id":"x4QZmJf6F0","type":"code","data":{"code":"public class Movie {\n\tpublic Movie(String title, Duration runningTime, Money fee){\n\t\tthis(title, runningTime, fee, null);\n\t}\n\n\tpublic Movie(String title, Duration runningTime, Money fee, DiscountPolicy policy){\n\t\tthis.discountPolicy = policy;\n\t}\n\tpublic Money calculateMovieFee(Screening screening){\n\t\tif(discountPolicy == null){\n\t\t\treturn fee;\n\t\t}\n\n\t\treturn fee.minus(discountPolicy.calculateDiscountAmount(screening));\n\t}\n}"}},{"id":"lqXfCne__M","type":"paragraph","data":{"text":"앞에서 설명한 생성자 체이닝 기법을 이용해 기본값으로 null 을 할당하고 있다는 점을 눈여겨보기 바란다. discountPolicy 의 값이 null 인 경우에는 할인 정책을 적용해서는 안되기 때문에, calculateMovieFee 매서드 내부에서 discountPolicy 의 값이 null 인지 여부를 체크한다."}},{"id":"-q9pA876qt","type":"paragraph","data":{"text":"이 코드는 제대로 동작하지만 한가지 문제가 있다. 지금까지의 Movie 와 DiscountPolicy 사이의 협력 방식에 어긋나는 예외 케이스가 추가된 것이다. 그리고 이 예외 케이스를 처리하기 위해 Movie 의 내부 코드를 직접 수정해야 했다. 어떤 경우든 코드 내부를 직접 수정하는 것은 버그의 발생 가능성을 높이는 것이라는 점을 기억하라."}},{"id":"Dn8tvvgDm2","type":"paragraph","data":{"text":"해결책은 할인 정책이 존재하지 않는다는 사실을 예외 케이스로 처리하지 말고 기존에 Movie 와 DiscountPolicy 가 협력하던 방식을 따르도록 만드는 것이다. 다시 말해 할인 정책이 존재하지 않는다는 사실을 할인 정책의 한 종류로 간주하는 것이다. 방법은 간단하다. 할인할 금액으로 0 원을 반환하는 NoneDiscountPolicy 클래스를 추가하고 DiscountPolicy 의 자식 클래스로 만드는 것이다. "}},{"id":"FQ-BbfO2fY","type":"code","data":{"code":"public class NoneDiscountPolicy extends DiscountPolicy {\n\t@Override\n\tprotected Money getDiscountAmount(Screening screening){\n\t\treturn Money.ZERO;\n\t}\n}"}},{"id":"f-8ex3CFff","type":"paragraph","data":{"text":"이제 Movie 클래스에 특별한 if 문을 추가하지 않고도 할인 혜택을 제공하지 않는 영화를 구현할 수 있다. 간단히 NoneDiscountPolicy 의 인스턴스를 Movie 의 생성자에 전달하면 되는 것이다. "}},{"id":"6nTynf8ymx","type":"code","data":{"code":"Movie avatar = new Movie(\"아바타\",\n\t\t\tDuration.ofMinues(120), \n\t\t\tMone.wons(10000), \n\t\t\tnew NoneDiscountPolicyt()\n\t\t);"}},{"id":"AzntmzoTE4","type":"paragraph","data":{"text":"두번째 예는 중복적용이 가능한 할인 정책을 구현하는 것이다. 여기서 중복 할인이란 금액 할인 정책과 비율 할인 정책을 혼합해서 적용할 수 있는 할인 정책을 의미한다. 할인 정책을 중복해서 적용하기 위해서는 Movie 가 하나 이상의 DiscountPolicy 와 협력할 수 있어야 한다."}},{"id":"xg3gEuzzkR","type":"paragraph","data":{"text":"가장 간단하게 구현할 수 있는 방법은 Movie 가 DiscountPolicy 의 인스턴스들로 구성된 List 를 인스턴스 변수로 갖게하는 것이다. 하지만 이 방법은 중복 할인 정책을 구현하기 위해 기존의 할인 정책의 협력 방식과는 다른 예외 케이스를 추가하게 만든다."}},{"id":"AaCZbClqpB","type":"paragraph","data":{"text":"이 문제 역시 NoneDiscountPolicy 와 같은 방법을 사용해서 해결할 수 있다. 중복할인 정책을 할인 정책의 한 가지로 간주하는 것이다. 중복 할인 정책을 구현하는 OverlappedDiscountPolicy 를 DiscountPolicy 의 자식 클래스로 만들면 기존의 Movie 와 DiscountPolicy 사이의 협력 방식을 수정하지 않고도 여러 개의 할인 정책을 사용할 수 있다."}},{"id":"4q9zVqLi8b","type":"code","data":{"code":"public class OverlappedDiscountPolicy extends DiscountPolicy {\n\tprivate List discountPolicies = new ArrayList<>();\n\n\tpublic OverlappedDiscountPolicy(DiscountPolicy ... discountPolicies){\n\t\tthis.discountPolicies = Arrays.asList(discountpolicies);\n\t}\n\n\t@Override\n\tprotected Money getDiscountAmount(Screening screening){\n\t\tMoney result = Money.ZERO;\n\t\tfor(DiscountPolicy each : discountPolicies){\n\t\t\tresult = result.plus(each.calculateDiscountAmount(screening));\n\t\t}\n\t\treturn result;\n\t}\n}"}},{"id":"xEw9egLP_l","type":"paragraph","data":{"text":"이제 OverlappedDiscountPolicy 의 인스턴스를 생성해서 Movie 에 전달하는 것만으로도 중복 할인을 쉽게 적용할 수 있다."}},{"id":"FVmOpQWdSb","type":"code","data":{"code":"Movie avatar = new Movie(\"아바타\",\n Duration.ofMinutes(120),\n Money.wons(10000),\n new OverlappedDiscountPolicy(\n new AmountDiscountPolicy(...),\n new PercentDiscountPolicy(...))\n );"}},{"id":"SyO3SXIDF6","type":"paragraph","data":{"text":"이 예제는 Movie 를 수정하지 않고도 할인 정책을 적용하지 않는 새로운 기능을 추가하는 것이 얼마나 간단한지를 잘 보여준다. 우리는 단지 원하는 기능을 구현한 DiscountPolicy 의 자식 클래스를 추가하고 이 클래스의 인스턴스를 Movie 에 전달하기만 하면 된다. Movie 가 협력해야 하는 객체를 변경하는 것만으로도 Movie 를 새로운 컨텍스트에서 재사용할 수 있기 때문에 Movie 는 유연하고 재사용 가능하다. "}}],"version":"2.31.0-rc.7"}

Tag List