도시를 세운다면?

우리가 혼자서 도시를 세우고 직접 관리할 수 있을까? 불가능하다.
일상적으로 잘 돌아가고 있는 도시에는 여러 분야를 관리하는 팀이 존재한다.

도시가 잘 돌아가는 이유는 적절한 추상화와 모듈화 때문이다.

소프트웨어 팀도 도시처럼 구성해야 한다. 이 장에서는 높은 추상화 수준에서도 깨끗함을 유지하는 방법을 살펴본다.

시스템 제작과 시스템 사용을 분리하라

소프트웨어 시스템은 준비 과정과 런타임 로직을 분리해야 한다.

Main 분리

생성과 관련한 코드는 모두 main이나 main이 호출하는 모듈로 옮기고, 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정한다.

main에서 시스템에 필요한 객체를 생성하고, 이를 애플리케이션에 넘긴다. 애플리케이션은 넘겨받은 객체를 사용한다.

팩토리

: 하위 class에서 객체의 구체적인 생성 방법을 결정해서 사용하는 Design pattern

상위 class에는 추상 method가 존재한다. 하위 class에서는 구체적으로 객체를 어떻게 생성할 것인지를 기술한다.

의존성 주입

: 클래스간 의존성을 클래스 외부에서 주입하는 것. 사용과 제작을 분리하는 강력한 메커니즘

public class UserDAO {
	
	private ConnectionMaker connectionMaker;
	
	// 객체를 주입 받는다.
	public UserDAO(ConnectionMaker connectionMaker) {
		this.connectionMaker = connectionMaker;
	}
    
    ...
}

확장

군락은 마을로, 마을은 도시로 점점 확장한다. 확장하면서 여러 서비스가 생겨난다. 하지만 확장이 일어나기는 어렵다.

소프트웨어 시스템은 관심사를 적절히 분리해야 점진적을 발전할 수 있다.

횡단(cross-cutting) 관심사

관심사는 시스템에서 하나의 기능이나 모듈을 의미한다.

모든 객체가 전반적으로 동일한 방식을 이용하게 만들어야 한다.
모든 핵심 관심 사항에 공통적으로 들어가는 코드를 횡단 관심사라고 한다.
핵심 관심 사항은 프로그램에서 주요한 기능을 말한다.

자바에서 사용하는 관점과 유사한 메커니즘

• 자바 프록시
  : 개별 객체나 클래스에서 메서드 호출을 감싸는 경우 좋다.
• 순수 자바 AOP 프레임워크
  : 프록시 코드를 자동화한다.
• AspectJ 관점
  : 관심사를 관점으로 분리하는 가장 강력한 도구이다.

테스트 주도 시스템 아키텍쳐 구축

유사한 개념으로 관심사를 분리하는 방식은 아주 좋다. 코드 수준에서 아키텍처 관심사를 분리할 수 있다면, 진정한 테스트 주도 아키텍쳐 구축이 가능해진다.

-> 어느 정도의 방향으로 잡고 빠르게 결과물을 출시한 후, 기반 구조를 추가하며 조금씩 확장해나가도 괜찮다.

의사 결정을 최적화하라

결정을 내려야 할 때, 최대한 정보를 많이 모으고, 더 고민하고, 구현 방안을 더 찾아본 후에 결정을 하도록 한다.

명백한 가치가 있을 때 표준을 현명하게 사용하라

표준을 사용하면 재사용이 쉽고, 좋은 아이디어를 캡슐화하기 쉽고, 컴포넌트를 엮기 쉽다. 하지만 표준을 만드는 시간이 너무 오래 걸리기 때문에 표준을 제정한 목적을 잊을 수도 있다.

시스템은 도메인 특화 언어가 필요하다

도메인 특화 언어를 효과적으로 사용한다면 적절한 추상화 수준에서 코드 의도를 표현할 수 있다.