{"time":1752929601590,"blocks":[{"id":"Rwzo65gzps","type":"warning","data":{"title":"해당 글은 조영호님의 쓰신 Object 책을 읽고 챕터별로 정리해본 글입니다.","message":""}},{"id":"4vUPnvhOi8","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":"dfr6uqqFRA","type":"delimiter","data":{}},{"id":"mXMWMDWCbx","type":"paragraph","data":{"text":"객체는 협력을 위해 존재한다. 협력은 객체가 존재하는 이유와 문맥을 제공한다. 잘 설계된 애플리케이션은 이해하기 쉽고, 수정이 용이하며, 재사용가능한 렵력의 모임이다. 객체지향 설계의 목표는 적절한 책임을 수행하는 객체들의 협력을 기반으로 결합도가 낮고 재사용 가능한 코드 구조를 창조하는 것이다."}},{"id":"_KOhLR3cEa","type":"paragraph","data":{"text":"애플리케이션을 개발하다보면 유사한 요구사항을 반복적으로 추가하거나 수정하게 되는 경우가 있다. 이때 객체들의 협력 구조가 서로 다른 경우에는 코드를 이해하기도 어렵고 코드 수정으로 인해 버그가 발생할 위험성도 높아진다. "}},{"id":"jnsjefMmOx","type":"paragraph","data":{"text":"유사한 요구사항을 계속 추가해야하는 상황에서 각 협력이 서로 다른 패턴을 따를 경우에는 전체적인 설계의 일관성이 서서히 무너지게 된다. "}},{"id":"TNUdbW71VH","type":"paragraph","data":{"text":"객체지향 패러다임의 장점은 설계를 재사용할 수 있다는 것이다. 하지만 재사용은 공짜로 얻어지지 않는다. 재사용을 위해서는 객체들의 협력 방식을 일관성 있게 만들어야 한다. 일관성은 설계에 드는 비용을 감소시킨다. 과거의 해결 바법을 반복적으로 사용해서 유사한 기능을 구현하는 데 드는 시간과 노력을 대폭 줄일 수 있기 때문이다."}},{"id":"oBPWUQ79Wz","type":"paragraph","data":{"text":"일관성 있는 설계가 가져다 주는 더 큰 이익은 코드가 이해하기 쉬워진다는 것이다. 특정한 문제를 유사한 방법으로 해결하고 있다는 사실을 알면 문제를 이해하는 것 만으로도 코드의 구조를 예상할 수 있게 된다. "}},{"id":"G0ZZNgrKJe","type":"delimiter","data":{}},{"id":"gg1gKcoCMt","type":"header","data":{"text":"핸드폰 과금 시스템 변경하기","level":2}},{"id":"A06E0jVE1l","type":"header","data":{"text":"기본 정책 확장","level":3}},{"id":"iF4aDcVIH9","type":"paragraph","data":{"text":"11 장에서 구현한 핸드폰 과금 시스템의 요금 정책을 수정해야 한다고 가정하자. 지금까지 기본 정책에는 일반 요금제와 심야 할인 요금제의 두 가지 종류가 있었다. 이번 장에서는 기본 정책을 아래 표와 같이 4가지 방식으로 확장할 것이다. 부가 정책에 대한 요구사항은 변화가 없다."}},{"id":"Z00632cbq5","type":"table","data":{"withHeadings":false,"stretched":false,"content":[["유형","형식","예시"],["고정요금 방식","A 초당 B 원","10초당 18원"],["시간대별 방식","A 시부터 B시까지 C초당 D 원","00~19시 까지 10초당 18원"],["요일별 방식","평일에는 A 초당 B 원 공휴일에는 A 초당 C원","평일에는 10초당 38원공휴일에는 10초단 19원"],["구간별 방식","초기 A분 동안 B 초당 C원A~D 분까지 B 초당 D 원D 분 초과 시 B 초당 E 원","초기 1분 동안 10초당 50원초기 1분 이후 10초당 20원"]]}},{"id":"RiC4wxITh9","type":"paragraph","data":{"text":"기본 정책을 구성하는 4가지 방식에 관해 간단히 살펴보자."}},{"id":"tn2e9O_AHQ","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"고정요금 방식","meta":{},"items":[{"content":"일정 시간 단위로 동일한 요금을 부과하는 방식이다. 모든 통화에 대해 동일하게 10초당 9원을 부과하는 방식이 고정요금 방식의 예에 해당한다. 기존의 '일반 요금제' 와 동일하다.","meta":{},"items":[]}]}]}},{"id":"kVNUBJsP7T","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"시간대별 방식","meta":{},"items":[{"content":"하루 24시간을 특정 시간 구간으로 나눈 후 각 구간별로 서로 다른 요금을 부과하는 방식이다. 예를 들어 0시 ~ 19시 까지는 10초당 18원을, 19시 부터 24시까지는 10초당 15원의 요금을 부과하는 방식이다. 기존의 심야 할인 요금제는 밤 10시를 기준으로 요금을 부과한 시간대별 방식이다. ","meta":{},"items":[]}]},{"content":"요일별 방식","meta":{},"items":[{"content":"요일별로 요금을 차등 부과하는 방식이다. 이 방식을 사용하면 월요일 부터 금요일까지는 10초당 38원을, 토요일과 일요일에는 10초당 19원을 부과하는 요금제를 만들 수 있다. ","meta":{},"items":[]}]},{"content":"구간별 방식","meta":{},"items":[{"content":"전체 통화 시간을 일정한 통화 시간에 따라 나누고 각 구간별로 요금을 차등 부과하는 방식이다. 예를 들어, 통화 구간을 초기 1분과 1분 이후로 나눈 후 초기 1분 동안은 10초당 50원을, 그 이후에는 10초당 20원을 부과하는 방식이 구간별 방식에 해당한다. 만약 어떤 사용자의 전체 통화 시간이 60분이라면 처음 1분에 대해서는 10초는 50원이 부과되고 나머지 59분에 대해서는 10초당 20원의 요금을 부과될 것이다.","meta":{},"items":[]}]}]}},{"id":"xE8GfQdAAg","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/image(11).png"}}},{"id":"1wTSjqK-xX","type":"delimiter","data":{}},{"id":"L0lEnyL72x","type":"header","data":{"text":"고정요금 방식 구현하기","level":2}},{"id":"bgDlJ1MjYe","type":"paragraph","data":{"text":"가장 간단한 고정요금 방식부터 시작해보자. 고정요금 방식은 기존의 일반 요금제와 동일하기 때문에 기존의 RegularPolicy 클래스의 이름을 FIxedFeePolicy 로 수정하기만 하면 된다."}},{"id":"LNtgDfVmQE","type":"code","data":{"code":"public class FixedFeePolicy extends BasicratePolicy {\n private Money amount;\n private Duration seconds;\n\n public FixedFeePolicy(Money amount, Duration seconds) {\n this.amout = 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":"b905fFargq","type":"delimiter","data":{}},{"id":"WjrlhRPNNv","type":"header","data":{"text":"시간대별 방식 구현하기","level":2}},{"id":"Oax8pn2qYm","type":"paragraph","data":{"text":"시간대별 방식에 따라 요금에 계산하기 위해서는 통화 기간을 정해진 시간대별로 나눈 후 각 시간대별로 서로 다른 계산 규칙을 적용해야 한다. 0시부터 19시까지의 통화에 대해서는 10초당 18원의 요금을 부과하고, 19시부터 24시까지는 10초당 15원의 요금을 부과하는 시간대별 방식으로 구현하자고 하자."}},{"id":"NzIIBBM0pd","type":"paragraph","data":{"text":"가입자가 18시부터 20시까지 2시간 통안 통화를 했다면 18시~19시 1시간 동안의 통화에 대해서는 10초당 18원이 부과되고, 19~20시 1시간 동안의 통화에 대해서는 10초당 15원의 요금이 부과된다."}},{"id":"m-ydPe7g_Z","type":"paragraph","data":{"text":"여기서 한 가지 고려해야 할 조건이 있다. 만약 통화가 여러 날에 걸쳐서 이뤄진다면 어떻게 될까? 이 경우 시간대별 방식에 따라 요금을 구현하려면 규칙에 정의된 구간별로 통화를 구분해야 한다."}},{"id":"-6RZzZxtjI","type":"paragraph","data":{"text":"시간대별 방식을 구현하는 데 있어 핵심은 규칙에 따라 통화 시간을 분할하는 방법을 결정하는 것이다. 이를 위해 기간을 편하게 관리할 수 있는 DateTimeInterval 클래스를 추가하자. DateTimeInterval 은 시작 시간(from) 과, 종료 시간(to) 를 인스턴스 변수로 포함하며, 객체 생성을 위한 정적 메서드는 'of', 'toMidNight', 'fromMidNight', 'during' 을 제공한다"}},{"id":"gY3nbDaHuP","type":"code","data":{"code":"public class DateTimeInterval {\n private LocalDateTime from;\n private LocalDateTime to;\n\n public static DateTimeInterval of(LocalDateTime from, LocalDateTime to) {\n return new DateTimeInterval(from, to);\n }\n\n public static DateTimeInterval toMidnight(LocalDatetime from) {\n return new DateTimeInterval(from,\n LocalDateTime.of(from.toLocalDate(), LocalTime.of(23, 59, 59, 999_999_999)));\n }\n\n public static DateTimeInterval fromMidnight(LocalDatetime to){\n\t\treturn DateTimeInterval(LocalDateTime.of(to.toLocalDate(), LocalTime.of(0,0)),to));\n\t}\n\n public static DateTimeInterval during(LocalDate date) {\n return new DateTimeInterval(\n LocalDateTime.of(date, LocalTime.of(0, 0)),\n LocalDateTime.of(date, LocalTime.of(23, 59, 59, 999_999_999)));\n }\n\n private DateTimeInterval(LocalDateTime from, LocalDateTime to) {\n this.from = from;\n this.to = to;\n }\n\n public Duration duration() {\n return Duration.between(from, to);\n }\n\n public LocalDateTime getFrom() {\n return from;\n }\n\n public LocalDateTime getTo() {\n return to;\n }\n}"}},{"id":"cjFXzD3fDB","type":"paragraph","data":{"text":" 전체 통화 시간을 일자와 시간 기준으로 분할해서 계산해보자. 이를 위해 요금 계산 로직을 다음과 같이 두 개의 단계로 나눠 구현할 필요가 있다."}},{"id":"UGaaW8xugk","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":" 통화 기간을 일자로 분리한다.","meta":{},"items":[]},{"content":"일자별로 분리된 기간을 다시 시간대별로 분리한 후 각 기간에 대해 요금을 계산한다.","meta":{},"items":[]}]}},{"id":"wO2VPbME1s","type":"paragraph","data":{"text":"두 작업을 객체의 책임으로 할당해 보자. 책임을 할당하는 기본 원칙은 책임을 수행하는데 필요한 정보를 가장 잘 알고 있는 정보전문가에게 할당하는 것이다. 통화 기간을 일자 단위로 나누는 작업의 정보 전문가는 누군가? 통화 기간에 대한 정보를 가장 잘 알 고 있는 객체는 Call 이다. 하지만 Call 은 통화 기간은 잘 알지 몰라도 기간 자체를 처리하는 방법에 대해서는 전문가가 아니다."}},{"id":"2z1pVQRwQm","type":"paragraph","data":{"text":"기간을 처리하는 방법에 대한 저문가는 바로 DateTimeInterval 이다. 따라서 통화 기간을 일자 단위로 나누는 책임을 DateTimeInterval 에게 할당하고 Call 이 DateTimeInterval 에게 분할을 요청하도록 협력을 설계하는 것이 적절할 것이다."}},{"id":"wq0_H5R7w0","type":"paragraph","data":{"text":"두번째 작업인 시간대별로 분할하는 작업의 정보 전문가는 누구인가? 시간대별 기준을 잘 알고 있는 요금 정책 전문가는 TimeOfDayDiscountPolicy 라는 이름의 클래스로 구현할 것이다."}},{"id":"DTqXiUkQ6R","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/image(12).png"}}},{"id":"Z-rfGIMBJF","type":"paragraph","data":{"text":"이해를 돕기 위해 구체적인 예를 통해 분할 과정을 살펴보자. 0시부터 19시까지는 10초당 18원의 요금을 부과하고, 19시부터 24시까지 10초당 15원의 요금을 부과하는 시간대별 방식 요금제에 가입한 사용자가 1월1일 10시부터 1월3일 15시까지 3일에 걸쳐 통화를 했다고 가정해보자."}},{"id":"Id3fwd2Wcc","type":"paragraph","data":{"text":"앞에서 설명한 것처럼 시간대별 방식으로 요금을 계산하기 위해서는 우선 날짜별로 통화 시간을 분리해야 한다. "}},{"id":"h-FpVdIo4D","type":"paragraph","data":{"text":"Call 은 기간을 저장하고 있는 DateTimeInterval 타입의 인스턴스 변수인 interval 에게 splitByDay 메서드를 호출한다. splitByDay 메서드는 "}},{"id":"W5_w1HqBZ-","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"1/1일, 10 ~ 24 시","meta":{},"items":[]}]}},{"id":"0O52Jtb3A9","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"1/2일, 0 ~ 24 시","meta":{},"items":[]},{"content":"1/3일, 0~ 15 시","meta":{},"items":[]}]}},{"id":"K8alPmdaz6","type":"paragraph","data":{"text":"를 저장하는 3개의 DateTimeInterval 인스턴스를 포함하는 List 를 반환할 것이다. "}},{"id":"TWbKahd0Bj","type":"paragraph","data":{"text":"Call 은 이렇게 분리된 List 를 시간대별 방식을 위한 TimeOfDayDiscountPolicy 클래스에게 반환한다. TimeOfDayDiscountPolicy 클래스는 일자별로 분리된 각 DateTImeInterval 인스턴스들을 요금 정책에 정의된 각 시간대별로 분할한 후 요금을 부과한다."}},{"id":"LZeRfWybss","type":"paragraph","data":{"text":"첫 번째 통화 구간과 두번째 통화 구간은 조금 복잡하다. 1월1일 10시~24시 와 1월2일 0시~24시가 두 요금 규칙의 시간대에 걸쳐 있기 때문이다. 이 요금을 계산하기 위해서는 반환된 통화 구간을 다시 시간대별로 나뉘어진 시간대별로 요금을 계산한 합을 구해야한다."}},{"id":"a_7TMKZa_j","type":"paragraph","data":{"text":"따라서 통화 구간을 19시 기준으로 나누고 1월1일 10시~19시와 1월2일 0시~19시는 10초당 18원으로, 1월1일 19~24시 와 1월2일 19~24시 까지는 10초당 15원으로 요금을 계산해야 한다. 세번째 통화 구간인 1월3일 0시~15시는 전체가 0시부터 19시 사이에 포함되기 때문에 전체 구간에 대해 10초당 18원의 요금 규칙을 적용하면 될 것이다."}},{"id":"vvBWZ6exDb","type":"paragraph","data":{"text":"결과적으로 1/1 10시 ~ 1/3 15시 까지의 통화 요금을 계산하기 위한 전체 통화 기간은 아래처럼 5개로 분리된다."}},{"id":"ezmIzSDyh9","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":" 1/1 10~19 시 ","meta":{},"items":[]}]}},{"id":"-l1tPMjGni","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"1/1 19~24 시","meta":{},"items":[]}]}},{"id":"pnknwWSkx7","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"1/2 0~19 시","meta":{},"items":[]}]}},{"id":"ut1tOMmp3-","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"1/2 19~24시","meta":{},"items":[]}]}},{"id":"r0CdGY-uG4","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"1/3 0~15 시 ","meta":{},"items":[]}]}},{"id":"b_C6x5JruY","type":"paragraph","data":{"text":"이제 대략적인 로직을 살펴봤으므로 TimeOfDayDiscountPolicy 클래스를 구현해보자 시간대별 방식을 담당한 개발자는 이 문제를 4개의 서로 다른 List 를 가지는 것으로 해결했다. TimeOfDayDiscountPolicy 클래스는 시작 시간의 List, 종료시간의 List, 단위 시간의 List, 단위 요금의 List를 포함하며 같은 규칙에 포함된 요소들은 List 안에서 동일한 인덱스에 위치하게 된다."}},{"id":"siL2eI68Gt","type":"code","data":{"code":"public class TimeOfDayDiscountPolicy extends BasicPolicy {\n\tprivate List starts = new ArrayList<>();\n\tprivate List ends = new ArrayList<>();\n\tprivate List durations = new ArrayList<>();\n\tprivate List amounts = new ArrayList<>();\n}"}},{"id":"XZAvw1BNdG","type":"table","data":{"withHeadings":false,"stretched":false,"content":[["요소","인덱스 0 ","인덱스 1"],["starts","00:00","19:00"],["ends","19:00","24:00"],["durations","10초","10ch"],["amounts","18원","15원"]]}},{"id":"INRi5SeKK_","type":"paragraph","data":{"text":"다음은 TimeOfDayDiscountPolicy 클래스의 전체 코드를 나타낸 것이다. 지금까지 설명한 내용을 이해했다면 큰 무리없이 코드를 이해할 수 있을 것이다. "}},{"id":"G0TWBx2mYT","type":"code","data":{"code":"public class TimeOfDayDiscountPolicy extends BasicRatePolicy {\n private List starts = new ArrayList<>();\n private List ends = new ArrayList<>();\n private List durations = new ArrayList<>();\n private List amounts = new ArrayList<>();\n\n @Override\n protected Money calculateCallFee(Call call){\n Money result = Money.ZERO;\n for(DateTimeInterval interval : call.splitByDay()){\n for(int loop =0; loop < starts.size(); loop++){\n result.plus(amounts.get(loop).times(\n Duarion.between(from(interval, starts.get(loop)), to(interval, ends.get(loop)))\n .getSeconds() / durations.get(loop).getSeconds();\n ));\n }\n return result;\n }\t\t\n }\n\n private LocalTime from(DateTimeInterval interval, LocalTime from) {\n return interval.getFrom().toLocalTime().isBefore(from) ? from : interval.getFrom().toLocalTime();\n }\n\n private LocalTime to(DateTimeInterval interval, LocalTime to) {\n return interval.getTo().toLocalTime().isAfter(to) ? to : interval.getTo().toLocalTime();\n }\n}"}},{"id":"6oIBsf4V4T","type":"paragraph","data":{"text":"Call 의 splitByDay 메서드는 DateTimeInterval 에 요청을 전달한 후 응답을 반환하는 간단한 위임 메서드다."}},{"id":"iwE-dogZOI","type":"code","data":{"code":"public class Call {\n public List splitByDay(){\n return interval.splitByDat();\n }\n}"}},{"id":"25lSte1IBw","type":"paragraph","data":{"text":"DateTimeInterval 클래스의 splitByDay 메서드는 통화 기간을 일자별로 분할해서 반환한다. days 메서드는 from 과 to 사이에 포함된 날짜 수를 반환한다. 만약 days 메서드의 반환값이 1보다 크다면 split 메서드를 호출해서 날짜 수만큼 분리한다. 만약 days 메서드의 반환값이 1이라면 (하루 안의 기간이라면) 현재의 DateTimeInterval 인스턴스를 리스트에 담아 그대로 반환한다 "}},{"id":"dtaG6LuzWz","type":"code","data":{"code":"public class DateTImeInterval {\n public List splitByDay() {\n if (days() > 0) {\n return splitByDay(days());\n }\n\n return Arrays.asList(this);\n }\n\n private long days() {\n return Duration.between(from.toLocalDate().asStartOfDay(), to.toLocalDate().asStartOfDay()).toDays();\n }\n\n private List splitByDay(long days) {\n List result = new ArrayList<>();\n addFirstDay(result);\n addMiddelDays(result, days);\n addLastDay(result);\n return result;\n }\n\n private void addFirstDay(List result) {\n result.add(DateTimeInterval.toMidNight(from));\n }\n\n private void addMiddleDays(List result, long days) {\n for (int loop = 1; loop < days; loop++) {\n result.add(DateTimeInterval.during(from.toLocalDate().plusDays(loop)));\n }\n }\n\n private void addLastDay(List result) {\n result.add(DateTimeInterval.fromMidnight(to));\n }\n}"}},{"id":"p59VeuOXE1","type":"delimiter","data":{}},{"id":"1w7GLt7uVT","type":"header","data":{"text":"요일별 방식 구현하기 ","level":2}},{"id":"NLlo9l7i5j","type":"paragraph","data":{"text":"요일별 방식은 요일별로 요금 규칙을 다르게 설정할 수 있다. 각 규칙은 요일의 목록, 단위 시간, 단위 요금이라는 세 가지 요소로 구성된다. 요일별 방식을 사용하면 월요일부터 금요일까지는 10초당 38원 , 토요일과 일요일은 10초당 19원을 부과하는 식으로 요금정책을 설정할 수 있다. "}},{"id":"DGuW84O3qX","type":"paragraph","data":{"text":"먼저 요일별 방식을 구성하는 규칙들을 구현해야 한다. 시간대별 방식을 개발한 프로그래머는 4개의 List 를 이용해서 규칙을 정의했지만 요일별 방식을 개발하는 프로그래머는 규칙 DayOfWeekDiscountRule 이라는하나의 클래스로 구현하는 것이 더 나은 설계라고 판단했다."}},{"id":"TG1zUNt49V","type":"paragraph","data":{"text":"예상할 수 있겠지만 DayOfWeekDiscountrule 클래스는 규칙을 정의하기 위해 필요한 요일의 목록 (dayOfWeek) , 단위시간 (duration), 단위 요금 (amount) 을 인스턴스 변수로 포함한다. calculate 메서드는 파라미터로 전달된 interval 이 요일 조건을 만족시킬 경우 단위 시간과 단위 요금을 이용해 통화 요금을 계산한다. "}},{"id":"Py5apRzLc3","type":"code","data":{"code":"public class DayOfWeekDiscountRule {\n private List dayOfWeeks = new ArrayList<>();\n private Duration duration = Duration.ZERO;\n private Money amount = Money.ZERO;\n\n public DayOfWeekDiscountRule(List dayOfWeeks, Duration duration, Money amount){\n this.dayOfWeeks = dayOfWeeks;\n this.duration = duration;\n this.amount = amount;\n }\n\n public Money calculate(DateTimeInterval interval) {\n if (dayOfWeeks.contains(interval.getFrom().getDayOfWeek())) {\n return amount.times(interval.duration().getSeconds() / duration.getSeconds());\n }\n\n return Money.ZERO;\n }\n}"}},{"id":"hCSAooX0i_","type":"delimiter","data":{}},{"id":"TUeCFmRpyf","type":"header","data":{"text":"구간별 방식 구현하기 ","level":2}},{"id":"ubg3bY5GyY","type":"paragraph","data":{"text":"이제 구간별 방식만 남았다. 잠시 숨을 고르고 지금까지 작업한 고정요금 방식, 시간대별 방식, 요일별 방식의 구현 클래스를 천천히 살펴보자. FixedFeePolicy, TimeOfDayDiscountPolicy, DayOfWeekDiscountPolicy 의 세 클래스는 통화 요금을 정확하게 계산하고 있고 응집도와 결합도 측면에서도 특별히 문제는 없어 보인다. 클래스들을 따로 털어트려 놓고 살펴보면 그럭저럭 괜찮은 구현으로 보이기까지 한다. 하지만 이 클래스들을 함께 모아놓고 보면 그동안 보이지 않던 문제점이 보이기 시작한다. "}},{"id":"AWdM_F6gfh","type":"paragraph","data":{"text":"뒤에서 좀 더 자세히 살펴보겠지만 현재 구현의 가장 큰 문제점은 이 클래스들이 유사한 문제를 해결하고 있음에도 불구하고 설계에 일관성이 없다는 것이다. 이 클래스들은 기본 정책을 구현한다는 공통의 목적을 공유한다. 하지만 정책을 구현하는 방식이 완전히 다르다. 다시 말해서 개념적으로는 연관돼 있지만 구현 방식에 있어서는 완전히 제각각이라는 것이다. "}},{"id":"i8Rpep1Wxu","type":"paragraph","data":{"text":"비일관성은 두 가지 상황에서 발목을 잡는다. 하나는 새로운 구현을 추가해야 하는 상황이고, 또 다른 하나는 기존의 구현을 이해해야 하는 상황이다. 그리고 이 장애물이 문제인 이유는 개발자로서 우리가 수행하는 대부분의 활동이 코드를 추가하고 이해하는 일과 깊숙이 연관돼 있기 때문이다 ."}},{"id":"7ke07cUmbe","type":"code","data":{"code":"public class DuarationDiscountRule extends FixedFeePolicy {\n private Duration from;\n private Duration to;\n\n public DurationDiscountRule(Duration from, Duration to, Money amount, Duration seconds){\n super(amount, seconds);\n this.from = from;\n this.to = to;\n }\n\n public Money calculate(Call call){\n if(call.getDuration().compareTo(to) > 0){\n return Money.ZERO;\n }\n if(call.getDuration().compareTo(from) < 0){\n return Money.ZERO;\n }\n\n Phone phone = new Phone(null);\n phone.call(new Call(call.getFrom().plus(from), \n call.getDuration().compareTo(to) > 0 ? call.getFrom().plus(to) : call.getTo()));\n\n return super.calculateFee(phone);\n }\n}"}},{"id":"iygOc8NK4t","type":"paragraph","data":{"text":"이제 여러 개의 DurationDiscountRule 을 이용해 DurationDiscountPolicy 를 구현할 수 있다. "}},{"id":"2NaJmHAzwy","type":"code","data":{"code":"public class DurationDiscountPolicy extends BasicratePolicy {\n private List rules = new ArrayList<>();\n\n public DurationDiscountPolicy(List rules) {\n this.rules = rules;\n }\n\n @Override\n protected Moeny calculateCallFee(Call call) {\n Money result = Money.ZERO;\n for (DurationDiscountRule rule : rules) {\n result.plus(rule.calculate(call));\n }\n return result;\n }\n}"}},{"id":"DTVXRQasf6","type":"paragraph","data":{"text":"DurationDiscountPolicy 클래스는 할인 요금을 정상적으로 게산하고, 각 클래스는 하나의 책임만을 수행한다. 하지만 이 설계를 훌륭하다고 말하기는 어려운데 기본 정책을 구현하는 기존 클래스들과 일관성이 없기 때문이다. "}},{"id":"6f7hEpp_Cb","type":"delimiter","data":{}},{"id":"swVD35R3Sk","type":"header","data":{"text":"설계에 일관성 부여하기","level":2}},{"id":"j5jaJmhTm5","type":"paragraph","data":{"text":"일관성 있는 설계를 만드는데 가장 훌륭한 조언은 다양한 설계 경험을 익히는 것이다. 풍부한 설계경험을 가진 사람은 어떤 변경이 중요한지, 그리고 그 변경을 어떻게 다뤄야 하는지에 대한 통찰력을 가지게 된다. 따라서 설계 경험이 풍부하면 풍부할수록 어떤 위치에서 일관성을 보장해야 하고 일관성을 제공하기 위해 어떤 방법을 사용해야 하는지를 직관적으로 결정할 수 있다. 하지만 이런 설계 경험을 단기간에 쌓아 올리는 것은 생각보다 어려운 일이다. "}},{"id":"dD8x_Npo6W","type":"paragraph","data":{"text":"일관성 있는 설계를 위한 두번쨰 조언은 널리 알려진 디자인 패턴을 학습하고 변경이라는 문맥 안에서 디자인 패턴을 적용해 보라는 것이다."}},{"id":"ENPsA2rpIu","type":"paragraph","data":{"text":"비록 디자인 패턴이 반복적으로 적용할 수 있는 설계 구조를 제공한다고 하더라도 모든 경우에 적합한 패턴을 찾을 수 있는 것은 아니다. 따라서 협력을 일관성 있게 만들기 위해 다음과 같은 기본 지침을 따르는 것이 도움이 될 것이다. "}},{"id":"iryXtGRiS9","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"변하는 개념을 변하지 않는 개념으로부터 분리하라.","meta":{},"items":[]}]}},{"id":"_uaVI8RDnU","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"변하는 개념을 캡슐화 하라 ","meta":{},"items":[]}]}},{"id":"cEN3zxQcAV","type":"paragraph","data":{"text":"사실 이 두 가지 지침은 훌륭한 구조를 설계하기 위해 따라야 하는 기본적인 원칙이기도 하다, 지금까지 이 책에서 설명했던 모든 원칙과 개념들 역시 대부분 변경의 캡슐화라는 목표를 향한다"}},{"id":"W8Tt1kN6KM","type":"delimiter","data":{}},{"id":"toTD_dtVvP","type":"customHeader","data":{"text":"변하는 부분을 분리해서 타입 계층을 만든다"}},{"id":"7pTZ5xhQ3R","type":"paragraph","data":{"text":"변하지 않는 부분으로부터 변하는 부분을 분리한다. 변하는 부분들의 공통적인 행동을 추상 클래스나 인터페이스로 추상화한 후 변하는 부분들이 이 추상 클래스나 인터페이스를 상속받게 만든다. 이제 변하는 부분은 변하지 않는 부분의 서브타입이 된다. 영화 예매 시스템에서 DiscountPolicy 를 추상클래스로, DiscountCondition 을 인터페이스로 구현한 점을 눈여겨 보기바란다."}},{"id":"EG20LoQleF","type":"delimiter","data":{}},{"id":"tI6kmsUD8F","type":"customHeader","data":{"text":"변하지 않는 부분의 일부로 타입 계층을 합성한다"}},{"id":"X-dzIjaE4Y","type":"paragraph","data":{"text":"앞에서 구현한 타입 계층을 변하지 않는 부분에 합성한다. 변하지 않는 부분에서는 변경되는 구체적인 사항에 결합돼서는 안된다. "}},{"id":"4q0PLpwAp7","type":"paragraph","data":{"text":"의존성 주입과 같이 결합도를 느슨하게 유지할 수 있는 방법을 이용해 오직 추상화에만 의존하게 만든다. 이제 변하지 않는 부분은 변하는 부분의 구체적인 종류에 대해서는 알지 못할 것이다. 변경이 캡슐화된 것이다. Movie가 DiscountPolicy 를 합성 관계로 연결하고 생성자를 통해 의존성을 해결한 이유가 바로 이 때문이다. "}},{"id":"g8ZVCTM-x5","type":"delimiter","data":{}},{"id":"tFU5lIBBCj","type":"header","data":{"text":"일관성 있는 기본 정책 구현하기","level":2}},{"id":"M_bHIm8_N0","type":"header","data":{"text":"변경 분리하기","level":3}},{"id":"J8VzQWs3JP","type":"paragraph","data":{"text":"일관성 있는 협력을 만들기 위한 첫번째 단계는 변하는 개념과 변하지 않는 개념을 분리하는 것이다. 그렇다면 핸드폰 과금 시스템의 기본 정책에서 변하는 부분과 변하지 않는 부분은 무엇인가? 이 질문에 답하기 위해서는 기본 정책의 요구사항을 정리해 볼 필요가 있다 ."}},{"id":"5w5sccBoQv","type":"paragraph","data":{"text":"표는 기본 정책을 구성하는 각 방식별 요금 규칙을 정리한 것이다. 표시된 시간대별, 요일별, 구간별 방식의 패턴을 살펴보면 어느 정도 유사한 형태를 띈다는 것을 알 수 있다. 고정요금 방식은 이 세가지 방식과는조금 다르기 때문에 뒤에서 다시 살펴보겠다."}},{"id":"3j2DuxW3tU","type":"table","data":{"withHeadings":false,"stretched":false,"content":[["방식","예시","규칙"],["고정요금 방식","10초당 18월","[단위시간] 당 [요금] 원"],["시간대별 방식","00~ 19 시까지 10초당 18원19~ 24 사까지 10초당 15원","[시작시간] ~ [종료시간] 까지[단위시간] 당 [요금] 원"],["요일별 방식","평일 10초당 38원공휴일 10초당 19원","[요일] 별[단위시간] 당 [요금] 원"],["구간별 방식","초기 1분 동안 1분당 50원초기 1분 이후 10초당 20원","[통화구간] 동안[단위시간] 당 [요금] 원"]]}},{"id":"IBccecWfVO","type":"paragraph","data":{"text":"먼저 시간대별, 요일별 구간별 방식의 공통점은 각 기본 정책을 구성하는 방식이 유사하다는 것이다. "}},{"id":"VsawYwJV_X","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"기본 정책은 한 개 이상의 규칙으로 구성된다","meta":{},"items":[]}]}},{"id":"U2LZ-n3FS0","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"하나의 규칙은 '적용조건' 과 '단위요금' 의 조합이다 ","meta":{},"items":[]}]}},{"id":"duYg1tt8gY","type":"paragraph","data":{"text":"시간대별, 요일별, 구간별 방식은 하나 이상의 '규칙' 들의 집합이라는 공통점을 가진다. 이미 눈치챘겠지만, 시간대별, 요일별, 구간별 방식의 차이점은 각 기본 정책별로 요금을 계산하는 '적용조건' 의 형식이 다르다는 것이다. 모든 규칙에 '적용 조건' 이 포함된다는 사실은 변하지 않지만 실제 조건의 세부적인 내용은 다르다."}},{"id":"nSpmFHe9J5","type":"paragraph","data":{"text":"공통점은 변하지 않는 부분이다. 차이점은 변하는 부분이다. 우리의 목적은 변하지 않는 것과 변하는 것을 분리하는 것이라는 점을 기억하라. 따라서 변하지 않는 '규칙' 으로 부터 변하는 '적용 조건'을 분리해야한다."}},{"id":"4eQD6-3ODE","type":"delimiter","data":{}},{"id":"_XbnLuxNom","type":"header","data":{"text":"변경 캡슐화 하기 ","level":2}},{"id":"yAdTu75H_t","type":"paragraph","data":{"text":"협력을 일관성 있게 만들기 위해서는 변경을 캡슐화해서 파급효과를 줄여야 한다. 변경을 캡슐화하기 가장 좋은 방법은 변하지 않는 부분으로부터 변하는 부분을 분리하는 것이다. 물론 변하는 부분의 공통점을 추상화하는 것도 잊어서는 안된다. 이제 변하지 않는 부분이 오직 이 추상화에만 의존하도록 관계를 제한하면 변경을 캡슐화 할 수 있게 된다. "}},{"id":"-JjgaRjjLq","type":"paragraph","data":{"text":"여기서 변하지 않는 것은 '규칙' 이다. 변하는 것은 '적용 조건' 이다 따라서 '규칙' 으로부터 '적용조건' 을 분리해서 추상화한 후 시간대별, 요일별, 구간별 방식을 이 추상화의 서브타입으로 만든다. 이것이 서브타입 캡슐화다. 그 후에 적용조건을 표현하는 추상화를 합성 관계로 연결한다. 이것이 객체 캡슐화다. "}},{"id":"AMtArTjacw","type":"paragraph","data":{"text":"그림은 개별 '규칙' 을 구성하는 데 필요한 클래스들의 관계를 나타낸 것이다, 하나의 기본 정책은 하나 이상의 '규칙' 들로 구성된다. 따라서 기본 정책을 표현하는 BasicRatePolicy 는 FeeRule 의 컬렉션을 포함한다. "}},{"id":"Rbz3E5M7Hs","type":"paragraph","data":{"text":"FeeRule 은 '규칙' 을 구현하는 클래스이며 '단위 요금' 은 FeeRule 의 인스턴스 변수인 FeePerDuration 에 저장돼 있다. FeeCondition 은 '적용조건' 을 구현하는 인터페이스이며 변하는 부분을 캡슐화하는 추상화다. "}},{"id":"8ZFLa0QM3a","type":"paragraph","data":{"text":"각 기본 정책별로 달라지는 부분은 각각의 서브타입으로 구현된다. "}},{"id":"2nbNryctr8","type":"paragraph","data":{"text":"FeeRule 이 FeeCondition 을 합성 관계로 연결하고 있다는 점에 주목하라. FeeRule 이 오직 FeeCondition 에만 의존하고 있다는 점도 주목하라. FeeRule 은 FeeCondition 의 어떤 서브타입도 알지 못한다. 따라서 변하는 FeeCondtion 의 서브타입은 변하지 않는 FeeRule 로부터 캡슐화된다. "}},{"id":"kUcshP82Zj","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/image(17).png"}}},{"id":"dSTcgOAr0z","type":"paragraph","data":{"text":"정리해보자. 이 도메인 모델은 앞에서 설명한 것 처럼 변하지 않는 부분으로부터 변하는 부분을 효과적으로 분리한다. 변하지 않는 부분은 기본 정책이 여러 '규칙' 들의 집합이며, 하나의 규칙은 '적용조건' 과 '단위요금' 으로 구성된다는 것이다. 이 관계는 BasicRatePolicy , FeeRule, FeeCondition 의 조합으로 구현된다. "}},{"id":"XjArmMmVJO","type":"paragraph","data":{"text":"변하는 부분은 '적용조건' 의 세부적인 내용이다. 이것은 FeeCondition 의 서브타입인 TimeOfDayFeeCondition, DayOfWeekFeeCondition, DurationFeeConditiom 으로 구현된다. 그리고 FeeRule 은 추상화인 FeeCondition 에 대해서만 의존하기 때문에 '적용조건' 이 변하더라도 영향을 받지 않는다. 즉 '적용조건' 이라는 변경에 대해 캡슐화돼 있다. "}},{"id":"bNH4DBz_0T","type":"delimiter","data":{}},{"id":"PdQJ7VWXj7","type":"header","data":{"text":"협력 패턴 설계하기 ","level":2}},{"id":"BR6PCN1Nui","type":"paragraph","data":{"text":"이제 객체들의 협력 방식을 고민해보자. 변하는 부분과 변하지 않는 부분을 분리하고, 변하는 부분을 적절히 추상화하고 나면 변하는 부분을 생략할 채 변하지 않는 부분만을 이용해 객체 상의 협력을 이야기 할 수 있다. "}},{"id":"RPXbEZkXax","type":"paragraph","data":{"text":"추상화만으로 구성한 헙력은 추상화를 구체적인 사례로 대체함으로써 다양한 상황으로 확장할 수 있다. 다시 말해서 재사용 가능한 협력 패턴이 선명하게 드러나는 것이다. 그림은 이런 변하지 않는 추상화만을 남길 것이다., "}},{"id":"q7Ste69oVI","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/image(18).png"}}},{"id":"CekOxjWiMU","type":"paragraph","data":{"text":"아래 그림은 이 추상화들이 참여하는 협력을 나타낸 것이다. 협력은 BasicRatePolicy 가 calculateFee 메시지를 수신했을 때 시작된다. BasicRatePolicy 의 calculateFee 메서드는 인자로 전달받은 통화 목록 (List Call) 타입의 전체 요금을 계산한다. BasicRatePolicy 는 목록에 포함된 각 Call 별로 FeeRule 의 CalculateFee 메서드를 실행한다. "}},{"id":"U4Pq9bZOex","type":"paragraph","data":{"text":"하나 이상의 FeeRule 로 구성되기 때문에 Call 하나당 FeeRule 에 다수의 calculateFee 메서지가 전송된다, "}},{"id":"w9ezlIdNSR","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/image(19).png"}}},{"id":"H1Hwavm_0V","type":"paragraph","data":{"text":"FeeRule 은 하나의 Call 에 대해 요금을 계산하는 책임을 수행한다. 현재 FeeRule 은 단위 시간당 요금인 feePerDuration 과 요금을 적용할 조건을 판단하는 적용조건인 FeeCondition 의 인스턴스를 알고 있다. "}},{"id":"vRUbvsu2Op","type":"paragraph","data":{"text":"하나의 Call 요금을 계산하기 위해서는 두 개의 작업이 필요하다 "}},{"id":"oD43ZWpjNj","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"하나는 전체 통화 시간을 각 '규칙' 의 '적용조건' 을 만족하는 구간들로 나누는 것이다. ","meta":{},"items":[]}]}},{"id":"nZHbmkSlT7","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"다른 하나는 이렇게 분리된 통화 구간에 대해 '단위 요금' 을 적용해서 요금을 계산하는 것이다, ","meta":{},"items":[]}]}},{"id":"szP2zYzOV9","type":"paragraph","data":{"text":"객체지향에서는 모든 작업을 객체의 책임으로 생각하기 때문에 이 두 개의 책임을 객체에게 할당하자. 전체 통화 시간을 각 '규칙' 의 '적용조건' 을 만족하는 구간들로 나누는 첫 번째 작업은 '작업조건' 을 가장 잘 알고 있는 정보 전문가인 FeeCondition 에게 할당하는 것이 적절할 것이다. 이렇게 분리된 통화 구간에 '단위 요금' 을 계산하는 두 번째 작업은 '요금기준'의 정보 전문가인 FeeRule 이 담당하는 것이 적절할 것이다, "}},{"id":"MUtqyvF8lm","type":"delimiter","data":{}},{"id":"WfQ2VRgp1I","type":"header","data":{"text":"추상화 수준에서 협력 패턴 구현하기","level":2}},{"id":"iPOngYOJ6A","type":"paragraph","data":{"text":"먼저 '적용조건' 을 표현하는 추상화인 FeeCondtion 에서 시작하자. FeeCondition 은 findTimeIntervals 라는 단 하나의 오퍼레이션을 포함하는 간단한 인터페이스다. 이 오퍼레이션은 인자로 전달된 Call 의 통화 기간 중에서 '적용조건' 을 만족하는 기간을 구한 후 List 에 담아 반환한다"}},{"id":"FWMkrb4jtO","type":"code","data":{"code":"public interface FeeCondition {\n List findTimeIntervals(Call call);\n}"}},{"id":"L27l0xOa73","type":"paragraph","data":{"text":"FeeRule 은 '단위요금(feePerDuration) 과 '적용조건(FeeCondition)' 을 저장하는 두 개의 인스턴스 변수로 구성된다. FeeRule 의 calculateFee 메서드는 FeeCondition 에게 findTimeIntervals 메서드를 전달해서 조건을 만족하는 시간의 목록을 반환받은 후 feePerDuration 의 값을 이용해 요금을 계산한다. "}},{"id":"M8OWo6EmXD","type":"code","data":{"code":"public class FeeRule {\n private FeeCondition feeCondition;\n private FeePerDuration feePerDuration;\n\n public FeeRule(FeeCondition feeCondition, FeePerDuration feePerDuration) {\n this.feeCondition = feeCondition;\n this.feePerDuration = feePerDutration;\n }\n\n public Money calcluateFee(Call call) {\n return feeCondition.findTimeIntervals(call).stream()\n .map(each -> feePerDuration.calculate(each))\n .reduce(Money.ZERO, (first, second) -> first.plus(second));\n }\n}"}},{"id":"tLDfbvTJl9","type":"paragraph","data":{"text":"FeePerDuration 클래스는 \"단위시간당 요금\" 이라는 개념을 표현하고 이 정보를 이용해 일정기간 동안의 요금을 계산하는 calculate 메서드를 구현한다 "}},{"id":"meMA5wajut","type":"code","data":{"code":"public class FeePerDuration {\n private Money fee;\n private Duration duration;\n\n public FeePerDuration(Money fee, Duration duration) {\n this.fee = fee;\n this.duration = duration;\n }\n\n public Money calculate(DateTimeInterval interval){\n return fee.times(Math.ceil((double) interval.duration().toNanos() / duration.toNanos()));\n }\n}"}},{"id":"J3w7-izEex","type":"paragraph","data":{"text":"이제 BasicRatePolicy 가 FeeRule 의 컬렉션을 이용해 전체 통화 요금을 계산하도록 수정할 수 있다. "}},{"id":"3EuoN3x82G","type":"code","data":{"code":"public class BasicRatePolicy implements RatePolicy {\n private List feeRules = new ArrayList<>();\n\n public BasicRatePolicy(FeeRule... feeRules) {\n this.feeRules = feeRules;\n }\n\n @Override\n public Money calculateFee(Phone phone) {\n return phone.getCalls().stream()\n .map(call -> calculate(call))\n .reduce(Money.ZERO, (first, second) -> first.plus(second));\n }\n\n private Money calculate(Call call) {\n return feeRules.stream()\n .map(rule -> rule.calculateFee(call))\n .reduce(Money.ZERO, (first, second) -> first.plus(second));\n }\n}"}},{"id":"kwqXANB7XB","type":"paragraph","data":{"text":"지금까지 구현한 클래스와 인터페이스는 모두 변하지 않는 추상화에 해당한다, 이 요소들을 조합하면 전체적인 협력 구조가 완성된다. 다시 말해서 변하지 않는 요소와 추상적인 요소만으로도 요금 계산에 필요한 전체적인 협력 구조를 설명할 수 있다는 것이다. 이것이 핵심이다"}},{"id":"Z-llsnajNV","type":"delimiter","data":{}},{"id":"4J06WtmIf4","type":"header","data":{"text":"구체적인 협력 구현하기","level":2}},{"id":"uQsU-kPgBK","type":"header","data":{"text":"시간대별 정책 ","level":3}},{"id":"ggFwhdNcbw","type":"code","data":{"code":"public class TimeOfDayFeeCondition implements FeeCondition {\n private LocalTime from;\n private LocalTime to;\n\n public TimeOfDayFeeCondition(LocalTime from, LocalTime to) {\n this.from = from;\n this.to = to;\n }\n\n @Override\n\tpublic List findTimeIntervals(Call call){\n return call.getInterval().splitByDay().stream()\n .filter(each -> from(each).isBefore(to(each)))\n .map(each -> DateTimeInterval.of(\n LocalDateTime.of(each.getFrom().toLocalDate(), from(each)),\n LocalDateTIme.of(each.getTo().toLocalDate(), to(each))))\n .collect(Collectors.toList());\n }\n\n private LocalTime from(DateTimeInterval interval) {\n return interval.getFrom().toLocalTime().isBefore(from) ? from : interval.getFrom().toLocalTIme();\n }\n\n private LocalTime to(DateTImeInverval interval) {\n return interval.getTo().toLocalTime().isAfter(to) ? to : interval.getTo().toLocalTime();\n }\n}"}},{"id":"SFR2OCcZx1","type":"header","data":{"text":"요일별 정책","level":3}},{"id":"HlwOxgt1qR","type":"code","data":{"code":"public class DayOfWeekCondition implements FeeCondition {\n private List dayOfWeeks = new ArrayList<>();\n\n public DayOfWeekCondition(DayOfWekk... dayOfWeeks) {\n this.dayOfWeek = Arrays.asList(dayOfWeeks);\n }\n\n @Override\n public List findTimeIntervals(Call call){\n return call.getIntervals().splitByDay().stream()\n .filter(each -> dayOfWeeks.contains(each.getFrom().getDayOfWeek())\n .collect(Collectors.toList()));\n\t}\n}"}},{"id":"j1KWtkuv0e","type":"header","data":{"text":"구간별 정책","level":3}},{"id":"DdOlij0pHO","type":"code","data":{"code":"public class DurationFeeCondition implements FeeCondition {\n private Duration from;\n private Duration to;\n\n public DurationFeeCondition(Duration from, Duration to) {\n this.from = form;\n this.to = to;\n }\n\n @Override\n public List findTimeIntervals(Call call){\n if(call.getIntervals().duration().compareTo(from) < 0){\n return Collections.emptyList();\n }\n\n return Arrays.asList(DateTimeInterval.of(\n call.getInterval().getFrom().plus(from),\n call.getInterval().getTo().compareTo(to) > 0 ? \n call.getInterval().getFrom().plus(to) :\n call.getInterval().getTo()));\n }\n}"}},{"id":"lNqcy-hfXI","type":"header","data":{"text":"고정 요금 방식 정책","level":3}},{"id":"gQTtR3DwYs","type":"code","data":{"code":"public class FixedFeeCondition implements FeeCondtition {\n @Overide\n public List findTimeIntervals(Call call) {\n return Arrays.asList(call.getInterval());\n }\n}"}},{"id":"Z8rH9bw7Qo","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/image(20).png"}}},{"id":"yuhgd1YyzB","type":"delimiter","data":{}},{"id":"3n4crmmsBq","type":"header","data":{"text":"패턴을 찾아라","level":2}},{"id":"Fr-enAsq_G","type":"paragraph","data":{"text":"지금까지 살펴본 것처럼 일관성 있는 협력의 핵심은 변경을 분리하고 캡슐화하는 것이다. 변경을 캡슐화하는 방법이 협력에 참여하는 객체들의 역할과 책임을 결정하고 이렇게 결정된 협력이 코드의 구조를 결정한다. 따라서 훌륭한 설계자가 되는 첫 걸음은 변경의 방향을 파악할 수 있는 날카로운 감각을 기르는 일이다. 그리고 이 변경에 탄력적으로 대응할 수 있는 다양한 캡슐화 방법과 설계 방법을 익히는 것 역시 중요하다. "}},{"id":"idQQqwYuhk","type":"paragraph","data":{"text":"애플리케이션에서 유사한 기능에 대한 변경이 지속적으로 발생하고 있다면 변경을 캡슐화 할 수 있는 적절한 추상활르 찾은 후, 이 추상화에 변하지 않는 공통적인 책임을 할당하라. 현재의 구조가 변경을 캡슐화하기에 적합하지 않다면 코드를 수정하지 않고도 원하는 변경을 수용할 수 있도록 협력과 코드를 리팩터링 하라. 변경을 수용할 수 있는 적절한 역할과 책임을 찾다 보면 협력의 일관성이 서서히 윤곽을 드러낼 것이다. "}},{"id":"bGgoI-J810","type":"paragraph","data":{"text":"협력을 일관성 있게 만드는 과정은 유사한 기능을 구현하기 위해 반복적으로 적용할 수 있는 협력의 구조를 찾아가는 기나긴 여정이다. 따라서 협력을 일관성 있게 만든다는 것은 유사한 변경을 수용할 수 있는 패턴을 발견하는 것과 동일하다. "}}],"version":"2.31.0-rc.7"}

Tag List