정책과 수준
좋은 아키텍처라면 각 컴포넌트를 연결할 때 의존성의 방향이 컴포넌트의 수준을 기반으로 연결되도록 만들어야 한다. 즉, 저수준 컴포넌트가 고수준 컴포넌트에 의존하도록 설계되어야 한다.
정책
- 소프트웨어 시스템이란 정책을 기술한 것이다. 실제로 컴퓨터 프로그램의 핵심부는 이게 전부다. 컴퓨터 프로그램은 각 입력을 출력으로 변환하는 정책을 상세하게 기술한 설명서다.
- 소프트웨어 아키텍처를 개발하는 기술에는 이러한 정책을 신중하게 분리하고, 정책이 변경되는 양상에 따라 정책을 재편성하는 일도 포함된다. 동일한 이유로 동일한 시점에 변경되는 정책은 함께 묶인다
- 정책을 컴포넌트로 묶는 기준은 정책이 변경되는 방식에 달려있다는 사실을 상기하기(SRP와 CCP)
- 흔히 아키텍처 개발은 재편성된 컴포넌트들을 비순환 방향 그래프로 구성하는 기술을 포함한다
- 정점: 동일한 수준의 정책을 포함하는 컴포넌트
- 방향이 있는 간선 : 컴포넌트 사이의 의존성
수준
- 엄밀하게 정의하자면 입력과 출력까지의 거리다.
- 입력과 출력 모두로부터 멀리 위치 할수록 ⇒ 정책의 수준은 높아진다.
- 입력과 출력을 다루는 정책 ⇒ 시스템에서 최하위 수준
간단한 암호화 프로그램의 예시
입력 장치에서 문자를 읽어서 테이블을 참조하여 문자를 번역한 후 번역된 문자를 출력 장치로 기록하는 프로그램이다.
잘못된 아키텍처
function encrypt() { while(true) writeChar(translate(readChar())); }
- 고수준인 encrypt 함수가 저수준의 readChar함수와 writeChar함수에 직접적으로 의존하기에 잘못된 아키텍처임
개선된 아키텍처
- 이렇게 고수준의 암호화 정책을 저수준의 입출력 정책과 분리하고 의존성을 고수준 정책쪽으로 갖게 함으로써 암호화 정책을 더 넓은 맥락에서 사용할 수 있다. 입력과 출력에 변화가 생기더라도 암호화 정책은 거의 영향을 받지 않기 때문이다.
정책을 컴포넌트로 묶는 기준
- 정책을 컴포넌트로 묶는 기준은 정책이 변경되는 방식에 달려 있다
- 단일 책임 원칙과 공통 폐쇄 원칙에 따르면 동일한 이유로 동일한 시점에 변경되는 정책은 함께 묶여야 한다.
- 고수준 정책 : 덜 빈번하게 변경, 보다 중요한 이유로 변경됨
- 저수준 정책 : 더 빈번하게 변경되며 덜 중요한 이유로 변경되는 경향이 있음
- 모든 소스 코드 의존성의 방향이 고수준 정책을 향할 수 있도록 정책을 분리했다면 변경의 영향도를 줄일 수 있다.
결론
이 장에서 설명한 정책에 대한 논의는 단일책임원칙, 개방 폐쇄 원칙, 공통 폐쇄 원칙, 의존성 역전 원칙, 안정된 의존성 원칙, 안정된 추상화 원칙을 모두 포함한다.
단일 책임원칙 : 단일 변경의 이유로 변경되는 클래스는 하나여야 한다. 입력과 출력의 방식을 변경시킬 때, Char Reader, Char Writer 쪽은 변경시킬 필요 없이 Console Reader, Console Writer만 변경하면 됨
개방 폐쇄 원칙 : Char Reader와 Char Writer 인터페이스를 도입함으로 입출력의 방식이 변경될 때 변경은 필요 없고 구체 클래스를 확장만 하면 됨
공통 폐쇄 원칙 : 같이 변경되는 애들은 같은 컴포넌트 안에 들어있어야 한다. 암호화 알고리즘이 바뀔 때, 문자를 읽고 문자를 출력하는 방식 자체가 바뀌는건 아니고 그걸 이용하는 순서가 바뀔 수 있음. 그래서 Char Reader, CharWriter, Encrypt 는 함께 바뀜
의존성 역전 원칙 : 중간에 인터페이스를 둠으로, 고수준 정책이 저수준 정책에 의존하지 않고 의존성의 방향이 반대가 됨
안정된 의존성 원칙 : 더 안정한 쪽으로 의존성을 가져야 한다. Encrypt 암호화 로직은 다른 여러 곳에서 더 넓게 쓰일 수 있으니 이 쪽이 더 안정한 컴포넌트. 그러므로 이쪽으로 의존성을 가져야 한다.
안정된 추상화 원칙 : 컴포넌트는 안정된 정도만큼 추상화 되어야 한다. Encrypt 암호화 모듈을 갖고 있는 컴포넌트는 여러 컴포넌트에서 쓰일 수 있으므로 추상화 되어서 사용되어야 한다. (중간에 인터페이스 도입)