09. 유연한 설계

09. 유연한 설계

태그

비어 있음

날짜

2024년 4월 28일

개방-폐쇄 원칙

소프트웨어 개체는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다.

확장과 수정은 각각 동작과 코드의 관점을 반영한다.

의존성 관점에서 개방-폐쇄 원칙을 따르는 설계란 컴파일타입 의존성은 유지하면서 런타임 의존성의 가능성을 확장하고 수정할 수 있는 구조

이 원칙의 핵심은 추상화에 의존하는 것

추상화 과정을 거치면 문맥이 바뀌더라도 변하지 않는 부분만 남게되므로 각 문맥에 적합하게 기능을 구체화하고 확장할 수 있다.

💡

단순히 어떤 개념을 추상화했다고 해서 수정에 대해 닫혀 있는 설계를 만들 수 있는 것은 아니다. 개방-폐쇄 원칙에서 폐쇄를 가능하게 하는 것은 의존성의 방향이다.

생성 사용 분리

유연하고 재사용 가능한 설계를 원한다면 객체와 관련된 두 가지 책임을 서로 다른 객체로 분리해야 한다.

Factory 추가하기

생성과 사용을 분리하기 위해 객체 생성에 특화된 객체를 FACTORY라고 부른다.

순수한 가공물에게 책임 할당하기

FACTORY를 추가한 이유는 순수하게 기술적인 결정이다.

결합도를 낮추고 재사용성을 높이기 위해 도메인 개념에게 할당돼 있던 객체 생성 책임을 가공의 객체로 이동시킨 것.

객체를 분해하는 두 가지 방식

표현적 분해

객체들을 이용해 시스템을 분해. 도메인과 소프트웨어 사이의 표현적 차이를 최소화하는 것을 목적으로 한다.

행위적 분해

책임을 할당하기 위해 창조되는 도메인과 무관한 인공적인 객체를 PURE FABRICATION이라고 부른다.

이는 보통 특정한 행동을 표현하는 것이 일반적이라 행위적 분해에 의해 생성된다.

💡

이런 측면에서 객체지향이 실세계의 모방이라는 말은 옳지 않다. 객체지향 애플리케이션은 도메인 개념뿐만 아니라 설계자들이 임의적으로 창조한 인공적인 추상화들을 포함하고 있다.

의존성 주입

사용하는 객체가 아닌 외부의 독립적인 객체가 인스턴스를 생성한 후 이를 전달해서 의존성을 해결하는 방법을 의존성 주입이라고 한다.

의존성을 해결하는 세 가지 방법

생성자 주입

setter 주입

메서드 주입

숨겨진 의존성은 나쁘다.

SERVICE LOCATOR패턴의 가장 큰 단점은 의존성을 감춘다는 것.

문제점을 코드 작성이 아니라 실행 시점으로 미룬다.

모든 단위 테스트 케이스가 같은 상태를 공유하게 된다. 단위테스트는 서로 고립돼야 한다는 기본 원칙을 위반한다.

문제의 원인은 숨겨진 의존성이 캡슐화를 위반헀기 때문이다.

→ 코드의 내부 구현을 이해할 것을 강요한다.

💡

명시적인 의존성이 숨겨진 의존성보다 좋다.

유연성에 대한 조언

유연한 설계는 유연성이 필요할 때만 옳다

설계가 유연할수록 클래스 구조와 객체 구조 사이의 거리는 점점 멀어진다.

복잡성이 필요한 이유와 합리적인 근거를 제시하지 않는다면 어느 누구도 설계를 만족스러운 해법으로 받아들이지 않을 것이다.

협력과 책임이 중요하다.

설계를 유연하게 만들기 위해서는 먼저 역할, 책임, 협력에 초점을 맞춰야 한다.

초보자가 자주 저지르는 실수 중 하나는 객체의 역할과 책임이 자리를 잡기 전에 너무 성급하게 객체 생성에 집중하는 것.

객체를 생성할 책임을 담당할 객체나 객체 생성 메커니즘을 결정하는 시점은 책임 할당의 마지막 단계로 미뤄야만 한다.

객체가 무엇이 되고 싶은지를 알게 될 때까지 객체들을 어떻게 인스턴스화 할 것인지에 대해 전혀 신경 쓰지 않았다는 것이다. 가장 중요한 관심거리는 마치 객체자 이미 존재하는 것처럼 이들 간의 관계를 신경 쓰는 일이다.

표