책임 할당 과정은 일종의 trade-off 활동이다.
\n이 객체가 수행해야 하는 책임은 무엇인가를 결정이 책임을 수행하는 데 필요한 데이터는 무엇인가를 결정\n\n\"메시지를 전송해야 하는데 누구에게 전송해야 하지?\"라고 질문하는 것이 메시지 기반 설계로 향하는 첫걸음이다.
\n객체를 가지고 있기 때문에 메시지를 보내는 것이 아니다. 메시지를 전송하기 때문에 객체를 갖게 된 것이다.
\n
결론적으로 책임 중심의 설계에서는 협력이라는 문맥 안에서 객체가 수행할 책임에 초점을 맞춘다.
\n책임 주도 설계의 핵심은 책임을 결정한 후에 책임을 수행할 객체를 결정하는 것이다. 그리고 협력에 참여하는 객체들의 책임이 어느 정도 정리될 때까지는 객체의 내부 상태에 대해 관심을 가지지 않는 것이다.
\nGeneral Responsibility Assignment Software Pattern
\ninformation expert pattern
\nMovie 대신 Screening이 직접 DiscountCondition과 협력하게 하는 것은 어떨까?
Screening을 Reservation의 Creator로 선택/**\n * 상영 Class\n */\npublic class Screening {\n\n /**\n * 영화\n */\n private Movie movie;\n\n /**\n * 순번\n */\n @Getter\n private int sequence;\n\n /**\n * 상영 시작 시간\n */\n @Getter\n private LocalDateTime whenScreened;\n\n public Reservation reserve(Customer customer, int audienceCount) {\n return new Reservation(customer, this, calculateFee(audienceCount), audienceCount);\n }\n \n private Money calculateFee(int audienceCount) {\n return movie.calculateMovieFee(this).times(audienceCount);\n }\n}\n Movie에 전송하는 메시지의 시그니처를 calculateMovieFee으로 선언Movie에 어떤 수정을 가하더라도 Screening에는 영향을 미치지 않는다.public class Movie {\n\n /**\n * 제목\n */\n private String title;\n\n /**\n * 상영 시간\n */\n private Duration runningTime;\n\n /**\n * 기본 요금\n */\n private Money fee;\n\n /**\n * 할인 조건 목록\n */\n private List<DiscountCondition> discountConditions;\n\n /**\n * 할인 정책의 종류를 결정하는 변수\n */\n private MovieType movieType;\n\n /**\n * 할인 금액\n */\n private Money discountAmount;\n\n /**\n * 할인 비율\n */\n private double discountPercent;\n\n public Money calculateMovieFee(Screening screening) {\n if (isDiscountable(screening)) {\n return fee.minus(calculateDiscountAmount());\n }\n \n return fee;\n }\n \n private boolean isDiscountable(Screening screening) {\n return discountConditions.stream().anyMatch(condition -> condition.isSatisfiedBy(screening));\n }\n \n private Money calculateDiscountAmount() {\n switch (movieType) {\n case AMOUNT_DISCOUNT -> {\n return calculateAmountDiscountAmount();\n }\n case PERCENT_DISCOUNT -> {\n return calculatePercentDiscountAmount();\n }\n case NONE_DISCOUNT -> {\n return calculateNoneDiscountAmount();\n }\n }\n \n throw new IllegalArgumentException();\n }\n \n private Money calculateAmountDiscountAmount() {\n return discountAmount;\n }\n \n private Money calculatePercentDiscountAmount() {\n return fee.times(discountPercent);\n }\n \n private Money calculateNoneDiscountAmount() {\n return Money.ZERO;\n }\n}\n /**\n * 할인 조건 class\n */\npublic class DiscountCondition {\n\n /**\n * 할인 조건 타입\n */\n private DiscountConditionType type;\n\n /**\n * 상영 순번\n */\n private int sequence;\n\n /**\n * 요일\n */\n private DayOfWeek dayOfWeek;\n\n /**\n * 시작 시간\n */\n private LocalTime startTime;\n\n /**\n * 종료 시간\n */\n private LocalTime endTime;\n\n public boolean isSatisfiedBy(Screening screening) {\n if (type == DiscountConditionType.PERIOD) {\n return isSatisfiedByPeriod(screening);\n }\n \n return isSatisfiedBySequence(screening);\n }\n\n private boolean isSatisfiedByPeriod(Screening screening) {\n return dayOfWeek.equals(screening.getWhenScreened().getDayOfWeek()) &&\n !startTime.isAfter(screening.getWhenScreened().toLocalTime()) &&\n !endTime.isBefore(screening.getWhenScreened().toLocalTime());\n }\n\n private boolean isSatisfiedBySequence(Screening screening) {\n return sequence == screening.getSequence();\n }\n}\n public enum DiscountConditionType {\n\n /**\n * 순번 조건\n */\n SEQUENCE,\n\n /**\n * 기간 조건\n */\n PERIOD\n}\n 가장 큰 문제점은 변경에 취약한 클래스를 포함하고 있다는 것
\nDiscountCondition은 세 가지 이유로 변경될 수 있다.
즉, 변경의 이유에 따라 클래스를 분리해야 한다.
\n코드를 통해 변경의 이유를 파악할 수 있는 방법
\n인스턴스 변수가 초기화되는 시점을 살펴보는 것
\n메서드들이 인스턴스 변수를 사용하는 방식을 살펴보는 것
\nDiscountCondition의 가장 큰 문제는 순번 조건과 기간 조건이라는 두 개의 독립적인 타입이 하나의 클래스 안에 공존하고 있다는 점이다.
@AllArgsConstructor\npublic class PeriodCondition {\n\n /**\n * 요일\n */\n private DayOfWeek dayOfWeek;\n\n /**\n * 시작 시간\n */\n private LocalTime startTime;\n\n /**\n * 종료 시간\n */\n private LocalTime endTime;\n\n public boolean isSatisfiedBy(Screening screening) {\n return dayOfWeek.equals(screening.getWhenScreened().getDayOfWeek()) &&\n !startTime.isAfter(screening.getWhenScreened().toLocalTime()) &&\n !endTime.isBefore(screening.getWhenScreened().toLocalTime());\n }\n}\n @AllArgsConstructor\npublic class SequenceCondition {\n\n /**\n * 상영 순번\n */\n private int sequence;\n\n private boolean isSatisfiedBy(Screening screening) {\n return sequence == screening.getSequence();\n }\n}\n public class Movie {\n\n /**\n * 기간 할인 조건 목록\n */\n private List<PeriodCondition> periodConditions;\n\n /**\n * 순번 할인 조건 목록\n */\n private List<SequenceCondition> sequenceConditions;\n\n private boolean isDiscountable(Screening screening) {\n return checkPeriodConditions(screening) || checkSequenceConditions(screening);\n }\n \n private boolean checkPeriodConditions(Screening screening) {\n return periodConditions.stream().anyMatch(condition -> condition.isSatisfiedBy(screening));\n }\n\n private boolean checkSequenceConditions(Screening screening) {\n return sequenceConditions.stream().anyMatch(condition -> condition.isSatisfiedBy(screening));\n }\n}\n Movie가 PeriodCondition과 SequenceCondition 양쪽 모두에게 결합된다. 즉, 결합도가 높아졌다.public interface DiscountCondition {\n\n boolean isSatisfiedBy(Screening screening);\n}\n public class PeriodCondition implements DiscountCondition {...}\npublic class SequenceCondition implements DiscountCondition {...}\n public class Movie {\n\n /**\n * 할인 조건 목록\n */\n private List<DiscountCondition> discountConditions;\n\n public Money calculateMovieFee(Screening screening) {\n if (isDiscountable(screening)) {\n return fee.minus(calculateDiscountAmount());\n }\n\n return fee;\n }\n\n private boolean isDiscountable(Screening screening) {\n return discountConditions.stream().anyMatch(condition -> condition.isSatisfiedBy(screening));\n }\n}\n protected variations pattern (변경 보호 패턴)
\npublic abstract class Movie {\n\n /**\n * 제목\n */\n private final String title;\n\n /**\n * 상영 시간\n */\n private final Duration runningTime;\n\n /**\n * 기본 요금\n */\n private final Money fee;\n\n /**\n * 할인 조건 목록\n */\n private final List<DiscountCondition> discountConditions;\n\n protected Movie(String title, Duration runningTime, Money fee, DiscountCondition... discountConditions) {\n this.title = title;\n this.runningTime = runningTime;\n this.fee = fee;\n this.discountConditions = Arrays.asList(discountConditions);\n }\n\n public Money calculateMovieFee(Screening screening) {\n if (isDiscountable(screening)) {\n return fee.minus(calculateDiscountAmount());\n }\n\n return fee;\n }\n\n private boolean isDiscountable(Screening screening) {\n return discountConditions.stream().anyMatch(condition -> condition.isSatisfiedBy(screening));\n }\n\n protected abstract Money calculateDiscountAmount();\n}\n calculateDiscountAmount를 추상 메서드로 선언public class AmountDiscountMovie extends Movie {\n\n private final Money discountAmount;\n\n public AmountDiscountMovie(String title, Duration runningTime, Money fee, Money discountAmount, DiscountCondition... discountConditions) {\n super(title, runningTime, fee, discountConditions);\n this.discountAmount = discountAmount;\n }\n\n @Override\n protected Money calculateDiscountAmount() {\n return discountAmount;\n }\n}\n public class PercentDiscountMovie extends Movie {\n\n private final double percent;\n\n public PercentDiscountMovie(String title, Duration runningTime, Money fee, double percent, DiscountCondition... discountConditions) {\n super(title, runningTime, fee, discountConditions);\n this.percent = percent;\n }\n\n @Override\n protected Money calculateDiscountAmount() {\n return getFee().times(percent);\n }\n}\n @Getter(AccessLevel.PROTECTED)\n private final Money fee;\n public class NoneDiscountMovie extends Movie {\n\n public NoneDiscountMovie(String title, Duration runningTime, Money fee, double percent, DiscountCondition... discountConditions) {\n super(title, runningTime, fee, discountConditions);\n }\n\n @Override\n protected Money calculateDiscountAmount() {\n return Money.ZERO;\n }\n}\n \n\n도메인의 구조가 코드의 구조를 이끈다
\n
개발자로서 변경에 대비할 수 있는 두 가지 방법
\n코드를 이해하고 수정하기 쉽도록 최대한 단순하게 설계
\n코드를 수정하지 않고도 변경을 수용할 수 있도록 코드를 더 유연하게 만드는 것
\n이해하기 쉽고 수정하기 쉬운 소프트웨어로 개선하기 위해 겉으로 보이는 동작은 바꾸지 않은 채 내부 구조를 변경하는 것을 리팩터링(Refactoring)이라고 부른다.
\n/**\n * 영화 예매 절차 구현 Class\n */\npublic class ReservationAgency {\n\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().isAfter(screening.getWhenScreened().toLocalTime()) &&\n !condition.getEndTime().isBefore(screening.getWhenScreened().toLocalTime());\n } else {\n discountable = condition.getSequence() == screening.getSequence();\n }\n\n if (discountable) {\n break;\n }\n }\n\n Money fee;\n if (discountable) {\n Money discountAmount = Money.ZERO;\n switch (movie.getMovieType()) {\n case AMOUNT_DISCOUNT -> discountAmount = movie.getDiscountAmount();\n case PERCENT_DISCOUNT -> discountAmount = movie.getFee().times(movie.getDiscountPercent());\n case NONE_DISCOUNT -> discountAmount = Money.ZERO;\n }\n\n fee = movie.getFee().minus(discountAmount);\n } else {\n fee = movie.getFee();\n }\n\n return new Reservation(customer, screening, fee, audienceCount);\n }\n}\n public class ReservationAgency {\n\n public Reservation reserve(Screening screening, Customer customer, int audienceCount) {\n boolean discountable = checkDiscountable(screening);\n Money fee = calculateFee(screening, discountable, audienceCount);\n return createReservation(screening, customer, audienceCount, fee);\n }\n\n private boolean checkDiscountable(Screening screening) {\n return screening.getMovie().getDiscountConditions().stream().anyMatch(condition -> isDiscountable(condition, screening));\n }\n\n private boolean isDiscountable(DiscountCondition condition, Screening screening) {\n if (condition.getType() == DiscountConditionType.PERIOD) {\n return isSatisfiedByPeriod(condition, screening);\n }\n return isSatisfiedBySequence(condition, screening);\n }\n\n private boolean isSatisfiedByPeriod(DiscountCondition condition, Screening screening) {\n return screening.getWhenScreened().getDayOfWeek().equals(condition.getDayOfWeek()) &&\n !condition.getStartTime().isAfter(screening.getWhenScreened().toLocalTime()) &&\n !condition.getEndTime().isBefore(screening.getWhenScreened().toLocalTime());\n }\n\n private boolean isSatisfiedBySequence(DiscountCondition condition, Screening screening) {\n return condition.getSequence() == screening.getSequence();\n }\n\n private Money calculateFee(Screening screening, boolean discountable, int audienceCount) {\n if (discountable) {\n return screening.getMovie().getFee()\n .minus(calculateDiscountedFee(screening.getMovie()))\n .times(audienceCount);\n }\n \n return screening.getMovie().getFee().times(audienceCount);\n }\n\n private Money calculateDiscountedFee(Movie movie) {\n switch (movie.getMovieType()) {\n case AMOUNT_DISCOUNT -> {\n return calculateAmountDiscountedFee(movie);\n }\n case PERCENT_DISCOUNT -> {\n return calculatePercentDiscountedFee(movie);\n }\n case NONE_DISCOUNT -> {\n return calculateNoneDiscountedFee();\n }\n }\n\n throw new IllegalArgumentException();\n }\n\n private Money calculateAmountDiscountedFee(Movie movie) {\n return movie.getDiscountAmount();\n }\n\n private Money calculatePercentDiscountedFee(Movie movie) {\n return movie.getFee().times(movie.getDiscountPercent());\n }\n\n private Money calculateNoneDiscountedFee() {\n return Money.ZERO;\n }\n \n private Reservation createReservation(Screening screening, Customer customer, int audienceCount, Money fee) {\n return new Reservation(customer, screening, fee, audienceCount);\n }\n}\n public class DiscountCondition {\n\n /**\n * 할인 조건 타입\n */\n private DiscountConditionType type;\n\n /**\n * 상영 순번\n */\n private int sequence;\n\n /**\n * 요일\n */\n private DayOfWeek dayOfWeek;\n\n /**\n * 시작 시간\n */\n private LocalTime startTime;\n\n /**\n * 종료 시간\n */\n private LocalTime endTime;\n\n public boolean isDiscountable(Screening screening) {\n if (type == DiscountConditionType.PERIOD) {\n return isSatisfiedByPeriod(screening);\n }\n return isSatisfiedBySequence(screening);\n }\n\n private boolean isSatisfiedByPeriod(Screening screening) {\n return screening.getWhenScreened().getDayOfWeek().equals(dayOfWeek) &&\n !startTime.isAfter(screening.getWhenScreened().toLocalTime()) &&\n !endTime.isBefore(screening.getWhenScreened().toLocalTime());\n }\n\n private boolean isSatisfiedBySequence(Screening screening) {\n return sequence == screening.getSequence();\n }\n}\n DiscountCondition으로 이동하고, 접근제어자를 변경했다. private boolean checkDiscountable(Screening screening) {\n return screening.getMovie().getDiscountConditions().stream().anyMatch(condition -> condition.isDiscountable(screening));\n }\n 사람의 기억은 단기 기억과 장기 기억으로 분류할 수 있다. 실제로 문제를 해결하기 위해 사용하는 저장소는 장기 기억이 아니라 단기 기억이다.
\n\n\n한 번에 단기 기억에 담을 수 있는 추상화의 수에는 한계가 있지만 추상화를 더 큰 규모의 추상화로 압축시킴으로써 단기 기억의 한계를 초월할 수 있다.
\n
모든 프로그래밍 패러다임은 추상화와 분해의 관점에서 설명할 수 있다.
\n협력하는 공동체를 구성하도록 객체들로 나누는 과정이 바로 객체지향 패러다임에서의 분해를 의미
기능 분해의 관점에서 추상화의 단위는 프로시저이며 시스템은 프로시저를 단위로 분해
\n\n\n시스템은 필요한 더 작은 작업으로 분해될 수 있는 하나의 커다란 메인 함수다.
\n
전통적인 기능 분해 방법은 **하향식 접근법(Top-Down Approach)**을 따른다.
\n급여 = 기본급 - (기본급 * 소득세율)
직원의 급여를 계산한다
직원의 급여를 계산한다\n 사용자로부터 소득세율을 입력받는다.\n 직원의 급여를 계산한다.\n 양식에 맞게 결과를 출력한다.\n 직원의 급여를 계산한다\n 사용자로부터 소득세율을 입력받는다.\n "세율을 입력하세요: "라는 문장을 화면에 출력한다.\n 키보드를 통해 세율을 입력받는다.\n 직원의 급여를 계산한다.\n 전역 변수에 저장된 직원의 기본급 정보를 얻는다.\n 급여를 계산한다.\n 양식에 맞게 결과를 출력한다.\n "이름: {직원명}, 급여: {계산된 금액}" 형식에 다라 출력 문자열을 생성한다.\n 루비 언어를 기반으로 예시를 든다.
\n직원의 급여를 계산한다
def main(name)\nend\n 사용자로부터 소득세율을 입력받는다.\n 직원의 급여를 계산한다.\n 양식에 맞게 결과를 출력한다.\n def main(name)\n taxRate = getTaxRate()\n pay = calculatePayFor(name, taxRate)\n puts(describeResult(name, pay))\nend\n 사용자로부터 소득세율을 입력받는다.\n "세율을 입력하세요: "라는 문장을 화면에 출력한다.\n 키보드를 통해 세율을 입력받는다.\n def getTaxRate()\n print("세율을 입력하세요: ")\n return gets().chomp().to_f()\nend\n 직원의 급여를 계산한다.\n 전역 변수에 저장된 직원의 기본급 정보를 얻는다.\n 급여를 계산한다.\n $employees = ["직원A", "직원B", "직원C"]\n$basePays = [400, 300, 250]\n def calculatePayFor(name, taxRate)\n index = $imployees.index(name)\n basePay = $basePays[index]\n return basePay - (basePay * taxRate)\nend\n 양식에 맞게 결과를 출력한다.\n "이름: {직원명}, 급여: {계산된 금액}" 형식에 다라 출력 문자열을 생성한다.\n def describeResult(name, pay)\n return "이름: #{name}, 급여: #{pay}"\nend\n 하향식 기능 분해 방식으로 설계한 시스템은 메인 함수를 루트로 하는 '트리(tree)'로 표현할 수 있다. 체계적이고 이상적으로 보이지만 우리가 사는 세계는 그렇게 체계적이지도, 이상적이지도 않다.
\n\n\n실제 시스템에 정상(top)이란 존재하지 않는다. - 버트란드 마이어
\n
급여 관리 시스템에 모든 직원들의 기본급의 총합을 구하는 기능을 추가해 달라는 새로운 요구사항이 접수됐다고 가정
\ndef sumOfBasePays()\n result = 0\n for basePay in $basePays\n result += basePay\n end\n puts(result)\nend\n def main(name)\n taxRate = getTaxRate()\n pay = calculatePayFor(name, taxRate)\n puts(describeResult(name, pay))\nend\n def calculatePay(name)\n taxRate = getTaxRate()\n pay = calculatePayFor(name, taxRate)\n puts(describeResult(name, pay))\nend\n calcuatePay 함수로 옮기자def main(operation, args={})\n case(operation)\n when :pay then calculatePay(args[:name])\n when :basePays then sumOfBasePays()\n end\nend\n 하향식 설계와 관련된 모든 문제의 원인은 결합도 ❗️
\n정규 직원의 급여뿐만 아니라 아르바이트 직원에 대한 급여도 관리를 할 수 있도록 해달라는 변경 요청이 왔다고 가정
\n$employees = ["직원A", "직원B", "직원C", "아르바이트D", "아르바이트E", "아르바이트F"]\n$basePays = [400, 300, 250, 1, 1, 1.5]\n$hourlys = [false, false, false, true, true, true]\n$timeCards = [0, 0, 0, 120, 120, 120]\n def calculateHourlyPayFor(name, taxRate)\n index = $imployees.index(name)\n basePay = $basePays[index] * $timeCards[index]\n return basePay - (basePay * taxRate)\nend\n def hourly?(name)\n return $hourlys[$employees.index(name)]\nend\n def calculatePay(name)\n taxRate = getTaxRate()\n if (hourly?(name)) then\n pay = calculateHourlyPayFor(name, taxRate)\n else\n pay = calculatePayFor(name, taxRate)\n end\n puts(describeResult(name, pay))\nend\n def sumOfBasePays()\n result = 0\n for name in $employees\n if (not hourly?(name)) then\n result += $basePays[$employees.index(name)]\n end\n end\n puts(result)\nend\n 이처럼 데이터 변경으로 인해 발생하는 함수에 대한 영향도를 파악하는 것이 쉽지 않다.
\n하향식 설계는 설계가 어느 정도 안정화 된 후에는 설계의 다양한 측면을 논리적으로 설명하고 문서화하기에 용이하다.
\n\n\n하향식은 이미 완전히 이해된 사실을 서술하기에 적합한 방법이다.
\n
정보 은닉은 시스템을 모듈 단위로 분해하기 위한 기본 원리로 시스템에서 자주 변경되는 부분을 상대적으로 덜 변경되는 안정적인 인터페이스 뒤로 감춰야 한다는 것이 핵심이다.
\n\n\n모듈은 서브 프로그램이라기보다는 책임의 할당이다.
\n
모듈이 감춰야 할 비밀
\nmodule Employees\n $employees = ["직원A", "직원B", "직원C", "아르바이트D", "아르바이트E", "아르바이트F"]\n $basePays = [400, 300, 250, 1, 1, 1.5]\n $hourlys = [false, false, false, true, true, true]\n $timeCards = [0, 0, 0, 120, 120, 120]\n\n def Employees.calculatePay(name, taxRate)\n if (Employees.hourly?(name)) then\n pay = calculateHourlyPayFor(name, taxRate)\n else\n pay = calculatePayFor(name, taxRate)\n end\n end\n\n def Employees.hourly?(name)\n return $hourlys[$employees.index(name)]\n end\n\n def Employees.calculateHourlyPayFor(name, taxRate)\n index = $imployees.index(name)\n basePay = $basePays[index] * $timeCards[index]\n return basePay - (basePay * taxRate)\n end\n\n def Employees.calculatePayFor(name, taxRate)\n return basePay - (basePay * taxRate)\n end\n\n def Employees.sumOfBasePays()\n result = 0\n for name in $employees\n if (not Employees.hourly?(name)) then\n result += $basePays[$employees.index(name)]\n end\n end\n return result\n end\n module이라는 키워드를 제공하지만 모듈은 키워드의 지원 여부와 상관없이 적용할 수 있는 논리적인 개념이다.def main(operation, args={})\n case(operation)\n when :pay then calculatePay(args[:name])\n when :basePays then sumOfBasePays()\n end\nend\n\ndef calculatePay(name)\n taxRate = getTaxRate()\n pay = Employees.calculatePayFor(name, taxRate)\n puts(describeResult(name, pay))\nend\n\ndef getTaxRate()\n print("세율을 입력하세요: ")\n return gets().chomp().to_f()\nend\n\ndef describeResult(name, pay)\n return "이름: #{name}, 급여: #{pay}"\nend\n\ndef sumOfBasePays()\n puts(Employees.sumOfBasePays())\nend\n 모듈의 장점
\n모듈은 기능이 아니라 변경의 정도에 따라 시스템을 분해하게 한다.
\n모듈은 데이터와 함수가 통합된 한 차원 높은 추상화를 제공하는 설계 단위이다 ❗️
\n모듈의 가장 큰 단점은 인스턴스의 개념을 제공하지 않는다는 점이다. 다수의 직원 인스턴스가 존재하는 추상화 메커니즘이 추상 데이터 타입이다.
\n프로그래밍 언어에서 타입(type) 이란 변수에 저장할 수 있는 내용물의 종류와 변수에 적용될 수 있는 연산의 가짓수를 의미한다.
\n추상 데이터 타입을 구현하려면 다음과 같은 특성을 위한 프로그래밍 언어의 지원이 필요하다.
\n리스코프는 추상 데이터 타입을 정의하기 위해 제시한 언어적인 메커니즘을 오퍼레이션 클러스터라고 불렀다.
\nEmployee = Struct.new(:name, :basePay, :hourly, :timeCard) do\nEnd\n Employee = Struct.new(:name, :basePay, :hourly, :timeCard) do\n def calculatePay(taxRate)\n if (hourly) then\n return calculateHourlyPayFor(taxRate)\n end\n return calculateSalariedFor(taxRate)\n end\n\nprivate\n def calculateHourlyPayFor(taxRate)\n return (basePay * timeCard) - (basePay * timeCard) * taxRate\n end\n\n def calculateSalariedFor(taxRate)\n return basePay - (basePay * taxRate)\n end\nend\n Employee = Struct.new(:name, :basePay, :hourly, :timeCard) do\n def monthlyBasePay()\n if (hourly) then return 0 end\n return basePay\n end\nend\n $employees = [\n Employee.new("직원A", 400, false, 0),\n Employee.new("직원B", 300, false, 0),\n Employee.new("직원C", 200, false, 0),\n Employee.new("아르바이트D", 1, true, 120),\n Employee.new("아르바이트E", 1, true, 120),\n Employee.new("아르바이트F", 1, true, 120),\n]\n def calculatePay(name)\n taxRate = getTaxRate()\n for each in $employees\n if (each.name === name) then employee = each; break end\n end\n pay = employee. calculatePay(taxRate)\n puts(describeResult(name, pay))\nend\n def sumOfBasePays()\n result = 0\n for each in $employees\n result += each.monthlyBasePay()\n end\n puts(result)\nend\n 추상 데이터 타입의 기본 의도는 프로그래밍 언어가 제공하는 타입처럼 동작하는 사용자 정의 타입을 추가할 수 있게 하는 것
\n클래스와 추상 데이터 타입 모두 데이터 추상화를 기반으로 시스템을 분해한다. 그러나 명확한 의미에서 추상 데이터 타입과 클래스는 동일하지 않다.
\n하나의 대표적인 타입이 다수의 세부적인 타입을 감추기 때문에 이를 타입 추상화라 부른다.
\n추상 데이터 타입이 오퍼레이션을 기준으로 타입을 묶는 방법이라면 객체지향은 타입을 기준으로 오퍼레이션을 묶는다.
\nclass Employee\n attr_reader :name, :basePay\n\n def initialize(name, basePay)\n @name = name\n @basePay = basePay\n end\n\n def calculatePay(taxRate)\n raise NotImplementedError\n end\n\n def monthlyBasePay()\n raise NotImplementedError\n end\nend\n Employee class는 추상 클래스, calculatePay, monthlyBasePay는 추상 메서드이다.class SalariedEmployee < Employee\n def initialize(name, basePay)\n super(name, basePay)\n end\n\n def calculatePay(taxRate)\n return basePay - (basePay * taxRate)\n end\n\n def monthlyBasePay()\n return basePay\n end\nend\n class HourlyEmployee < Employee\n attr_reader :timeCard\n def initialize(name, basePay, timeCard)\n super(name, basePay)\n @timeCard = timeCard\n end\n\n def calculatePay(taxRate)\n return (basePay * timeCard) - (basePay * timeCard) * taxRate\n end\n\n def monthlyBasePay()\n return 0\n end\nend\n $employees = [\n SalariedEmployee.new("직원A", 400),\n SalariedEmployee.new("직원B", 300),\n SalariedEmployee.new("직원C", 200),\n HourlyEmployee.new("아르바이트D", 1, 120),\n HourlyEmployee.new("아르바이트E", 1, 120),\n HourlyEmployee.new("아르바이트F", 1, 120),\n]\n def sumOfBasePays()\n result = 0\n for each in $employees\n result += each.monthlyBasePay()\n end\n puts(result)\nend\n 비록 클래스를 사용하고 있더라도 타입을 기준으로 절차를 추상화하지 않았다면 그것은 객체지향 분해가 아니다.
\n개방-폐쇄 원칙(Open-Closed Principle, OCP)
\n협력이라는 문맥을 고려하지 않고 객체를 고립시킨 채 오퍼레이션의 구현 방식을 타입별로 분배하는 것은 올바른 접근법이 아니다.
\n객체가 참여할 협력을 결정하고 협력에 필요한 책임을 수행하기 위해 어떤 객체가 필요한지에 관해 고민하라.
\n\n\n애플리케이션은 클래스로 구성되지만 메시지를 통해 정의된다는 사실을 기억하라.
\n
메시지는 객체 사이의 협력을 가능하게 하는 매개체다. 두 객체 사이의 협력 관계를 설명하기 위해 사용하는 전통적인 메타포는 클라이언트-서버 모델 이다.
\nMovie와 같이 객체는 협력에 참여하는 동안 클라이언트와 서버의 역할을 동시에 수행하는 것이 일반적좋은 인터페이스는 최소한의 인터페이스와 추상적인 인터페이스라는 조건을 만족해야 한다.
\n퍼블릭 인터페이스의 품질에 영향을 미치는 원칙과 기법
\npublic class ReservationAgency {\n\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().isAfter(screening.getWhenScreened().toLocalTime()) &&\n !condition.getEndTime().isBefore(screening.getWhenScreened().toLocalTime());\n } else {\n discountable = condition.getSequence() == screening.getSequence();\n }\n\n if (discountable) {\n break;\n }\n }\n\n Money fee;\n if (discountable) {\n Money discountAmount = Money.ZERO;\n switch (movie.getMovieType()) {\n case AMOUNT_DISCOUNT -> discountAmount = movie.getDiscountAmount();\n case PERCENT_DISCOUNT -> discountAmount = movie.getFee().times(movie.getDiscountPercent());\n case NONE_DISCOUNT -> discountAmount = Money.ZERO;\n }\n\n fee = movie.getFee().minus(discountAmount);\n } else {\n fee = movie.getFee();\n }\n\n return new Reservation(customer, screening, fee, audienceCount);\n }\n}\n ReservationAgency와 인자로 전달된 Screening 사이의 결합도가 너무 높은 것이다.\n\n낯선 자에게 말하지 말라
\n오직 인접한 이웃하고만 말하라
\n
디미터 법칙을 따르기 위해서는 클래스가 특정한 조건을 만족하는 대상에게만 메시지를 전송하도록 프로그래밍
\n즉, 클래스 내부의 메서드가 아래 조건을 만족하는 인스턴스에만 메시지를 전송하도록 해야 한다.
\npublic class ReservationAgency {\n\n public Reservation reserve(Screening screening, Customer customer, int audienceCount) {\n Money fee = screening.calculateFee(audienceCount);\n return new Reservation(customer, screening, fee, audienceCount);\n }\n}\n screening.getMovie().getDiscountConditions();
screening.calculateFee(audienceCount);무비판적으로 디미터 법칙을 수용하면 퍼블릭 인터페이스 관점에서 객체의 응집도가 낮아질 수도 있다.
\n메시지 전송자는 메시지 수신자의 상태를 기반으로 결정을 내린 후 메시지 수신자의 상태를 바꿔서는 안된다.
\n메서드를 명명하는 방법
\npublic class PeriodCondition {\n public boolean isSatisfiedByPeriod(Screening screening) {\n ...\n }\n}\n\npublic class SequenceCondition {\n public boolean isSatisfiedBySequence(Screening screening) {\n ...\n }\n}\n 메서드가 작업을 어떻게 수행하는지를 나타내도록 이름 짓는 것
\n'어떻게'가 아니라 '무엇'을 하는지를 드러내는 것
\npublic class PeriodCondition {\n public boolean isSatisfiedBy(Screening screening) {\n ...\n }\n}\n\npublic class SequenceCondition {\n public boolean isSatisfiedBy(Screening screening) {\n ...\n }\n}\n public interface DiscountCondition {\n boolean isSatisfiedBy(Screening screening);\n}\n 이와 같은 메서드 명명 방법을 의도를 드러내는 선택자(Intention Revealing Selector) 라고 부른다.
\n@AllArgsConstructor\npublic class Theater {\n\n private TicketSeller ticketSeller;\n\n // 관람객 입장\n public void enter(Audience audience) {\n if (audience.getBag().hasInvitation()) {\n Ticket ticket = ticketSeller.getTicketOffice().getTicket();\n audience.getBag().setTicket(ticket);\n return;\n }\n Ticket ticket = ticketSeller.getTicketOffice().getTicket();\n audience.getBag().minusAmount(ticket.getFee());\n ticketSeller.getTicketOffice().plusAmount(ticket.getFee());\n audience.getBag().setTicket(ticket);\n }\n}\n @AllArgsConstructor\npublic class TicketSeller {\n\n private TicketOffice ticketOffice;\n\n public void setTicket(Audience audience) {\n if (audience.getBag().hasInvitation()) {\n Ticket ticket = ticketOffice.getTicket();\n audience.getBag().setTicket(ticket);\n return;\n }\n Ticket ticket = ticketOffice.getTicket();\n audience.getBag().minusAmount(ticket.getFee());\n ticketOffice.plusAmount(ticket.getFee());\n audience.getBag().setTicket(ticket);\n }\n}\n @AllArgsConstructor\npublic class Theater {\n\n private TicketSeller ticketSeller;\n\n public void enter(Audience audience) {\n ticketSeller.setTicket(audience);\n }\n}\n Theater는 TicketSeller와 Audience의 내부 구조에 관해 묻지 말고 원하는 작업을 시켜야 한다.@AllArgsConstructor\npublic class Audience {\n\n private Bag bag;\n\n public Long setTicket(Ticket ticket) {\n if (bag.hasInvitation()) {\n bag.setTicket(ticket);\n return 0L;\n }\n bag.setTicket(ticket);\n bag.minusAmount(ticket.getFee());\n return ticket.getFee();\n }\n}\n @AllArgsConstructor\npublic class TicketSeller {\n\n private TicketOffice ticketOffice;\n\n public void setTicket(Audience audience) {\n ticketOffice.plusAmount(audience.setTicket(ticketOffice.getTicket()));\n }\n}\n TicketSeller는 속성으로 포함되고 있는 TicketOffice의 인스턴스와 인자로 전달된 Audience에게만 메시지를 전송한다.Audience는 hasInvitation 메서드를 이용해 초대권을 가지고 있는지를 묻는다. 즉, 디미터 법칙을 위반한다.public class Bag {\n\n private Long amount;\n private Invitation invitation;\n private Ticket ticket;\n\n public Long setTicket(Ticket ticket) {\n if (hasInvitation()) {\n setTicket(ticket);\n return 0L;\n }\n setTicket(ticket);\n minusAmount(ticket.getFee());\n return ticket.getFee();\n }\n\n public boolean hasInvitation() {\n return invitation != null;\n }\n\n public void minusAmount(Long amount) {\n this.amount -= amount;\n }\n}\n @AllArgsConstructor\npublic class Audience {\n\n private Bag bag;\n\n public Long setTicket(Ticket ticket) {\n return bag.setTicket(ticket);\n }\n}\n Audience는 자율적인 존재가 되었다.디미터 법칙과 묻지 말고 시켜라 스타일을 따르면 자연스럽게 자율적인 객체로 구성된 유연한 협력을 얻게 된다.
\n위 코드들의 setTicket 메서드는 미묘하게 다른 의미를 가지고 있다❗️
public class TicketSeller {\n public void sellTo(Audience audience) {\n ...\n }\n}\n\npublic class Audience {\n public Long buy(Ticket ticket) {\n ...\n }\n}\n\npublic class Bag {\n public Long hold(Ticket ticket) {\n ...\n }\n}\n 원칙이 현재 상황에 부적합하다고 판단된다면 과감하게 원칙을 무시하라.
\nIntStream.of(1, 15, 20, 3, 9).filter(x -> x > 10).distinct().count();
설계는 trade-off의 산물이다. 즉, 경우에 따라 다르다
\n원칙이 적절한 상황과 부적절한 상황을 판단할 수 있는 안목을 길러라❗️
\n명령-쿼리 분리 원칙의 요지는 오퍼레이션은 부수효과를 발생시키는 명령이거나 부수효과를 발생시키지 않는 쿼리 중 하나여야 한다는 것
\n예시 도메인의 용어 정리
\n@AllArgsConstructor\npublic class Event {\n\n private String subject;\n private LocalDateTime from;\n private Duration duration;\n}\n @AllArgsConstructor\npublic class RecurringSchedule {\n\n private String subject;\n\n @Getter\n private DayOfWeek dayOfWeek;\n\n @Getter\n private LocalTime from;\n\n @Getter\n private Duration duration;\n}\n RecurringSchedule schedule = new RecurringSchedule("회의", DayOfWeek.WEDNESDAY, LocalTime.of(10, 30), Duration.ofMinutes(30));\nEvent meeting = new Event("회의", LocalDateTime.of(2019, 5, 8, 10, 30), Duration.ofMinutes(30));\n\nassert meeting.isSatisfied(schedule);\n RecurringSchedule schedule = new RecurringSchedule("회의", DayOfWeek.WEDNESDAY, LocalTime.of(10, 30), Duration.ofMinutes(30));\nEvent meeting = new Event("회의", LocalDateTime.of(2019, 5, 9, 10, 30), Duration.ofMinutes(30));\n\nassert !meeting.isSatisfied(schedule);\nassert meeting.isSatisfied(schedule);\n false를 반환한다. 하지만 다시 한번 더 실행시키면 true를 반환한다.@AllArgsConstructor\npublic class Event {\n\n private String subject;\n private LocalDateTime from;\n private Duration duration;\n\n public boolean isSatisfied(RecurringSchedule schedule) {\n if (from.getDayOfWeek() != schedule.getDayOfWeek() ||\n !from.toLocalTime().equals(schedule.getFrom()) ||\n !duration.equals(schedule.getDuration())) {\n reschedule(schedule);\n return false;\n }\n return true;\n }\n\n private void reschedule(RecurringSchedule schedule) {\n from = LocalDateTime.of(from.toLocalDate().plusDays(daysDistance(schedule)), schedule.getFrom());\n duration = schedule.getDuration();\n }\n\n private long daysDistance(RecurringSchedule schedule) {\n return schedule.getDayOfWeek().getValue() - from.getDayOfWeek().getValue();\n }\n}\n isSatisfied가 명령과 쿼리의 두 가지 역할을 동시에 수행하고 있었기 때문에 발생한 문제@AllArgsConstructor\npublic class Event {\n\n private String subject;\n private LocalDateTime from;\n private Duration duration;\n\n public boolean isSatisfied(RecurringSchedule schedule) {\n return from.getDayOfWeek() == schedule.getDayOfWeek() &&\n from.toLocalTime().equals(schedule.getFrom()) &&\n duration.equals(schedule.getDuration());\n }\n\n public void reschedule(RecurringSchedule schedule) {\n from = LocalDateTime.of(from.toLocalDate().plusDays(daysDistance(schedule)), schedule.getFrom());\n duration = schedule.getDuration();\n }\n\n private long daysDistance(RecurringSchedule schedule) {\n return schedule.getDayOfWeek().getValue() - from.getDayOfWeek().getValue();\n }\n}\n reschedule 메서드 호출 여부를 Event를 사용하는 쪽에서 결정할 수 있다.명령과 쿼리를 분리함으로써 명령형 언어의 틀 안에서 **참조 투명성(referential transparency)**의 장점을 제한적이나마 누릴 수 있게 된다.
\n참조 투명성을 만족하는 식은 우리에게 두 가지 장점을 제공
\n메시지를 먼저 선택하고 그 후에 메시지를 처리할 객체를 선택하라.
\n협력을 위해 두 객체가 보장해야 하는 실행 시점의 제약을 인터페이스에 명시할 수 있는 방법이 존재하지 않음.
\n