협력은 필수적이지만 과도한 협력은 설계를 곤경에 빠트릴 수 있다. 협력을 위해서는 의존성이 필요하지만 과도한 의존성은 애플리케이션을 수정하기 어렵게 만든다.
\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"}},"previous":{"id":"a37febe6-8388-5efc-91d5-5fac75bdd784","html":"코드를 재사용하려는 강력한 동기 이면에는 중복된 코드를 제거하려는 욕망이 숨어 있다.
\n중복 코드는 사람들의 마음속에 의심과 불신의 씨앗을 뿌린다.
\n중복 코드는 변경을 방해한다. 이것이 중복 코드를 제거해야 하는 가장 큰 이유다.
\n\n\nDon't Repeat Yourself
\n
@RequiredArgsConstructor\npublic class Call {\n \n @Getter\n private final LocalDateTime from;\n \n private final LocalDateTime to;\n\n public Duration getDuration() {\n return Duration.between(from, to);\n }\n}\n @Getter\n@RequiredArgsConstructor\npublic class Phone {\n\n private final Money amount;\n\n private final Duration seconds;\n\n private List<Call> calls = new ArrayList<>();\n\n public void call(Call call) {\n calls.add(call);\n }\n\n public Money calculateFee() {\n Money result = Money.ZERO;\n\n for (Call call : calls) {\n result = result.plus(amount.times((double) call.getDuration().getSeconds() / seconds.getSeconds()));\n }\n\n return result;\n }\n}\n @RequiredArgsConstructor\npublic class NightlyDiscountPhone {\n \n private static final int LATE_NIGHT_HOUR = 22;\n\n private final Money nightlyAmount;\n\n private final Money regularAmount;\n\n private final Duration seconds;\n\n private List<Call> calls = new ArrayList<>();\n\n public Money calculateCallFee() {\n Money result = Money.ZERO;\n\n for (Call call : calls) {\n if (call.getFrom().getHour() >= LATE_NIGHT_HOUR) {\n result = result.plus(nightlyAmount.times((double) call.getDuration().getSeconds() / seconds.getSeconds()));\n } else {\n result = result.plus(regularAmount.times((double) call.getDuration().getSeconds() / seconds.getSeconds()));\n }\n }\n\n return result;\n }\n}\n 새로운 요구사항: 통화 요금에 부과할 세금 계산
\n@Getter\n@RequiredArgsConstructor\npublic class Phone {\n\n private final Money amount;\n\n private final Duration seconds;\n \n private final double taxRate;\n\n private List<Call> calls = new ArrayList<>();\n\n public void call(Call call) {\n calls.add(call);\n }\n\n public Money calculateFee() {\n Money result = Money.ZERO;\n\n for (Call call : calls) {\n result = result.plus(amount.times((double) call.getDuration().getSeconds() / seconds.getSeconds()));\n }\n\n return result.plus(result.times(taxRate));\n }\n}\n @RequiredArgsConstructor\npublic class NightlyDiscountPhone {\n\n private static final int LATE_NIGHT_HOUR = 22;\n\n private final Money nightlyAmount;\n \n private final Money regularAmount;\n \n private final Duration seconds;\n \n private final double taxRate;\n \n private List<Call> calls = new ArrayList<>();\n\n public Money calculateCallFee() {\n Money result = Money.ZERO;\n\n for (Call call : calls) {\n if (call.getFrom().getHour() >= LATE_NIGHT_HOUR) {\n result = result.plus(nightlyAmount.times((double) call.getDuration().getSeconds() / seconds.getSeconds()));\n } else {\n result = result.plus(regularAmount.times((double) call.getDuration().getSeconds() / seconds.getSeconds()));\n }\n }\n\n return result.minus(result.times(taxRate));\n }\n}\n minus를 호출하고 있다.@Getter\n@RequiredArgsConstructor\npublic class Phone {\n\n private static final int LATE_NIGHT_HOUR = 22;\n\n enum PhoneType {REGULAR, NIGHTLY}\n\n private final PhoneType type;\n\n private final Money amount;\n\n private final Money regularAmount;\n\n private final Money nightlyAmount;\n\n private final Duration seconds;\n\n private List<Call> calls = new ArrayList<>();\n\n public Phone(Money amount, Duration seconds) {\n this(PhoneType.REGULAR, amount, Money.ZERO, Money.ZERO, seconds);\n }\n\n public Phone(Money regularAmount, Money nightlyAmount, Duration seconds) {\n this(PhoneType.NIGHTLY, Money.ZERO, regularAmount, nightlyAmount, seconds);\n }\n\n public Money calculateFee() {\n Money result = Money.ZERO;\n\n for (Call call : calls) {\n if (type == PhoneType.REGULAR) {\n result = result.plus(amount.times((double) call.getDuration().getSeconds() / seconds.getSeconds()));\n } else {\n if (call.getFrom().getHour() >= LATE_NIGHT_HOUR) {\n result = result.plus(nightlyAmount.times((double) call.getDuration().getSeconds() / seconds.getSeconds()));\n } else {\n result = result.plus(regularAmount.times((double) call.getDuration().getSeconds() / seconds.getSeconds()));\n }\n }\n }\n\n return result;\n }\n}\n public class NightlyDiscountPhone extends Phone {\n private static final int LATE_NIGHT_HOUR = 22;\n\n private Money nightlyAmount;\n\n public NightlyDiscountPhone(Money nightlyAmount, Money regularAmount, Duration seconds) {\n super(regularAmount, seconds);\n this.nightlyAmount = nightlyAmount;\n }\n\n @Override\n public Money calculateFee() {\n Money result = super.calculateFee();\n \n Money nightlyFee = Money.ZERO;\n for (Call call : getCalls()) {\n if (call.getFrom().getHour() >= LATE_NIGHT_HOUR) {\n nightlyFee = nightlyFee.plus(getAmount().minus(nightlyAmount.times((double) call.getDuration().getSeconds() / getSeconds().getSeconds())));\n }\n }\n \n return result.minus(nightlyFee);\n }\n}\n 새로운 요구사항: 세금 부과
\n@Getter\n@RequiredArgsConstructor\npublic class Phone {\n\n private final Money amount;\n\n private final Duration seconds;\n\n private final double taxRate;\n\n private List<Call> calls = new ArrayList<>();\n\n public Money calculateFee() {\n Money result = Money.ZERO;\n\n for (Call call : calls) {\n result = result.plus(amount.times((double) call.getDuration().getSeconds() / seconds.getSeconds()));\n }\n\n return result.plus(result.times(taxRate));\n }\n}\n public class NightlyDiscountPhone extends Phone {\n private static final int LATE_NIGHT_HOUR = 22;\n\n private Money nightlyAmount;\n\n public NightlyDiscountPhone(Money nightlyAmount, Money regularAmount, Duration seconds, double taxRate) {\n super(regularAmount, seconds, taxRate);\n this.nightlyAmount = nightlyAmount;\n }\n\n @Override\n public Money calculateFee() {\n Money result = super.calculateFee();\n\n Money nightlyFee = Money.ZERO;\n for (Call call : getCalls()) {\n if (call.getFrom().getHour() >= LATE_NIGHT_HOUR) {\n nightlyFee = nightlyFee.plus(getAmount().minus(nightlyAmount.times((double) call.getDuration().getSeconds() / getSeconds().getSeconds())));\n }\n }\n\n return result.minus(nightlyFee.plus(nightlyFee.times(getTaxRate())));\n }\n}\n \n\n자식 클래스의 메서드 안에서 super 참조를 이용해 부모 클래스의 메서드를 직접 호출할 경우 두 클래스는 강하게 결합된다. super 호출을 제거할 수 있는 방법을 찾아 결합도를 제거하라.
\n
Java 초기 버전의 대표적인 사례
\njava.util.Stack\njava.util.Properties\n\n\n상속받은 부모 클래스의 메서드가 자식 클래스의 내부 구조에 대한 규칙을 깨트릴 수 있다.
\n
\n\n자식 클래스가 부모 클래스의 메서드를 오버라이딩할 경우 부모 클래스가 자식의 메서드를 사용하는 방법에 자식 클래스가 결합될 수 있다.
\n
@Getter\n@RequiredArgsConstructor\npublic class Song {\n\n private final String singer;\n \n private final String title;\n}\n public class Playlist {\n\n @Getter\n private final List<Song> tracks = new ArrayList<>();\n\n public void append(Song song) {\n getTracks().add(song);\n }\n}\n public class PersonalPlaylist extends Playlist {\n \n public void remove(Song song) {\n getTracks().remove(song);\n }\n}\n @Getter\npublic class Playlist {\n\n private final List<Song> tracks = new ArrayList<>();\n\n private final Map<String, String> singers = new HashMap<>();\n\n public void append(Song song) {\n getTracks().add(song);\n singers.put(song.getSinger(), song.getTitle());\n }\n}\n public class PersonalPlaylist extends Playlist {\n\n public void remove(Song song) {\n getTracks().remove(song);\n getSingers().remove(song.getSinger());\n }\n}\n \n\n클래스를 상속하면 결합도로 인해 자식 클래스와 부모 클래스의 구현을 영원히 변경하지 않거나, 자식 클래스와 부모 클래스를 동시에 변경하거나 둘 중 하나를 선택할 수 밖에 없다.
\n
코드 중복을 제거하기 위해 상속을 도입할 때 따르는 원칙
\n@Getter\n@RequiredArgsConstructor\npublic class Phone {\n\n private final Money amount;\n\n private final Duration seconds;\n\n private List<Call> calls = new ArrayList<>();\n\n public Money calculateFee() {\n Money result = Money.ZERO;\n\n for (Call call : calls) {\n result = result.plus(calculateCallFee(call));\n }\n\n return result;\n }\n\n private Money calculateCallFee(Call call) {\n return amount.times((double) call.getDuration().getSeconds() / seconds.getSeconds());\n }\n}\n @RequiredArgsConstructor\npublic class NightlyDiscountPhone {\n\n private static final int LATE_NIGHT_HOUR = 22;\n\n private final Money nightlyAmount;\n\n private final Money regularAmount;\n\n private final Duration seconds;\n\n private List<Call> calls = new ArrayList<>();\n\n public Money calculateCallFee() {\n Money result = Money.ZERO;\n\n for (Call call : calls) {\n result = result.plus(calculateCallFee(call));\n }\n\n return result;\n }\n\n private Money calculateCallFee(Call call) {\n if (call.getFrom().getHour() >= LATE_NIGHT_HOUR) {\n return nightlyAmount.times((double) call.getDuration().getSeconds() / seconds.getSeconds());\n }\n return regularAmount.times((double) call.getDuration().getSeconds() / seconds.getSeconds());\n }\n}\n public abstract class AbstractPhone {\n\n private final List<Call> calls = new ArrayList<>();\n\n public Money calculateFee() {\n Money result = Money.ZERO;\n\n for (Call call : calls) {\n result = result.plus(calculateCallFee(call));\n }\n\n return result;\n }\n\n protected abstract Money calculateCallFee(Call call);\n}\n @Getter\n@RequiredArgsConstructor\npublic class Phone extends AbstractPhone{\n\n private final Money amount;\n\n private final Duration seconds;\n\n @Override\n protected Money calculateCallFee(Call call) {\n return amount.times((double) call.getDuration().getSeconds() / seconds.getSeconds());\n }\n}\n @RequiredArgsConstructor\npublic class NightlyDiscountPhone extends AbstractPhone {\n\n private static final int LATE_NIGHT_HOUR = 22;\n\n private final Money nightlyAmount;\n\n private final Money regularAmount;\n\n private final Duration seconds;\n\n @Override\n protected Money calculateCallFee(Call call) {\n if (call.getFrom().getHour() >= LATE_NIGHT_HOUR) {\n return nightlyAmount.times((double) call.getDuration().getSeconds() / seconds.getSeconds());\n }\n return regularAmount.times((double) call.getDuration().getSeconds() / seconds.getSeconds());\n }\n}\n public abstract class Phone {\n}\n\npublic class RegularPhone extends Phone {\n}\n\npublic class NightlyDiscountPhone extends Phone {\n}\n @RequiredArgsConstructor\npublic abstract class Phone {\n \n private final double taxRate;\n \n private List<Call> calls = new ArrayList<>();\n\n public Money calculateFee() {\n Money result = Money.ZERO;\n\n for (Call call : calls) {\n result = result.plus(calculateCallFee(call));\n }\n\n return result.plus(result.times(taxRate));\n }\n\n protected abstract Money calculateCallFee(Call call);\n}\n @Getter\npublic class RegularPhone extends Phone {\n\n private final Money amount;\n\n private final Duration seconds;\n\n public RegularPhone(double taxRate, Money amount, Duration seconds) {\n super(taxRate);\n this.amount = amount;\n this.seconds = seconds;\n }\n\n @Override\n protected Money calculateCallFee(Call call) {\n return amount.times((double) call.getDuration().getSeconds() / seconds.getSeconds());\n }\n}\n public class NightlyDiscountPhone extends Phone {\n\n private static final int LATE_NIGHT_HOUR = 22;\n\n private final Money nightlyAmount;\n\n private final Money regularAmount;\n\n private final Duration seconds;\n\n public NightlyDiscountPhone(double taxRate, Money nightlyAmount, Money regularAmount, Duration seconds) {\n super(taxRate);\n this.nightlyAmount = nightlyAmount;\n this.regularAmount = regularAmount;\n this.seconds = seconds;\n }\n\n @Override\n protected Money calculateCallFee(Call call) {\n if (call.getFrom().getHour() >= LATE_NIGHT_HOUR) {\n return nightlyAmount.times((double) call.getDuration().getSeconds() / seconds.getSeconds());\n }\n return regularAmount.times((double) call.getDuration().getSeconds() / seconds.getSeconds());\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"}}}},"staticQueryHashes":["2374173507","2996537568","3691437124"]}