클린 코드 독서일지 - Day 22

순수 자바 AOP 프레임워크

순수 자바 관점을 구현하는 여러 자바 프레임워크는 내부적으로 프록시를 사용

프로그래머가 설정 파일이나 API를 사용해 필수적인 애플리케이션 기반 구조를 구현하면, 프레임워크는 사용자 모르게 프록시나 바이트코드 라이브러리를 사용해 이를 구현함

=> 애플리케이션은 사실상 프록시 라이브러리와 독립적이게 되며, 복잡한 프록시 논리 없이 단순한 구현이 가능함
=> 코드가 깨끗해지고, 테스트하기 쉬워짐

AspectJ 관점

관심사를 관점으로 분리하는 가장 강력한 도구 : AspectJ 언어

AspectJ : 언어 차원에서 관점을 모듈화 구성으로 지원하는 자바 언어 확장.

풍부한 도구 집합을 제공하지만, 새 도구를 사용하고 새 언어 문법과 사용법을 익혀야 한다는 단점이 있음
=> 최근에 나온 AspectJ '애너테이션 폼’은 이를 어느 정도 완화.

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

코드 수준에서 아키텍처 관심사를 분리할 수 있다면, 테스트 주도 아키텍처 구축이 가능해지며 유연한 아키텍처 구조로 인해 점진적인 확장이 가능하다.

최선의 시스템 구조는 각기 POJO 객체로 구현되는 모듈화된 관심사 영역(도메인)으로 구성된다. 서로 다른 영역은 해당 영역 코드에 최소한의 영향을 미치는 관점이나 유사한 도구를 사용해 통합한다.

의사 결정을 최적화하라

모듈을 나누고 관심사를 분리하면 각 관심사에 치중한 관리와 결정이 가능해짐
=> 최대한 정보를 모아, 최선의 시점에 최적의 결정을 내리기가 쉬워진다.

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

표준을 사용하면 아이디어와 컴포넌트를 재사용하기 쉽고 사람을 구하기 쉬우며 아이디어의 캡슐화가 쉽고 컴포넌트 엮기가 쉽다는 장점이 있다.
그러나 표준을 만드는 시간이 너무 오래 걸려 업계가 기다리지 못할 수 있다는 단점이 있으며, 원래 표준을 제정한 목적을 잊어버리기도 한다.

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

DSL(Domain Specific Language) : 간단한 스크립트 언어나 표준 언어로 구현한 API.

좋은 DSL은 도메인 개념과 코드 사이의 의사소통 간극을 줄여주며, 추상화 수준을 코드 관용구나 디자인 패턴 이상으로 끌어올린다.

결론

시스템 역시 깨끗해야 한다.
모든 추상화 단계에서 의도는 명확히 표현해야 하며, 그러려면 POJO를 작성하고 관점을 사용해 각 구현 관심사를 분리해야 한다.

시스템을 설계하든 개별 모듈을 설계하든, 돌아가는 가장 단순한 수단을 사용하자.