19 정책과 수준

소프트웨어 시스템

• 입력을 출력으로 변환하는 정책을 상세하게 기술한 설명서

• 정책을 신중하게 분리

• 정책이 변경되는 양상에 따라 정책을 재편성하는 일

• 동일한 시점에 변경되는 정책은 동일 수준, 동일 컴포넌트 에 속해야 댐

수준

입력과 출력까지의 거리

1 잘못된 아키텍처

function encrypt(){ // 고수준
    while(true)
			// 저수준 read/writer Char 의존
	    writeChar(translate(readChar())); 
}

2 더 나은 아키텍처

• 고수준 정책은, 덜 빈번하게 변경되고, 더 중요한 이유로 변경됨

• 저수준 정책은, 더 빈번하게 변경되고, 덜 중요함

저수준 컴포넌트가 고수준 컴포넌트에 플러그인 되어야 한다

결론

• 단일 책임 원칙(SRP) 7

• 개방 폐쇄 원칙 (OCP) 8

• 공통 폐쇄 원칙 (CCP) 13
• 동일한 이유로 동일한 시점에 변경되는 클래스를 같은 컴포넌트로 묶어라
• 서로 다른 시점에 다른 이유로 변경되는 클래스는 다른 컴포넌트로 묶어라
• SRP를 컴포넌트 관점에서 다시 쓴 것
• 대다수의 애플리케이션에서 유지보수성은 재사용성보다 훨씬 중요하다
• 변경이 여러 컴포넌트에서 일어나는것보다 단일 컴포넌트에서 발생하는것이 훨씬 낫다.
• OCP와도 밀접하게 관련되어 있다.
• 100% 완전한 폐쇄란 불가능하므로 전략적으로 폐쇄해야 한다.

• 의존성 역전 원칙 (DIP) 11

• 안정된 의존성 원칙 (SDP)14
• 안정성의 방향으로(더 안정된 쪽에) 의존해라
• 설계는 결코 정적일 수 없다.

• 안정된 추상화 원칙 (SAP) 14
• 안정된 추상화 원칙은 안정성과 추상화 정도 사이의 관계를 정의한다.
• 컴포넌트는 안정된 정도만큼만 추상되어야 한다.
• 정책 만큼만 추상화 되어야 한다?
• 추상화 방향으로 의존성을 향해야 한다.
• 고수준 정책을 안정된 컴포넌트에 위치시키면 그 정책을 포함하는 소스코드는 수정하기 어려워진다