사람의 기억은 단기 기억과 장기 기억으로 분류할 수 있다. 실제로 문제를 해결하기 위해 사용하는 저장소는 장기 기억이 아니라 단기 기억이다.
\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
Movie를 새로운 컨텍스트에 사용되도록 확장할 수 있었던 것OCP를 수용하는 코드는 컴파일타임 의존성을 수정하지 않고도 런타임 의존성을 쉽게 변경할 수 있다. 의존성 관점에서 OCP를 따르는 설계란 컴파일타임 의존성은 유지하면서 런타임 의존성의 가능성을 확장하고 수정할 수 있는 구조라고 할 수 있다.
\nOCP의 핵심은 추상화에 의존하는 것
\npublic abstract class DiscountPolicy {\n private final List<DiscountCondition> conditions;\n \n protected DiscountPolicy(DiscountCondition... conditions) {\n this.conditions = Arrays.asList(conditions);\n }\n \n public Money calculateDiscountAmount(Screening screening) {\n for (DiscountCondition condition : conditions) {\n if (condition.isSatisfiedBy(screening)) {\n return getDiscountAmount(screening);\n }\n }\n return screening.getMovieFee();\n }\n protected abstract Money getDiscountAmount(Screening screening);\n}\n @AllArgsConstructor\npublic class Movie {\n\n private String title;\n\n private Duration runningTime;\n\n @Getter\n private Money fee;\n\n private DiscountPolicy discountPolicy;\n \n public Money calculateMovieFee(Screening screening) {\n return fee.minus(discountPolicy.calculateDiscountAmount(screening));\n }\n}\n Movie는 안정된 추상화인 DiscountPolicy에 의존하기 때문에 할인 정책을 추가하기 위해 DiscountPolicy의 자식 클래스를 추가하더라도 영향을 받지 않는다. 따라서 수정에 대해 닫혀 있다.추상화를 했다고 해서 모든 수정에 대해 설계가 폐쇄되는 것은 아니다. 추상화가 수정에 대해 닫혀 있을 수 있는 이유는 변경되지 않을 부분을 신중하게 결정하고 올바른 추상화를 주의 깊게 선택했기 때문이다.
\n결합도가 높아질수록 개방-폐쇄 원칙을 따르는 구조를 설계하기가 어려워진다.
\n유연하고 재사용 가능한 설계를 원한다면 객체에 대한 생성과 사용을 분리(seperating use from creation) 해야 한다.
\n사용으로부터 생성을 분리하는 데 사용되는 가장 보편적인 방법은 객체를 생성할 책임을 클라이언트로 옮기는 것
\n\n\n생성과 사용을 분리하기 위해 객체 생성에 특화된 객체를 FACTORY라고 부른다.
\n
public class Factory {\n public Movie createAvatarMovie() {\n return new Movie("아바타", Duration.ofMinutes(120), Money.wons(10000), new AmountDiscountPolicy(...));\n }\n}\n @AllArgsConstructor\npublic class Client {\n private Factory factory;\n\n public Money getAvatarFee() {\n Movie avatar = factory.createAvatarMovie();\n return avatar.getFee();\n }\n}\n 도메인 모델은 Information expert를 찾기 위해 참조할 수 있는 일차적인 재료다.
\n시스템을 객체로 분해하는 데는 크게 두 가지 방식이 존재
\n표현적 분해
\n행위적 분해
\n도메인 개념이 만족스럽지 못하다면 주저하지 말고 인공적인 객체를 창조하라. 객체지향이 실세계의 모방이라는 말은 옳지 않다.
\n의존성 주입: 사용하는 객체가 아닌 외부의 독립적인 객체가 인스턴스를 생성한 후 이를 전달해서 의존성을 해결하는 방법
\nMovie avatar = new Movie("아바타", Duration.ofMinutes(120), Money.wons(10000), new AmountDiscountPolicy(...));\n avatar.setDiscountPolicy(new AmountDiscountPolicy(...));\n avatar.calculateDiscountAmount(screening, new AmountDiscountPolicy(...));\n Service Locator 패턴
\n@NoArgsConstructor(access = AccessLevel.PRIVATE)\npublic class ServiceLocator {\n \n private static final ServiceLocator soleInstance = new ServiceLocator();\n private DiscountPolicy discountPolicy;\n \n public static DiscountPolicy discountPolicy() {\n return soleInstance.discountPolicy;\n }\n \n public static void provide(DiscountPolicy discountPolicy) {\n soleInstance.discountPolicy = discountPolicy;\n }\n}\n ServiceLocator.provide(new AmountDiscountPolicy(...));\nMovie avatar = new Movie("아바타", Duration.ofMinutes(120), Money.wons(10000));\n 의존성을 구현 내부로 감출 경우
\n의존성 주입을 지원하는 프레임워크를 사용하지 못하는 경우나 깊은 호출 계층에 걸쳐 동일한 객체를 계속해서 전달해야 하는 고통을 견디기 어려운 경우에는 어쩔 수 없이 Service Locator 패턴을 사용하는 것을 고려하라.
\npublic class Movie {\n private AmountDiscountPolicy discountPolicy;\n}\n 의존성은 변경의 전파와 관련된 것이기 때문에 설계는 변경의 영향을 최소화하도록 의존성을 관리해야 한다.
\n가장 중요한 것은 추상화에 의존하는 것이다.
\n의존성 역전 원칙(Dependency Inversion Principle, DIP)
\n역전은 의존성의 방향뿐만 아니라 인터페이스의 소유권에도 적용된다.
\nMovie를 다양한 컨텍스트에서 재사용하기 위해서는 불필요한 클래스들이 Movie와 함께 배포해야한 한다.Separated interface 패턴
\n의존성 역전 원칙에 따라 상위 수준의 협력 흐름을 재사용하기 위해서는 추상화가 제공하는 인터페이스의 소유권 역시 역전시켜야 한다.
\n유연하고 재사용 가능한 설계가 항상 좋은 것은 아니다.
\n복잡성에 대한 걱정보다 유연하고 재사용 가능한 설계의 필요성이 더 크다면 코드의 구조와 실행 구조를 다르게 만들어라.
\n설계를 유연하게 만들기 위해서는 먼저 역할, 책임, 협력에 초점을 맞춰야 한다.
\n불필요한 Singleton 패턴은 객체 생성에 관해 너무 이른 시기에 고민하고 결정할 때 도입되는 경향이 있다.
\n이번 장에서 설명한 다양한 기법들을 적용하기 전에 역할, 책임, 협력의 모습이 선명하게 그려지지 않는다면 의존성을 관리하는 데 들이는 모든 노력이 물거품이 될 수도 있다는 사실을 명심하라.
","excerpt":"📖 9.1 개방-폐쇄 원칙 소프트웨어 개체(클래스, 모듈, 함수 등등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다. 확장에 대해 열려 있다: 애플리케이션의 요구사항이 변경될 때 이 변경에 맞게 새로운 '동작'을 추가해서 애플리케이션의 기능을 확장할 수 있다. 수정에 대해 닫혀 있다: 기존의 '코드'를 수정하지 않고도 애플리케이션의 동작을 추가하거나 변경할 수 있다. 🔖 9.1.…","fields":{"slug":"/backend/object/chapter9/유연한_설계/"},"frontmatter":{"title":"Object - 9장 유연한 설계","thumbnail":{"childImageSharp":{"fluid":{"src":"/static/dd0e1990925e942697544e2bdcd9332e/9b73b/object.png"}}},"draft":false,"category":"Back-End","tags":["java"],"date":"October 22, 2023"}},"node":{"id":"7df70221-cf06-58ea-9288-34d2e832195f","html":"협력은 필수적이지만 과도한 협력은 설계를 곤경에 빠트릴 수 있다. 협력을 위해서는 의존성이 필요하지만 과도한 의존성은 애플리케이션을 수정하기 어렵게 만든다.
\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"}}}},"staticQueryHashes":["2374173507","2996537568","3691437124"]}