{"time":1752730765582,"blocks":[{"id":"l61BYxtifW","type":"warning","data":{"title":"해당 글은 조영호님의 쓰신 Object 책을 읽고 챕터별로 정리해본 글입니다.","message":""}},{"id":"--F5_NCs9L","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":"Cjcv83OfSG","type":"delimiter","data":{}},{"id":"pKJrgL64oq","type":"paragraph","data":{"text":"상속과 합성은 객체지향 프로그래밍에서 가장 널리 사용되는 코드 재사용 기법이다. "}},{"id":"Hr2XFxao-W","type":"paragraph","data":{"text":"상속이 부모 클래스와 자식 클래스를 연결해서 부모 클래스의 코드를 재사용하는 데 비해 합성은 전체를 표현하는 객체가 부분을 표현하는 객체를 포함해서 부분 객체의 코드를 재사용한다. 상속에서 부모 클래스와 자식 클래스 사이의 의존성은 컴파일타임에 해결되지만 합성에서 두 객체 사이의 의존성은 런타임에 해결된다. 상속 관계는 is-a 관계라고 부르고 합성 관계는 has-a 관계라고 부른다."}},{"id":"fPv5dGnpAB","type":"paragraph","data":{"text":"상속과 합성은 코드 재사용이라는 동일한 목적을 가진다는 점을 제외하면 구현 방법부터 변경을 다루는 방식에 이르기까지 모든 면에서 도드라진 차이를 보인다. 상속을 이용하면 자식 클래스의 정의에 부모 클래스의 이름을 덧붙이는 것만으로 부모 클래스의 코드를 재사용할 수 있게 된다."}},{"id":"Prmtvjdtsm","type":"paragraph","data":{"text":"그러나 상속을 제대로 활용하기 위해서는 부모 클래스의 내부 구현에 대해 상세하게 알아야 하기 때문에 자식 클래스와 부모 클래스 사이의 결합도가 높아질 수 밖에 없다. 결과적으로 상속은 코드를 재사용할 수 있는 쉽고 간단한 방법일지는 몰라도 우아한 방법이라고 할 수는 없다."}},{"id":"hc7O6lD_Jl","type":"paragraph","data":{"text":"합성은 구현에 의존하지 않는다는 점에서 상속과 다르다. 합성은 내부에 포함되는 객체의 구현이 아닌 퍼블릭 인터페이스에 의존한다. 따라서 합성을 이용하면 포함된 객체의 내부 구현이 변경되더라도 영향을 최소할 할 수 있기 때문에 변경에 더 안정적인 코드를 얻을 수 있게 된다 ."}},{"id":"G8J-lWogp1","type":"paragraph","data":{"text":"상속 관계는 클래스 사이의 정적인 관계인 데 비해 합성 관계는 객체 사이의 동적인 관계다. 이 차이점은 생각보다 중요한다, 코드 작성 시점에 결정한 상속 관계는 변경이 불가능하지만 합성 관계는 실행 시점에 동적으로 변경할 수 있기 때문이다. 따라서 상속 대신 합성을 사용하면 변경하기 쉽고 유연한 설계를 얻을 수 있다. "}},{"id":"4HI9JEIF3W","type":"warning","data":{"title":"객체 합성이 클래스 상속보다 더 좋은 방법이다.","message":""}},{"id":"kbtC3KOBH9","type":"paragraph","data":{"text":"상속과 합성은 재사용의 대상이 다르다. 상속은 부모 클래스 안에 구현된 코드 자체를 재사용하지만 합성은 포함되는 객체의 퍼블릭 인터페이스를 재사용한다. 따라서 상속 대신 합성을 사용하면 구현에 대한 의존성을 인터페이스에 대한 의존성으로 변경할 수 있다. 다시 말해서 클래스 사이의 높은 결합도를 객체 사이의 낮은 결합도로 대체할 수 있는 것이다. "}},{"id":"WsuhR9sFW-","type":"delimiter","data":{}},{"id":"vzWa0B8umB","type":"header","data":{"text":"상속으로 인한 조합의 폭발적인 증가","level":2}},{"id":"v7uj58nmP5","type":"paragraph","data":{"text":"상속으로 인해 결합도가 높아지면 코드를 수정하는 데 필요한 작업의 양이 과도하게 늘어나는 경향이 있다. 가장 일반적인 상황은 작은 기능들을 조합해서 더 큰 기능을 수행하는 객체를 만들어야 하는 경우다. 일반적인으로 다음과 같은 두 가지 문제점이 발생한다."}},{"id":"mU5JMz8r1v","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"하나의 기능을 추가하거나 수정하기 위해 불필요하게 많은 수의 클래스를 추가하거나 수정해야 한다.","meta":{},"items":[]},{"content":"단일 상속만 지원하는 언어에서는 상속으로 인해 오히려 중복 코드의 양이 늘어날 수 있다. ","meta":{},"items":[]}]}},{"id":"cfuMJjy1PI","type":"paragraph","data":{"text":"합성을 사용하면 상속으로 인해 발생하는 클래스의 증가와 중복 코드 문제를 간단하게 해결할 수 있다, 코드를 통해 살펴보자 ."}},{"id":"3x2WIcFCGy","type":"delimiter","data":{}},{"id":"aHt2yrGKzV","type":"header","data":{"text":"기본 정책과 부가 정책 조합하기","level":2}},{"id":"zdnTossLlc","type":"paragraph","data":{"text":"10장에서 소개했던 핸드폰 과금 시스템에 새로운 요구사항을 추가해보자. 현재 시스템에는일반 요금제와 심야 할인 요금제라는 두 가지 종류의 요금제가 존재한다. 새로운 요구사항은 이 두 요금제에 부가 정책을추가하는 것이다. 지금부터는 핸드폰 요금제가 '기본 정책' 과 '부가 정책' 을 조합해서 구성된다고 가정할 것이다. "}},{"id":"M089KB7lT8","type":"paragraph","data":{"text":"기본 정책은 가입자의 통화 정보를 기반으로 한다. 기본 정책은 가입자의 한달 통화량을 기준으로 부과할 요금을 계산한다. 앞 장에서 소개한 '일반 요금제' 와 '심야 할인 요금제'는 통화량을 기반으로 요금을 계산하기 때문에 기본정책으로 분류된다. "}},{"id":"PXZGAJXMAA","type":"paragraph","data":{"text":"부가 정책은 통화량과 무관하게 기본 정책에 선택적으로 추가할 수 있는 요금 방식을 의미한다. 10장에서 살펴봤던 세금을 부과하는 정책이 바로 부가 정책에 해당한다. 이 정책은 '세금 정책' 이라고 부를 것이다. 부가 정책에는 세금 정책 외에도 최종계산된 요금에서 일정 금액을 할인해 주는 기본 요금 할인 정책도 존재한다. "}},{"id":"crlBm-kol0","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"기본 정책의 계산 결과에 적용된다","meta":{},"items":[{"content":"세금 정책은 기본 정책인 RegularPhone 이나 NightlyDisucountPhone 의 계산이 끝난 결과에 세금을 부과한다 ","meta":{},"items":[]}]},{"content":"선택적으로 적용할 수 있다","meta":{},"items":[{"content":"기본 정책의 계산 결과에 세금 정책을 적용할 수도 있고 적용하지 않을 수도 있다. ","meta":{},"items":[]}]}]}},{"id":"SpfGvalkj4","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"조합 가능하다","meta":{},"items":[{"content":"기본정책에 세금 정책만 적용하는 것도 가능하고, 기본 요금 할인 정책만 적용하는 것도 가능하다. 또한 세금 정책과 기본 요금 할인 정책을 함께 적용하는 것도 가능해야 한다. ","meta":{},"items":[]}]},{"content":"부가 정책은 임의의 순서로 적용 가능하다","meta":{},"items":[{"content":"기본 정책에 세금 정책과 기본 요금 할인 정책을 함께 적용할 경우 세금 정책을 적용한 후에 기본 요금 할인 정책을 적용할 수도 있고, 기본요금 할인 정책을 적용한 후에 세금 정책을 적용할 수도 있다. ","meta":{},"items":[]}]}]}},{"id":"vkzldubiaO","type":"delimiter","data":{}},{"id":"O_mURPpSlq","type":"header","data":{"text":"상속을 이용해서 기본 정책 구현하기 ","level":2}},{"id":"XNRZknu4i8","type":"paragraph","data":{"text":"상속을 이용해서 기본 정책과 부가 정책을 구현해보자. 기본 정책은 Phone 추상 클래스를 루트로 삼는 기존의 상속 계층을 그대로 이용할 것이다. 일반 요금제를 구현하는 RegularPhone 과 심야 할인 요금제를 구현하는 NightlyDiscountPhone 은 Phone 의 자식 클래스로 구현한다. "}},{"id":"e9-HKAIj0B","type":"paragraph","data":{"text":"아래 코드는 10장에서 구현한 Phone 상속 계층을 그대로 옮겨온 것으로서 기본 정책은 아래의 세 클래스로 구성된다."}},{"id":"JH25ktEezZ","type":"code","data":{"code":"public abstract class Phone {\n private List calls = new ArrayList<>();\n\n public Money calculateFee() {\n Money result = Money.ZERO;\n\n for (Call call : calls) {\n result = result.result.plus(calculateCallFee(call));\n }\n return result;\n }\n\n abstract protected Money calculateCallFee(Call call);\n\n public class RegularPhone extends Phone {\n private Money amount;\n private Duration seconds;\n\n public RegularPhone(Money amount, Duration seconds) {\n this.amount = amount;\n this.seconds = seconds;\n }\n\n @Override\n protected Money calculateCallFee(Call call) {\n return amount.times(call.getDuration().getSeconds() / seconds.getSeconds());\n }\n }\n\n public class NightlyDiscountPhone extends Phone {\n private static final int LATE_NIGHT_HOUR = 22;\n\n private Money nightlyAmount;\n private Money regularAmount;\n private Duration seconds;\n\n public NightlyDiscountPolicy(Money nightlyAmout, Money regularAmount, Duration seconds){\n\t\t\tthis.nightlyAmount = nightlyAmount;\n\t\t\tthis.regularAmount = regularAmount;\n\t\t\tthis.seconds = seconds;\n\t\t}\n\n @Override\n protected Money calculateCallFee(Call call) {\n if (call.getFrom() >= LATE_NIGHT_HOUR) {\n return nightlyAmount.times(call.getDuration().getSeConds() / seconds.getSeconds());\n }\n return regularAmount.times(call.getDuration().getSecounds() / seconds.getSeconds());\n }\n }\n}"}},{"id":"9GbA6icegX","type":"paragraph","data":{"text":"RegularPhone 과 NightlyDiscountPhone 의 인스턴스만 단독으로 생성한다는 것은 부가 정책은 적용하지 않고오직 기본 정책만으로 요금을 계산한다는 것을 의미한다. "}},{"id":"7dZs5hrkEu","type":"delimiter","data":{}},{"id":"3daMJHtGd9","type":"header","data":{"text":"기본 정책에 세금 정책 조합하기 ","level":2}},{"id":"Rtsagw3v2O","type":"paragraph","data":{"text":"만약 일반 요금제에 세금 정책을 조합해야 한다면 어떻게 해야 할까? 가장 간단한 방법은 RegularPhone 클래스를 상속받은 TaxRegularPhone 클래스를 추가하는 것이다. TaxableRegularPhone 클래스는 부모 클래스의 calculateFee 메서드를 오버라이딩 한 후 super() 호출을 통해 부모 클래스에게 calculateFee 메서지를 전송한다. "}},{"id":"fUJ7SfBZHv","type":"paragraph","data":{"text":"RegularPhone 의 calculateFee 메서드는 일반 요금제규칙에 따라 계산된 요금을 반환하므로 이 반환값에 세금을 부과해서 반환하면 일반 요금제와 세금 정책을 조합한 요금을 계산할 수 있다. "}},{"id":"pgVvX4JPlb","type":"code","data":{"code":"public class TaxableRegularPhone extends regularPhone {\n private double taxRate;\n\n public TaxableRegularPhone(Money amount, Duration seconds, double taxRate) {\n super(amount, seconds);\n this.taxRate = taxRate;\n }\n\n @Override\n public Money calculateFee() {\n Money fee = super.calculateFee();\n return fee.plus(fee.times(taxRate));\n }\n}"}},{"id":"r7dmB5sry5","type":"paragraph","data":{"text":"부모 클래스의 메서드를 재사용하기 위해 super 호출을 사용하면 원하는 결과를 쉽게 얻을 수는 있지만 자식 클래스와 부모 클래스 사이의 결합도가 높아지고 만다. 결합도를 낮추는 방법은 자식 클래스가 부모 클래스의 메서드를 호출하지 않도록 부모 클래스에 추상 메서드를 제공하는 것이다. 부모 클래스가 자신이 정의한 추상 메서드를 호출하고 자식 클래스가 이 메서드를 오버라이딩해서 부모 클래스가 원하는 로직을 제공하도록 수정하면 부모 클래스와 자식 클래스 사이의 결합도를 느슨하게 만들 수 있다. "}},{"id":"tikrhWmHTp","type":"paragraph","data":{"text":"이 방법은 자식 클래스가 부모 클래스의 구체적인 구현이 아니라 필요한 동작의 명세를 기술하는 추상화에 의존하도록 만든다. "}},{"id":"hUXgtS5mGJ","type":"paragraph","data":{"text":"먼저 Phone 클래스에 새로운 추상 메서드인 afterCalculated 를 추가하자. 이 메서드는 자식 클래스에게 전체 요금을 계산한 후에 수행할 로직을 추가할 수 있는 기회를 제공한다. "}},{"id":"1jqvBgxW4x","type":"code","data":{"code":"public abstract class Phone {\n private List calls = new ArrayList<>();\n\n public Money calculateFee() {\n Money result = Money.ZERO;\n\n for (Call call : calls) {\n result = result.plus(calculateCallFee(call));\n }\n return afterCalculated(result);\n }\n\n protected abstract Money calculateCallFee(Call call);\n\n protected abstract Money afterCalculated(Money fee);\n}"}},{"id":"z-vTQFoWT3","type":"paragraph","data":{"text":"자식 클래스는 afterCalculated 메서드를 오버라이딩해서 계산된 요금에 적용할 작업을 추가한다. 일반요금제를 구현하는 RegularPhone 은 요금을 수정할 필요가 없기 때문에 afterCalculated 메서드에서 파라미터로 전달된 요금을 그대로 반환하도록 구현한다. "}},{"id":"YIgkWNoDh0","type":"code","data":{"code":"public class RegularPhone extends Phone {\n private Money amount;\n private Duration seconds;\n\n public RegularPhone(Money money, Duration seconds) {\n this.amount = amount;\n this.seconds = seconds;\n }\n\n @Override\n protected Money calculateCallFee(Call call) {\n return amount.times(call.getDuration().getSeconds() / seconds.getSeconds());\n }\n\n @Override\n protected Money afterCalculatd(Money fee) {\n return fee;\n }\n}"}},{"id":"NpYRxuv-R3","type":"paragraph","data":{"text":"추상 메서드"}},{"id":"PR_YQqT4JD","type":"warning","data":{"title":"개방 - 폐쇄 원칙을 만족하는 설계를 만들 수 있는 한가지 방법은 부모 클래스에 새로운 추상 메서드를 추가하고 부모 클래스와 다른 메서드 안에서 호출하는 것이다. 자식 클래스는 추상 메서드를 오버라이딩하고 자신만의 로직을 구현해서 부모 클래스에서 정의한 플로우에 개입할 수 있게 된다. 처음에 Phone 클래스에서 추상 메서드인 calculateCallFee 와 AfterCalculated 를 선언하고 자식 클래스에서 두 메서드를 오버라이딩 한 것 역시 이 방식을 응용한 것이다. ","message":""}},{"id":"oJ0DY4Z2DG","type":"paragraph","data":{"text":"훅 메서드"}},{"id":"xVI0D6CABy","type":"warning","data":{"title":"추상 메서드의 단점은 상속 계층에 속하는 모든 자식 클래스가 추상 메서드를 오버라이딩해야 한다는 것이다. 대부분의 자식 클래스가 추상 메서드를 동일한 방식으로 구현한다면 상속 계층 전반에 걸쳐 중복 코드가 존재하게 될 것이다. 해결 방법은 기본 구현을 제공하는 것이다. 이처럼 추상 메서드와 동일하게 자식 클래스에서 오버라이딩할 의도로 메서드를 추가했지만 편의를 위해 기본 구현을 제공하는 메서드를 훅 메서드라고 부른다 afterCalculated 메서드가 훅 메서드이다.","message":""}},{"id":"h9QNvx-iXo","type":"paragraph","data":{"text":"TaxableRegularPhone 을 수정할 차례다. TaxableRegularPhone 은 RegularPhone 이 계산한 요금에 세금을 부과한다. 다음과 같이 afterCalculated 메서드를 오버라이딩 한 후에 fee 에 세금을 더해서 반환하도록 구현하자."}},{"id":"VlNVP8lGQU","type":"code","data":{"code":"public class TaxableregularPhone extends regularPhone {\n private double taxRate;\n\n public TaxableRegularPhone(Money amount, Duration seconds, double taxRate){\n super(amount. seconds);\n this.taxRate = taxRate;\n\t}\n\n @Override\n protected Money afterCalculated(Money fee) {\n return fee.plus(fee.times(taxRate));\n }\n\n}"}},{"id":"lMCeN6TqkG","type":"paragraph","data":{"text":"이제 심야할인 요금제인 NightlyDiscountPhone 에도 세금을 부과할 수 있도록 NightlyDiscountPhone 의 자식 클래스인 TaxableNightlyDiscountPhone 을 추가하자 "}},{"id":"NDCwRX-y31","type":"code","data":{"code":"public class TaxableNightlyDiscountPhone extends NightlyDiscountPhone {\n private double taxRate;\n\n public taxableNightlyDiscountPhone(Money nightlyAmount, Money regularAmount, Duration seconds, double taxRate){\n super(nightlyAmount, regularAmount, seconds);\n this.taxRate = taxRate;\n\t}\n\n @Override\n protected Money afterCalculated(Money fee) {\n return fee.plus(fee.times(taxRate));\n }\n}"}},{"id":"zCXUmjPh4w","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/image(6).png"}}},{"id":"n74NV29KfP","type":"delimiter","data":{}},{"id":"yDAcC0lgsK","type":"header","data":{"text":"중복코드의 덫에 걸리다","level":2}},{"id":"M50nCkYoef","type":"paragraph","data":{"text":"부가 정책은 자유롭게 조합할 수 있어야 하고 적용되는 순서역시 임의로 결정할 수 있어야 한다. 이 요구사항에 따르면 앞에서 구현한 세금 정책과 기본 요금 할인 정책을 함께 적용하는 것도 가능해야 하고, 세금 정책을 적용한 후에 기본요금 할인 정책을 적용하거나 기본 요금할인 정책을 적용한 후에 세금 정책을 적용하는 것도 가능해야 한다. "}},{"id":"s7w-J1k7eI","type":"paragraph","data":{"text":"상속을 이용한 해결 방법은 모든 가능한 조합별로 자식 클래스를 하나씩 추가하는 것이다. 만약 일반 요금제의 계산 결과에 세금 정책을 조합한 후 기본 요금 할인 정책을 추가하고 싶다면 TaxableRegularPhone 을 상속받는 새로운 자식 클래스인 TaxableRateDiscountableRegularPhone 을 추가해야한다. "}},{"id":"4ZItDgbIRk","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/image(7).png"}}},{"id":"bpPla-sRXR","type":"paragraph","data":{"text":"위 그림은 상속을 사용할 경우 새로운 정책을 추가하기가 어렵다. 현재의 설계에 새로운 정책을 추가하기 위해서는 불필요하게 많은 수의 클래스를 상속 계층 안에 추가해야한다. "}},{"id":"5-k3zJi1hz","type":"paragraph","data":{"text":"새로운 기본 정책을 추가하면 그에 따라 조합 가능한 부가 정책의 수만큼 새로운 클래스를 추가해야 한다. "}},{"id":"3H9df7dOkm","type":"paragraph","data":{"text":"이처럼 상속의 남용으로 하나의 기능을 추가하기 위해 필요 이상으로 많은 수의 클래스를 추가해야 하는 경우를 가리켜 클래스 폭발 (class explosion) 문제 또는 조합의 폭발 문제라고 부른다. "}},{"id":"itd-FbhUXH","type":"paragraph","data":{"text":"클래스 폭발 문제는 자식 클래스가 부모 클래스의 구현에 강하게 결합되도록 강요하는 상속의 근본적인 한계 때문에 발생하는 문제다. 컴파일 타임에 결정된 자식 클래스와 부모 클래스 사이의 관계는 변경될 수 없기 때문에 자식 클래스와 부모 클래스의 다양한 조합이 필요한 상황에서 유일한 해결 방법은 조합의 수만큼 새로운 클래스를 추가하는 것뿐이다. "}},{"id":"Dk10OaQb7z","type":"paragraph","data":{"text":"클래스 폭발 문제는 새로운 기능을 추가할 때 뿐만 아니라 기능을 수정할 때도 문제가 된다. 만약 세금정책을 변경해야 한다면 어떻게 해야할까? 세금 정책과 관련된 코드가 여러 클래스 안에 중복돼 있기 때문에 세금 정책과 관련된 모든 클래스를 찾아 동일한 방식으로 수정해야 할 것이다. 이 클래스 중에서 하나라도 누락한다면 세금이 부과되지 않는 버그가 발생하고 말것 이다. "}},{"id":"lBIrQtMwpq","type":"paragraph","data":{"text":"이 문제를 해결할 수 있는 최선의 방법은 상속을 포기하는 것이다. "}},{"id":"1EXREyOKIe","type":"delimiter","data":{}},{"id":"EJ1YzPbDui","type":"header","data":{"text":"합성 관계로 변경하기 ","level":2}},{"id":"dHYijqexiO","type":"paragraph","data":{"text":"상속 관계는 컴파일 타임에 결정되고 고정되기 때문에 코드를 실행하는 도중에는 변경할 수 없다. 따라서 여러 기능을 조합해야 하는 설계에 상속을 이용하면 모든 조합 가능한 경우별로 클래스를 추가해야한다. 이것이 바로 핸드폰 과금 시스템의 설계 과정에서 직면했던 클래스 폭발 문제다."}},{"id":"S80BKJ3GYU","type":"paragraph","data":{"text":"합성은 컴파일타임 관계를 런타임 관계로 변경함으로써 이 문제를 해결한다. 합성을 사용하면 구현이 아닌 퍼블릭 인터페이스에 대해서만 의존할 수 있기 때문에 런타임에 객체의 관계를 변경할 수 있다. "}},{"id":"arh4JNt9Ob","type":"paragraph","data":{"text":"8장에서 컴파일타임 의존성과 런타임 의존성의 거리가 멀수록 설계가 유연햐진다고 했던 것을 기억하라. 상속을 사용하는 것은 컴파일타임의 의존성과 런타임의 의존성을 동일하게 만들겠다고 선언하는 것이다. 따라서 상속을 사용하면 부모클래스와 자식 클래스 사이의 관계가 정적으로 고정되기 때문에 실행시점에 동적으로 관계를 변경할 수 있는 방법이 없다. "}},{"id":"L61lJ40jWa","type":"paragraph","data":{"text":"상속과 달리 합성 관계는 런타임에 동적으로 변경할 수 있다. 합성을 사용하면 컴파일타임 의존성과 런타임 의존성을 다르게 만들 수 있다. "}},{"id":"peZ4DGem6z","type":"paragraph","data":{"text":"사실 8장에서 살펴본 유연한 설계를 만들기 위한 대부분의 의존성관리 기법은 상속이 아닌 합성을 기반으로 한다. 클래스 폭발 문제를 해결하기 위해 합성을 사용하는 이유는 런타임에 객체 사이의 의존성을 자유롭게 변경할 수 있기 때문이다. "}},{"id":"PeW_TIsStg","type":"paragraph","data":{"text":"이것이 바로 합성의 본질이다. 합성을 사용하면 구현 시점에 정책들의 관계를 고정시킬 필요가 없으며 실행 시점에 정책들의 관계를 유연하게 변경할 수 있게 된다. 상속이 조합의 결과를 개별 클래스 안으로 밀어 넣는 방법이라면 합성은 조합을 구성하는 요소들을 개별 클래스로 구현한 후 실행 시점에 인스턴스를 조립하는 방법을 사용하는 것이라고 할 수 있다. 컴파일 의존성에 속박되지 않고 다양한 방식의 런타임 의존성을 구성할 수 있다는 것이 합성이 제공하는 가장 커다란 장점인 것이다. "}},{"id":"KlVZYJuUC1","type":"paragraph","data":{"text":"설계는 트레이드오프의 산물이다. 대부분의 경우에는 단순한 설계가 정답이지만, 변경에 따르는 고통이 복잡성으로 인한 혼란을 넘어서고 있다면 유연성의 손을 들어주는 것이 현명한 판단일 확률이 높다."}},{"id":"lpJPYYJPkW","type":"paragraph","data":{"text":"아이러니하게도 변경하기 편리한 설계를 만들기위해 복잡성을 더하고 나면 원래의 설계보다 단순해지는 경우를 종종 볼수 있다. 상속을 합성으로 변경한 핸드폰 과금 시스템이 바로 그런경우다. 그 이유를 살펴보자. "}},{"id":"ndNxYVt0bq","type":"delimiter","data":{}},{"id":"mlFGJauJXr","type":"header","data":{"text":"기본 정책 합성하기","level":2}},{"id":"X63u_PfBCJ","type":"paragraph","data":{"text":"가장 먼저 해야할 일은 각 정책을 별도의 클래스로 구현하는 것이다. 분리된 정책들을 연결할 수 있도록 합성 관계를 이용해서 구조를 개선하면 그림과 같이 실행 시점에 정책들을 조합할 수 있게된다. 이를 위해서 핸드폰이라는 개념으로부터 요금 계산 방법이라는 개념을 분리해야한다. "}},{"id":"nDIWu_6MpX","type":"paragraph","data":{"text":"먼저 기본 정책과 부가 정책을 포괄하는 RatePolicy 인터페이스를 추가하자. RatePolicy는 Phone 을 인자로 받아 계산된 요금을 반환하는 calculateFee 오퍼레이션을 포함하는 간단한 인터페이스이자 "}},{"id":"igGTgSwpcY","type":"code","data":{"code":"public interface RatePolicy {\n Money calculateFee(phone phone);\n}"}},{"id":"cmTGQ1IloW","type":"paragraph","data":{"text":"기본 정책부터 구현하자. 기본 정책을 구성하는 일반 요금제와 심야 할인요금제는 개별 요금을 계산하는 방식을 제외한 전체 처리 로직이 거의 동일하다. 이 중복 코드를 담을 추상 클래스 BasicRegularPolicy 를 추가하자"}},{"id":"UCxHHgsvBJ","type":"code","data":{"code":"public abstract class BasicRatePlocy implements RatePolicy {\n @Override\n public Money calculateFee(Phone phone) {\n Money result = Money.ZERO;\n\n for (Call call : calls) {\n result.plus(calculateCallFee(call));\n }\n return result;\n }\n\n protected abstract Money calculateCallFee(Call call);\n}"}},{"id":"egpB7blae4","type":"paragraph","data":{"text":"BasicRatePolicy 의 기본 구현은 상속 버전의 Phone 클래스와 거의 동일하다. BasicRatePolicy의 자식 클래스는 추상 메서드인 calculateCallFee 를 오버라이딩해서 Call 의 요금을 계산하는 자신만의 방식을 구현할 수 있다. 먼저 일반요금제를 구현하자. BasicregularPolicy 의 자식 클래스로 RegularPolicy 를 추가하자"}},{"id":"EL6mhWh26f","type":"code","data":{"code":"public class RegularPolicy extends BasicRatePolicy {\n private Money amount;\n private Duration seconds;\n\n public RegularPolicy(Money amount, Duration seconds) {\n this.amount = amount;\n this.seconds = seconds;\n }\n\n @Override\n protected Money calculateCallFee(Call call) {\n return amount.times(call.getDuration().getSeconds() / seconds.getSeconds());\n }\n}"}},{"id":"GwfKbxGPYs","type":"paragraph","data":{"text":"심야 할인 요금제를 구현하는 NightlyDiscountPolicy 클래스 역시 유사한 방식으로 구현할 수 있다."}},{"id":"sOGMuy8Cxg","type":"code","data":{"code":"public class NightlyDiscountPolicy extends BasicRatePolicy {\n private static final int LATE_NIGHT_HOUR = 22;\n\n private Money nightlyAmount;\n private Money regularAmount;\n private Duration seconds;\n\n public NightlyDiscountPolicy(Money nightlyAmount, Money regularAmount, Duration seconds) {\n this.nightlyAmount = nightlyAmount;\n this.regularAmount = regularAmount;\n this.seconds = seconds;\n }\n\n @Override\n protected Money calculateCallFee(Call call) {\n if (call.getFrom().getHour() >= LATE_NIGHT_HOUR) {\n return nighlyAmount.times(call.getDuration().getSeconds() / seconds.getSeconds());\n }\n\n return regularAmount.times(call.getDuration().getSeconds() / seconds.getSeconds());\n\n }\n}"}},{"id":"Cv2CBzi1d_","type":"paragraph","data":{"text":"이제 기본 정책을 이용해 요금을 계산할 수 있도록 Phone 을 수정하자 "}},{"id":"E0f4VPn87m","type":"code","data":{"code":"public class Phone {\n private RatePolicy ratePolicy;\n private List calls = new ArrayList<>();\n\n public Phone(RatePolicy ratePolicy) {\n this.ratePolicy = ratePolicy;\n }\n\n public List getCalls() {\n return Collections.unmidifiableList(calls);\n }\n\n public Money calculateFee() {\n return ratePolicy.calculateFee(this);\n }\n\n}"}},{"id":"fh5bNuwks2","type":"paragraph","data":{"text":"Phone 내부에 RatePolicy 에 대한 참조자가 포함돼 있다는 것에 주목하라. 이것이 바로 합성이다. Phone 이 다양한 요금 정책과 협력 할 수 있어야 하므로 요금 정책이 타입이 RatePolicy 라는 인터페이스로 정의돼 있다는 것에도 주목하라. "}},{"id":"RlIqsOZg84","type":"paragraph","data":{"text":"Phone 은 이 컴파일 타임 의존성을 구체적인 런타임 의존성으로 대체하기 위해 생성자를 통해 RatePolicy 의 인스턴스에 대한 의존성을 주입받는다. Phone 의 경우처럼 다양한 종류의 객체와 협력하기 위해 합성 관계를 사용하는 경우에는 객체의 타입을 인터페이스나 추상 클래스로 선언하고 의존성 중비을 사용해 런타입에 필요한 객체를 설정 할 수 있도록 구현하는 것이 일반적이다."}},{"id":"rIo-uLKt6j","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/합성_관계를_사용한_기본_정책.png"}}},{"id":"15ixP2ZdxF","type":"paragraph","data":{"text":"일반 요금제의 규칙에 따라 통화 요금을 계산하고 싶다면 다음과 같이 Phone 과 BasicRatePolicy 의 인스턴스를 합성하면 된다"}},{"id":"snIvJrtR8Z","type":"code","data":{"code":"Phone phone = new Phone(new RegularPolicy(Money.wons(10), Duration.ofSeconds(10)));"}},{"id":"hmQIe36ozl","type":"paragraph","data":{"text":"심야 할인 요금제의 규칙에 따라 통화 요금을 계산하고 싶다면 다음과 같이 Phone 과 NightlyDiscountPolicy 의 인스턴스를 합성하면 된다."}},{"id":"kHGjSI2Yr7","type":"paragraph","data":{"text":" "}},{"id":"x1Nnu0g1FW","type":"code","data":{"code":"Phone phone = new Phone(new NightlyDiscountPolicy(Money.wons(5), Money.wons(10), Duration.ofSeconds(10)));"}},{"id":"A3Nc3WkIsX","type":"paragraph","data":{"text":"합성을 사용하면 Phone 과 연결되는 RatePolicy 인터페이스의 구현 클래스가 어떤 타입인지에 따라 요금을 계산하는 방식이 달라진다. 여기까지만 보면 단순히 원하는 클래스를 선택하는 상속보다 더 복잡해 졌다는 생각이 든다. "}},{"id":"2Nl5zoynq2","type":"paragraph","data":{"text":"상속을 사용한 경우에는 어떤 클래스의 인스턴스를 조합해야 하는지 고민할 필요 없이 기본 요금제를 적용하고 싶은 경우에는 RegularPhone 을, 심야 할인 요금제를 적용하고 싶은 경우에는 NightlyDiscountPhone 의 인스턴스를 생성하면 됐기 때문이다. 하지만 현재의 설계에 부가 정책을 추가해 보면 합성의 강력함을 실감할 수 있을 것이다. "}},{"id":"2dbOLIF9I1","type":"delimiter","data":{}},{"id":"-jWVWZEkUI","type":"header","data":{"text":"부가 정책 적용하기","level":2}},{"id":"gBmyQtwcvo","type":"paragraph","data":{"text":"일반 요금제를 적용한 경우에 생성된 인스턴스의 관계를 살펴보자. 그림에서 알수 있는 것처럼 컴파일 시점의 Phone 클래스와 RatePolicy 인터페이스 사이의 관계가 런타임에 Phone 인스턴스와 RegularPolicy 인스턴스 사이의 관계로 대체됐다는 것을 알 수 있다. "}},{"id":"zXPCzvvOUS","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/기본_요금제의_인스턴스_관계.png"}}},{"id":"kj7SD3cbRA","type":"paragraph","data":{"text":"지금부터 할 일은 여기에 부가 정책을 추가하는 것이다. 부가 정책은 기본 정책에 대한 계산이 끝난 후에 적용된다는 것을 기억하라. 만약 그림에 세금 정책을 추가한다면 세금 정책은 RegularPolicy 의 계산이 끝나고 Phone 에게 반환되기 전에 적용돼야 한다. 따라서 아래와 같이 RegularPolicy 와 Phone 사이에 세금 정책을 구현하는 TaxablePolicy 인스턴스를 연결해야 한다. "}},{"id":"vqOyqh67KW","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/기본_요금제에_세금_정책을_부과한_인스턴스_관계.png"}}},{"id":"2wrjC3d7Li","type":"paragraph","data":{"text":"만약 일반 요금제에 기본 요금 할인 정책을 적용한 후에 세금 정책을 적용해야 한다면 아래와 같은 순서로 인스턴스들을 연결해야 한다. "}},{"id":"9Yr4qmS58N","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/기본_요금제에_기본_요금할인정책을_적용_후_세금_정책_부과.png"}}},{"id":"ToHMYJYnJB","type":"paragraph","data":{"text":"위에 2개 그림은 다음의 2가지 제약에 따라 부가 정책을 구현해야 한다는 사실을 잘 보여준다"}},{"id":"bQJ9W6_IeS","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"부가 정책은 기본 정책이나 다른 부가 정책의 인스턴스를 참조할 수 있어야 한다. 다시 말해서 부가 정책의 인스턴스는 어떤 종류의 정책과도 합성 될 수 있어야 한다. ","meta":{},"items":[]}]}},{"id":"1yu6zmAyos","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"Phone 입장에서는 자신이 기본 정책의 인스턴스에게 메시지를 전송하고 있는지, 부가 정책의 인스턴스에게 메시지를 전송하고 있는지를 몰라야 한다. ","meta":{},"items":[]}]}},{"id":"LDR7ZEivs3","type":"paragraph","data":{"text":"요약하면 부가 정책은 RatePolicy 인터페이스를 구현해야 하며, 내부에 또 다른 ratePolicy 인스턴스를 합성할 수 있어야 한다. 부가 정책을 AdditionalRatePolicy 추상 클래스로 구현하자"}},{"id":"6OGfjB0wnY","type":"code","data":{"code":"public abstract class AdditionalRatePolicy implements RatePolicy {\n private RatePolicy next;\n\n public AdditionalRatePolicy(RatePolicy next) {\n this.next = next;\n }\n\n @Override\n public Money calculateFee(Phone phone) {\n Money fee = next.calculateFee(phone);\n return afterCalculated(fee);\n }\n\n abstract protected Money afterCalculated(Money fee);\n}"}},{"id":"ENEKD6EVHA","type":"paragraph","data":{"text":"Phone 의 입장에서 AdditionalRatePolicy 는 RatePolicy 의 역할을 수행하기 때문에 RatePolicy 인터페이스를 구현한다. 또한 다른 요금 정책과 조합될 수 있도록 RatePolicy 타입의 next 라는 이름을 가진 인스턴스 변수를 내부에 포함한다. "}},{"id":"STwbspEzAF","type":"paragraph","data":{"text":"AdditionalRatePolicy 는 컴파일타임 의존성을 런타임 의존성으로 쉽게 대체될 수 있도록 RatePolicy 타입의 인스턴스를 인자로 받는 생성자를 제공한다. 생성자 내부에서는 next 에 전달된 인스턴스에 대한 의존성을 주입한다. "}},{"id":"i2mTXsFDhT","type":"paragraph","data":{"text":"AdditionalRatePolicy 의 calculateFee 메서드는 먼저 next 가 참조하고 있는 인스턴스에게 calculateFee 메시지를 전송한다. 그 후 반환된 요금에 부가 정책을 적용하기 위해 afterCalculated 메서드를 호출한다. AdditionalRatePolicy 를 상속받은 자식 클래스는 aftercalculated 메서드를 오버라이딩해서 적절한 부가 정책을 구현할 수 있다. "}},{"id":"GtudKfq9am","type":"paragraph","data":{"text":"먼저 세금 정책부터 구현하자"}},{"id":"yTEaz3a25K","type":"code","data":{"code":"public class TaxablePolicy extends AdditionalRatePolicy {\n private double taxRatio;\n\n public TaxablePolicy(double taxRatio, ratePolicy next) {\n super(next);\n this.taxRatio = taxRatio;\n }\n\n @Override\n protected Money afterCalculated(Money fee) {\n return fee.plus(fee.times(taxRatio));\n }\n}"}},{"id":"COlbDwxwxZ","type":"paragraph","data":{"text":"아래 모든 요금 계산과 관련된 모든 클래스 사이의 관계를 다이어그램으로 표현한 것이다. "}},{"id":"4MHEscr7p5","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/기본정책과_부가_정택을_조합하는_상속구조.png"}}},{"id":"Ga0_YyVX7F","type":"paragraph","data":{"text":"모든 준비가 끝났다. 이제 구현된 정책들을 합성해보자. "}},{"id":"gwCa-Com1i","type":"delimiter","data":{}},{"id":"NpfwTt5tug","type":"header","data":{"text":"기본 정책과 부가 정책 합성하기","level":2}},{"id":"nH64krDmtY","type":"paragraph","data":{"text":"이제 다양한 방식으로 정책들을 조합할 수 있는 설계가 준비됐다. 남은 일은 원하는 정책의 인스턴스를 생성한 후 의존성 주입을 통해 다른 정책의 인스턴스에 전달하는 것 뿐이다. "}},{"id":"ih935Dkueh","type":"paragraph","data":{"text":"다음은 일반 요금제에 세금 정책을 조합할 경우의 Phone 인스턴스를 생성하는 방법을 나타낸것이다 "}},{"id":"ISfkG_ZUij","type":"code","data":{"code":"Phone phone = new Phone(new TaxablePolicy(0.05, new RegularPolicy(...)));"}},{"id":"_H9zR329az","type":"paragraph","data":{"text":"일반 요금제에 기본 요금 할인 정책을 조합한 결과에 세금 정책을 조합하고 싶다면 다음과 같이 Phone 을 생성하면 된다."}},{"id":"1RtaQ7PMu2","type":"code","data":{"code":"Phone phone = new Phone(new TaxablePolicy(0.05, \n\t new RateDiscountablePolicy(Money.wons(1000), \n\t new RegularPolicy(...))\n );"}},{"id":"npv-0kb-Rh","type":"paragraph","data":{"text":"혹시 세금 정책과 기본 요금 할인 정책이 적용되는 순서를 바꾸고 싶은가? 문제없다"}},{"id":"9AnPzlVwbw","type":"code","data":{"code":"Phone phone = new Phone(new RateDiscountablePolicy(Money.wons(1000),\n\t\t\t\tnew taxablePolicy(0.05), \n\t\t\t\tnew RegularPolicy(...))));"}},{"id":"xqGRARJfRI","type":"paragraph","data":{"text":"동일한 정책을 심야 할인 요금제에도 적용하고 싶은가? 간단하다."}},{"id":"bwPP-0nkaL","type":"code","data":{"code":"Phone phone = new Phone(new RateDiscountablePolicy(Money.wonds(1000),\n\t\t\t new TaxablePolicy(0.05),\n\t\t\t new NightlyDiscountPolicy(...))\n);"}},{"id":"lGphhbLJLF","type":"paragraph","data":{"text":"어떤가 그림을 보면 상속을 사용한 설계보다 복잡하고 정해진 규칙에 따라 객체를 생성하고 조합해야 하기 때문에 처음에는 코드를 이해하기 어려울 수도 있다. 하지만 일단 설계에 익숙해지고 나면 객체를 조합하고 사용하는 방식이 상속을 사용한 방식보다 더 예측 가능하고 일관성이 있다는 사실을 알게 될 것이다. "}},{"id":"Iak7IqwJ_D","type":"paragraph","data":{"text":"하지만 합성의 장점은 여기서 끝나지 않는다. 합성의 진가는 새로운 클래스를 추가하거나 수정하는 시점이 돼서야 비로소 알 수 있다. "}},{"id":"CKdMqK1aF3","type":"delimiter","data":{}},{"id":"4cPdb9RTGE","type":"header","data":{"text":"새로운 정책 추가하기 ","level":2}},{"id":"vEGNxBpbqo","type":"paragraph","data":{"text":"그림에서 살펴본 것 처럼 상속을 기반으로 한 설계에 새로운 부가 정책을 추가하기 위해서는 상속 계층에 불필요할 정도로 많은 클래스를 추가해야만 했다. 합성을 기반으로 한 설계에서는 이 문제를 간단하게 해결할 수 있다. "}},{"id":"MCaQ-ndph4","type":"paragraph","data":{"text":"고정 요금제가 필요하다면 고정 요금제를 구현한 클래스 '하나' 만 추가한 후 원하는 방식으로 조합하면 된다. "}},{"id":"bAoLkYxJ5s","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/image(8).png"}}},{"id":"IXeaKZOMdY","type":"paragraph","data":{"text":"약정 할인 정책이라는 새로운 부가 정책이 필요한가? 역시 클래스 하나만 추가하면 된다 "}},{"id":"JcVeZPtvGP","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/image(9).png"}}},{"id":"Xrgtvc44fi","type":"paragraph","data":{"text":"우리는 오직 하나의 클래스만 추가하고 런타임에 필요한 정책들을조합해서 원하는 기능을 얻을 수 있다."}},{"id":"PujJgsa9Xi","type":"paragraph","data":{"text":"이 설계를 필요한 조합의 수만큼 매번 새로운 클래스를 추가해야 했던 상속과 비교해보라. 왜 많은 사람들이 그렇게 코드 재사용을 위해 상속보다는 합성을 사용하라고 하는지 그 이유를 이해할 수 있을 것이다. "}},{"id":"MG_CryQ-0h","type":"paragraph","data":{"text":"더 중요한 것은 요구사항을 변경할 때 오직 하나의 클래스만 수정해도 된다는 것이다. 세금 정책을 변경한다고 생각해보라, 세금 정책을 다루는 코드가 상속 계층 여기저기에 중복돼 있던 그림에서는 세금 정책을 변경하기 위해 한번에 여러 클래스를 수정해야 한다. "}},{"id":"TuHl__blkm","type":"paragraph","data":{"text":"그에 비해 위 그림에서는 오직 TaxablePollicy 클래스 하나만 변경하면 된다. 변경 후의 설계는 단일 책임 원칙을 준수하고 있는 것이다. "}},{"id":"hsqKczGkbH","type":"delimiter","data":{}},{"id":"yEJp1y53xl","type":"header","data":{"text":" 객체 합성이 클래스 상속보다 더 좋은 방법이다","level":2}},{"id":"8_m_spfaP9","type":"paragraph","data":{"text":"객체지향에서 코드를 재사용하기 위해 가장 널리 사용되는 방법은 상속이다. 하지만 상속은 코드 재사용을 위한 우아한 해결책은 아니다. 상속은 부모 클래스의 세부적인 구현에 자식 클래스를 강하게 결합시키기 때문에 코드의 진화를 방해한다. "}},{"id":"l0snWGT3JX","type":"paragraph","data":{"text":"코드를 재사용하면서도 건전한 결합도를 유지할 수 있는 더 좋은 방법은 합성을 이용하는 것이다. 상속이 구현을 재사용하는 데 비해 합성은 객체의 인터페이스를 재사용한다. "}},{"id":"4fjUuqm_iz","type":"paragraph","data":{"text":"여기서 한 가지 의문이 들 것이다. 그렇다면 상속은 사용하면 안되는 것인가? 상속을 사용해야 하는 경우는 언제인가? 이 의문에 대답하기 위해서는 먼저 상속을 구현 상속과 인터페이스 상속의 두 가지로 나눠야 한다는 사실을 이해해야 한다. 그리고 이번 장에서 살펴본 상속에 대한 모든 단점들은 구현 상속에 국한된다는점 또한 이해해야 한다. "}},{"id":"fcWPV8c8E8","type":"paragraph","data":{"text":"13장에서는 인터페이스 상속이 이번 장에서 살펴본 구현 상속과 어떤 면에서 다른지 살펴볼 것이다. 13장을 읽고 나면 구현 상속을 피하고 인터페이스 상속을 사용해야하는 이유를 이해하게 될 것이다 ."}},{"id":"m_jVzjC16t","type":"paragraph","data":{"text":"다음 장으로 넘어가기 전에 코드를 재사용할 수 있는 유용한 기법을 한가지 더 살펴보기로 하자. 믹스인이라는 이름으로 널리 알려져 있는 이 기법은 상속과 합성의 특성을 모두 보유하고 있는 독특한 코드 재사용 방법이다. 믹스인을 이해하고 나면 상속과 합성의 장단점에 관해 좀 더 깊이 있게 이해하게 될 것이다. "}}],"version":"2.31.0-rc.7"}

Tag List