[클린 코드 읽고 정리해두고 다시 보기] 시스템

도시를 세운다면?

• 도시는 수도 관리 팀, 전력 관리 팀 등 적절한 추상화와 모듈화로 잘 동작한다.
• 높은 추상화 수준인 시스템 수준에서도 깨끗함을 유지하는 것이 중요하다.

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

• 소프트웨어 시스템은 애플리케이션 객체를 제작하고 의존성을 서로 연결하는 준비 과정과 이후에 이어지는 런타임 로직을 분리해야 한다.
• 여기서 말하는 시스템 제작은 코드를 작성하는 것을 말하는 것이 아니라 작성해 놓은 코드를 기반으로 동작하기 위한 객체들이 생성되고 서로 연결되는 단계를 말한다.
• 시스템 제작과 사용을 분리하지 않은 예시는 초기화 지연 기법이 대표적이다. 객체가 실제로 사용되는 시점에 생성하는 기법으로 사용 코드와 제작 코드가 결합되어 있다.

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

• 위의 예시처럼 메서드가 구체적인 구현 객체에 의존하게 된다.
• 또한 메서드가 작업을 두 가지 이상 수행하여 단일 책임 원칙을 위반하게 될 수 있다.
• 제작과 사용을 분리하기 위해서 생성과 관련된 코드는 모두 main이나 main이 호출하는 모듈로 옮기고, 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정하라.
• 객체 생성 시점을 애플리케이션이 결정해야하는 경우에는 ABSTRACT FACTORY 패턴을 사용하라. 사용 부분에서 팩토리의 인터페이스를 정의하고, 생성 부분에서 구현하는 것이다.

의존성 주입

• DI(Depedency Injection)는 IoC(Inversion of Control)기법을 의존성 관리에 적용한 메커니즘이다.
• 한 객체가 맡은 보조 책임을 새로운 객체에게 넘겨 단일 책임 원칙을 지킬 수 있다.
• DI 컨테이너는 객체의 인스턴스를 만든 후 생성자 인수나 설정자 메서드를 사용해 의존성을 설정한다. 이를 통해 DI 컨테이너가 제작을 담당하고, 런타임 로직에서는 제작 책임 없이 또 구체적인 구현 객체에 의존하지 않게 될 수 있다.

확장

• TDD, 리팩터링, 깨끗한 코드는 코드 수준에서 시스템을 조정하고 확장하기 쉽게 만든다.
• 시스템 수준에서 시스템 아키텍처를 조정하고 확장하기 위해서는 관심사를 적절히 분리해야한다.
• 영속성 프레임워크와 도메인 논리는 관심사를 분리하기에 겹치는 부분이 많다. 즉 횡단 관심사가 존재하는 것이다.
• 횡단 관심사를 대처하기 위해서는 AOP처럼 관점 메커니즘이 필요하다.

자바 프록시

• 자바 프록시는 개별 객체나 클래스에서 메서드 호출을 감싸는 단순한 상황에 적합하다.
• 코드 양과 크기가 커진다는 것이 단점이다.

순수 자바 AOP 프레임워크

• 순수 자바 관점을 구현하는 스프링 AOP, JBoss AOP 등과 같은 여러 자바 프레임워크는 내부적으로 프록시를 사용한다.
• 스프링은 엔터프라이즈 프레임워크에 의존하지 않는 POJO에 순수하게 도메인에 초점을 맞춘 비즈니스 로직을 구현한다.
• POJO는 xml과 같은 설정 파일 또는 애너테이션 기반으로 중첩적으로 프록시된다.
• POJO에는 순수 도메인 비즈니스 로직 관심사에 대한 코드만 존재하고 다른 관심사는 외부에 존재하게 된다. 애플리케이션은 스프링과 독립적이게 되고 강결합 문제가 해결된다.

AspectJ 관점

• AspectJ 언어는 관심사를 관점으로 분리하는 가장 강력한 도구다.
• 새 도구를 사용하고 새 언어 문법과 사용법을 익혀야한다는 단점이 있다.
• AspectJ 애너테이션 폼은 자바 5 애너테이션을 사용해 관점을 정의하여 새 도구와 새 언어라는 부담을 완화한다.

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

• 코드 수준에서 아키텍처 관심사를 분리할 수 있다면 테스트 주도 아키텍처 구축이 가능해지고, 확장이 용이해진다.
• 관심사가 분리된 아키텍처로 프로젝트를 진행해 결과물을 빨리 출시하고, 기반 구조를 추가하면 조금씩 확장해 나갈 수 있다.

의사 결정을 최적화하라

• 모듈을 나누고 관심사를 분리하면 지엽적인 관리와 결정이 가능해진다.

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

• 표준을 사용하면 아이디어와 컴포넌트를 재사용하기 쉽고, 적절한 경험을 가진 사람을 구하기 쉬우며, 좋은 아이디어를 캡슐화하기 쉽고, 컴포넌트를 엮기 쉽다.
• 하지만 표준을 만드는데 비용이 이득보다 크다면 만들지 마라.

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

• DSL(Domain Specific Language)는 간단한 스크립트 언어나 표준 언어로 구현한 API를 가리킨다.
• DSL로 작성한 코드는 가독성이 좋고, 도메인을 잘못 구현할 가능성이 줄어든다.

호텔 건축과정의 모습과 완공 이후 모습이 다른 것 처럼 소프트웨어 시스템 또한 제작시의 모습과 사용시의 모습은 달라야한다.

애플리케이션 객체를 제작하고 서로 의존성을 연결하는 제작 부분
그 이후 이어지는 런타임 로직인 사용 부분
두가지 부분을 분리해야한다.