\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협력은 필수적이지만 과도한 협력은 설계를 곤경에 빠트릴 수 있다. 협력을 위해서는 의존성이 필요하지만 과도한 의존성은 애플리케이션을 수정하기 어렵게 만든다.
\n객체지향 설계의 핵심은 협력을 위해 필요한 의존성은 유지하면서도 변경을 방해하는 의존성은 제거하는데 있다. 이런 관점에서 객체지향 설계란 의존성을 관리하는 것이고 객체가 변화를 받아들일 수 있게 의존성을 정리하는 기술이라고 할 수 있다.
\n어떤 객체가 협력하기 위해 다른 객체를 필요로 할 때 두 객체 사이에 의존성이 존재하게 된다. 의존성은 실행 시점과 구현 시점에 서로 다른 의미를 가진다.
\n@AllArgsConstructor\npublic class PeriodCondition implements DiscountCondition {\n\n private DayOfWeek dayOfWeek;\n private LocalTime startTime;\n private LocalTime endTime;\n\n @Override\n public boolean isSatisfiedBy(Screening screening) {\n return screening.getStartTime().getDayOfWeek().equals(dayOfWeek) &&\n !startTime.isAfter(screening.getStartTime().toLocalTime()) &&\n !endTime.isBefore(screening.getStartTime().toLocalTime());\n }\n}\n PeriodCondition의 인스턴스가 정상적으로 동작하기 위해서는 Screening의 인스턴스가 존재해야 한다.이처럼 어떤 객체가 예정된 작업을 정상적으로 수행하기 위해 다른 객체를 필요로 하는 경우 두 객체 사이에 의존성이 존재한다고 말한다.
\n직접 의존성
\nPeriodCondition이 Screening에 직접 의존하는 경우간접 의존성
\n런타임 의존성
\n컴파일타임 의존성
\n유연하고 재사용 가능한 설계를 창조하기 위해서는 동일한 소스코드 구조를 가지고 다양한 실행 구조를 만들 수 있어야 한다.
\n\n\n시스템을 구성하는 객체가 컨텍스트 독립적이라면 해당 시스템은 변경하기 쉽다.\n여기서 컨텍스트 독립적이라는 말은 각 객체가 해당 객체를 실행하는 시스템에 관해 아무것도 알지 못한다는 의미다.
\n
컴파일타임 의존성은 구체적인 런타임 의존성으로 대체돼야 한다.
\n의존성은 객체들의 협력을 가능하게 만드는 매개체라는 관점에서는 바람직한 것이다. 하지만 의존성이 과하면 문제가 될 수 있다.
\n바람직한 의존성은 재사용성과 관련이 있다.
\n결합도의 정도는 한 요소가 자신이 의존하고 있는 다른 요소에 대해 알고 있는 정보의 양으로 결정
\n결합도를 느슨하게 만들기 위해서는 협력하는 대상에 대해 필요한 정보 외에는 최대한 감추는 것이 중요
\n추상화란 어떤 양상, 세부사항, 구조를 좀 더 명확하게 이해하기 위해 특정 절차나 물체를 의도적으로 생략하거나 감춤으로써 복잡도를 극복하는 방법
\n일반적으로 추상화와 결합도의 관점에서 의존 대상을 다음과 같이 구분하는 것이 유용하다. 아래로 갈수록 결합도가 느슨해진다.
\n의존하는 대상이 더 추상적일수록 결합도는 더 낮아진다.
\npublic class Movie {\n\n private DiscountPolicy discountPolicy;\n\n public Movie(String title, Duration runningTime, Money fee) {\n this.discountPolicy = new AmountDiscountPolicy(...);\n }\n}\n AmountDiscountPolicy의 인스턴스를 직접 생성해서 대입하고 있어 결합도가 불필요하게 높아졌다.public class Movie {\n\n private DiscountPolicy discountPolicy;\n\n public Movie(String title, Duration runningTime, Money fee, DiscountPolicy discountPolicy) {\n this.discountPolicy = discountPolicy;\n }\n}\n 의존성을 구현 내부에 숨겨두지 마라. 명시적인 의존성을 사용해야만 퍼블릭 인터페이스를 통해 컴파일타임 의존성을 적절한 런타임 의존성으로 교체할 수 있다.
\nnew를 잘못 사용하면 클래스 사이의 결합도가 극단적으로 높아진다.
new 연산자를 사용하기 위해서는 구체 클래스의 이름을 직접 기술해야한다. 즉, 구체 클래스에 의존할 수 밖에 없기에 결합도가 높아진다.new 연산자는 생성하려는 구체 클래스뿐만 아니라 어떤 인자를 이용해 클래스의 생성자를 호출해야 하는지도 알아야 한다. 즉, 지식의 양이 늘어나기 때문에 결합도가 높아진다.사용과 생성의 책임을 분리하고, 의존성을 생성자에 명시적으로 드러내고, 구체 클래스가 아닌 추상 클래스에 의존하게 함으로써 설계를 유연하게 만들 수 있다.
\n주로 협력하는 기본 객체를 설정하고 싶은 경우 클래스 안에서 객체의 인스턴스를 직접 생성하는 방식이 유용하다.
\npublic class Movie {\n\n private DiscountPolicy discountPolicy;\n\n public Movie(String title, Duration runningTime, Money fee) {\n this(title, runningTime, fee, new AmountDiscountPolicy(...));\n } \n\n public Movie(String title, Duration runningTime, Money fee, DiscountPolicy discountPolicy) {\n this.discountPolicy = discountPolicy;\n }\n}\n 모든 결합도가 모이는 새로운 클래스를 추가함으로써 사용성과 유연성이라는 두 마리 토끼를 잡을 수 있는 경우도 있다.
\n의존성이 불편한 이유는 그것이 항상 변경에 대한 영향을 암시하기 때문
\npublic abstract class DiscountPolicy {\n \n private List<DiscountCondition> conditions = new ArrayList<>();\n\n public void switchConditions(List<DiscountCondition> conditions) {\n this.conditions = conditions;\n }\n}\n ArrayList의 코드가 수정될 확률은 0에 가깝기 때문에 인스턴스를 직접 생성하더라도 문제가 되지 않는다.List를 사용하여 다양한 객체로 대체가능하도록 설계public class Movie {\n\n private DiscountPolicy discountPolicy;\n\n public Movie(String title, Duration runningTime, Money fee) {\n this(title, runningTime, fee, null);\n } \n\n public Movie(String title, Duration runningTime, Money fee, DiscountPolicy discountPolicy) {\n this.discountPolicy = discountPolicy;\n }\n\n public Money calculateMovieFee(Screening screening) {\n if (discountPolicy == null) {\n return fee;\n }\n\n return fee.minus(discountPolicy.calculateDiscountAmount(screening))\n }\n}\n public class NoneDiscountPolicy extends DiscountPolicy {\n \n @Override\n protected Money getDiscountAmount(Screening screening) {\n return Money.ZERO;\n }\n}\n 설계를 유연하게 만들 수 있었던 이유는 Movie가 DiscountPolicy라는 추상화에 의존하고, 생성자를 통해 DiscountPolicy에 대한 의존성을 명시적으로 드러냈으며, new와 같이 구체 클래스를 직접적으로 다뤄야 하는 책임을 Movie 외부로 옮겼기 때문이다.
어떤 객체와 협력하느냐에 따라 객체의 행동이 달라지는 것은 유연하고 재사용 가능한 설계가 가진 특징이다. 유연하고 재사용 가능한 설계는 응집도 높은 책임들을 가진 작은 객체들을 다양한 방식으로 연결함으로써 애플리케이션의 기능을 쉽게 확장할 수 있다.
\n훌륭한 객체지향 설계란 객체가 어떻게 하는지를 표현하는 것이 아니라 객체들의 조합을 선언적으로 표현함으로써 객체들이 무엇을 하는지를 표현하는 설계다.
\n설계를 창조하는 데 있어서의 핵심은 의존성을 관리하는 것이다.
","excerpt":"협력은 필수적이지만 과도한 협력은 설계를 곤경에 빠트릴 수 있다. 협력을 위해서는 의존성이 필요하지만 과도한 의존성은 애플리케이션을 수정하기 어렵게 만든다. 객체지향 설계의 핵심은 협력을 위해 필요한 의존성은 유지하면서도 변경을 방해하는 의존성은 제거하는데 있다. 이런 관점에서 객체지향 설계란 의존성을 관리하는 것이고 객체가 변화를 받아들일 수 있게 의존성을 정리하는 기술이라고 할 수 있다. 📖 8.1 의존성 이해하기 🔖 8.1.…","fields":{"slug":"/backend/object/chapter8/의존성_관리하기/"},"frontmatter":{"title":"Object - 8장 의존성 관리하기","thumbnail":{"childImageSharp":{"fluid":{"src":"/static/dd0e1990925e942697544e2bdcd9332e/9b73b/object.png"}}},"draft":false,"category":"Back-End","tags":["java"],"date":"October 15, 2023"}},"node":{"id":"5c30d890-7e1f-5638-9630-e5d1dea7f6c9","html":"사람의 기억은 단기 기억과 장기 기억으로 분류할 수 있다. 실제로 문제를 해결하기 위해 사용하는 저장소는 장기 기억이 아니라 단기 기억이다.
\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