• 목차

도시를 세운다면

도시 - 추상화와 모듈화 덕분에 큰 그림을 이해하지 못할지라도 개인이 관리하는 구성요소는 효율적으로 돌아감

⇒ 시스템 수준에서도 코드를 깨끗하게 유지하는 방법

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

• 제작 ≠ 사용 소프트웨어 시스템은 준비 과정과 런타임 로직을 분리해야 한다

• 시작 단계는 모든 어플리케이션이 풀어야 할 관심사이다.

  • 관심사 분리 (Seperation of concerns)

  public Service getService() {
  	if(service == null)
  		service = new MyServiceImpl(...);
  	return service;
  }
  

  • 초기화 지연

    장점

    1. 필요할 때까지 객체 생성 X ∴ 부하 없음. 빨라짐.

    2. null 포인터 반환 X

    단점

    1. getService 메서드가 MyServiceImpl과 생성자 인수에 의존함.

       → 런타임 로직에서 MyServiceImpl 객체를 사용하지 않더라도 의존성 해결 없이는 컴파일이 안됨.

    2. 테스트 시 MyServiceImpldl이 무거운 객체라면 단일 책임 원칙 위배.

    3. 모든 상황에서 MyServiceImpl가 적합한지 모름

    4. 모듈성 ↓, 중복 多

  ⇒ 설정 논리는 일반 실행 논리와 분리해야 모듈성이 높아진다.

  사용과 제작을 분리하는 3가지 방법 ⇒ main 분리, 팩토리, 의존성 주입

• Main 분리

• 팩토리

• ❓의존성 주입

확장

TDD(테스트 주도 개발)과 리펙터링으로 얻어지는 깨끗한 코드는 코드 수준에서 시스템을 조정하고 확장하기 쉽게 만든다.

관심사를 적절히 분리해 관리한다면 소프트웨어 아키텍처는 발전할 수 있다.

• 관심사를 적절히 분리하지 못하는 아키텍처 예

  → EJB1, EJB2

  • 예시)
  • 단점
    1. 비지니스 로직이 EJB2 컨테이너와 강하게 결합되어 있어, 클래스 생성 시 컨테이너에서 파생해야 하며 컨테이너의 다양한 생명주기 메서드를 제공해야 한다.
    2. 비지니스 로직이 덩치 큰 컨테이너와 밀접하게 결합되어 독자적인 단위 테스트가 어렵다.
    3. 객체 지향 프로그래밍의 개념이 무너진다. 빈은 다른 빈을 상속 받지 못한다. 일반적으로 EJB2 빈은 DTO(Data Transfer Object)를 정의한다. DTO는 메서드가 없는 사실상의 구조체이므로 동일한 정보를 저장하는 자료 유형이 두 개가 된다. 그래서 객체 간의 자료를 복사하는 반복적인 코드가 필요하다.

• 횡단(cross-cutting) 관심사