3 주차
토, 일 | Assignment #17
11장. 시스템
📘 책에서 기억하고 싶은 내용
- "복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제적하고 테스트하기 어렵게 만든다." - 레이 오지
- 시스템 제작과 시스템 사용을 분리하라 (p.194)
- 소프트웨어 시스템은 준비 과정과 런타임 로직을 분리해야 한다.
- 설정 논리는 일반 실행 논리와 분리해야 모듈성이 높아진다.
- 초기화 지연 사용 시 문제점
- 해당 필드가
null인 경우와 null 이 아닌 경우 모두 테스트해보아야 함
SRP 위배 (단위 테스트 시 객체 할당 및 테스트 2가지 책임을 져야 함)
- Main 분리
- 시스템 생성과 관련된 코드는 모두
main이나 main이 호출하는 모듈로 옮기고, 나머지 시스템은 모든 객체가 생성되었고 의존성이 연결되었다고 가정
- 애플리케이션은
main이나 객체가 생성되는 과정을 전혀 모른다.
- 팩토리
- 애플리케이션이 객체가 생성되는 시점을 결정해야 할 때,
ABSTRACT FACTORY 패턴 사용
- 의존성 주입 (DI, Dependency Injection)
IoC 기법을 의존성 관리에 적용한 메커니즘- 객체는 의존성 자체를 인스턴스로 만드는 책임은 지지 않으며, 이런 책임을 메커니즘에 맡김으로써 제어를 역전
- DI 컨테이너는 필요한 객체의 인스턴스를 만든 후 생성자 인수나 설정자(
setter) 메서드를 사용해 의존성 설정
- 확장 (p.199)
- 단순한 아키텍처를 복잡한 아키텍처로 조금씩 키울 수는 없다.
- 영속성과 같은 관심사는 애플리케이션의 자연스러운 객체 경계를 넘나드는 경향이 있고, 모든 객체가 전반적으로 동일한 방식을 이용하게 만들어야 한다.
- 모듈화/캡슐화 방식으로 영속성 방식을 구상할 수 있으나 현실적으로는 영속성 방식을 구현한 코드가 온갖 객체로 흩어진다.
- EJB 아키텍처의 영속성, 보안, 트랜잭션을 처리하는 방식은 관심사를 거의 완벽하게 분리하여
AOP 를 예견한 것으로 보인다.
AOP : 횡단 관심사에 대처해 모듈성을 확보하는 일반적인 방법론
- 관심사는
자바 프록시, AOP, AspectJ 를 사용하여 관점으로 분리할 수 있다.
- 자바 프록시 (p.203)
- 개별 객체나 클래스에서 메소드 호출을 감싸는 등 단순한 상황에 적합
- JDK의 동적 프록시는
interface 만 지원하며, 클래스 프록시를 가용하려면 GGLIB, ASM, Javassist 등과 같은 바이트 코드 처리 라이브러리가 필요하다.
- 순수 자바 AOP 프레임워크 (p.205)
- 스프링 AOP 등 여러 자바 FW는 내부적으로 프록시 방식을 사용
- 스프링은 비즈니스 논리를
POJO 로 구현하고, POJO 는 순수하게 도메인에 초점을 맞춘다.
- AspectJ 관점 (p.209)
- AspectJ : 언어 차원에서 관점을 모듈화 구성으로 지원하는 자바 언어 확장, 관심사를 관점으로 분리하는 가장 강력한 도구지만 새 언어 문법과 사용법을 익혀야 한다는 단점 존재
- 테스트 주도 시스템 아키텍처 구축 (p.210)
- 코드 수준에서 아키텍처 관심사를 분리할 수 있다면, 진정한 테스트 주도 아키텍처 구축이 가능해지고, 그때그때 새로운 기술을 채택해 단순한 아키텍처를 복잡한 아키텍처로 키워갈 수 있다.
- 명백한 가치가 있을 때 표준을 현명하게 사용하라 (p.211)
- 표준을 사용하면 재사용 등 이점이 있지만 과도한 표준 사용은 복잡한 시스템을 초래할 수도 있다.
- 결론 (p.213)
- 깨끗하지 못한 아키텍처는 도메인 논리를 흐리며 기민성을 떨어뜨리고, 도메인 논리가 흐려지면 제품 품질이 떨어진다. 결국
TDD 가 제공하는 장점이 사라지게 된다.
- 시스템을 설계하든 개별 모듈을 설계하든, 실제로 돌아가는 가장 단순한 수단을 사용해야 한다.
🤔 소감 및 생각
- 페이지 첫 줄에서부터 터졌다 ㅋㅋㅋㅋㅋㅋ 저 인용구에 따르면 나는 죽음 속에서 업무를 지속적으로 해왔던 것이다.
Spring Framework 를 공부할 때 자주 접했던 개념이 이번 챕터에 나와서 반가웠다. 결국 모든 챕터가 다 하나의 사실을 각각 다르게 표현하고 있음을 느꼈다.
(p.s. 절반쯤 읽었는데 갑자기 velog 탭을 닫아버려서 글이 날아간 줄 알고 눈물 흘릴 뻔했다. 😭)
🔍 새롭게 또는 다시 알게 된 내용
- DECORATOR 패턴 : 주어진 상황 및 용도에 따라 어떤 객체에 책임을 덧붙이는 패턴으로, 기능 확장이 필요할 때 서브클래싱 대신 쓸 수 있는 유연한 대안이 될 수 있다.
- AspectJ : PARC에서 개발한 자바 프로그래밍 언어용 AOP 확장 기능
- BDUF(Big Design Up Front) : 구현을 시작하기 전에 앞으로 벌어질 모든 사항을 설계하는 기법
