Clean Code 9장 - 11장
9장 단위 테스트
p. 155 TDD 법칙 세 가지
여기서 실패하는 단위 테스트를 작성하라는 말은 ‘아 난 실패해야지!! 실패하는 테스트 짜자!’가 아니다.
실제코드를 작성하기 전에 테스트를 짜기 때문에 실패하는 것이다. 그러니까 테스트할 본 코드가 없기때문에 테스트가 실패하는 것이다. ‘실패하는 단위 테스트를 작성하라’는 말은 그냥 본 코드 짜기전에 테스트 부터 짜라는 말이다.
10장 클래스
p. 190 변경으로부터 격리
DIP는 SOLID(객체지향 설계 5원칙)에 포함되는 그것이다. DIP와 DI는 다르다. DIP를 구현하는 방법 중 하나가 DI이다.
DIP (의존관계 역전 원칙, Dependency Inversion Principle)
고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다. 저수준 모듈은 고수준 모듈에서 정의한 추상 타입에 의존해야 한다.
DI (의존성 주입, Dependency Injection)
189쪽에 있는 아래 코드가 그 예시이다. Portfolio에서 StockExchange라는 객체를 사용(의존)할 때, Portfolio에서 StockExchange 객체를 생성하는 것이 아니다.
그 외부(IoC 컨테이너)에서 StockExchange 객체를 생성하고, Portfolio에 주입을 하는 것이다.
public Portfolio {
private StockExchange exchange;
public Portfolio(StockExchange exchange) {
this.exchange = exchange;
}
// ...
}
11장 시스템
p. 202 횡단(cross-cutting) 관심사
‘횡단관심사’라는 단어자체가 바로 와 닿지 않아서 이미지를 찾아보았다. 여러가지의 모듈에서 반복적으로 나타나는 부분들이 있을 것인데, 그것이 바로 횡단관심이다.
p. 203 자바 프록시
여기서의 말하는 프록시는 그 디자인 패턴의 프록시, VPN의 프록시와 비슷하다. 여기서의 맥락은 ‘Spring AOP를 구현하는 것에는 크게 3가지가 있고, 그 세 가지 모두 프록시 기반이다.’인 것 같으니 그에 맞춰서 설명하자면 아래와 같을 것 이다.
스프링은 Aspect 대상이 되는 객체(Target)에 대한 프록시를 만들어준다. 클라이언트는 객체에 바로 접근 하는 것이 아니라, 프록시를 ‘통해서’ Target에 접근하게 한다.
그러므로 여기서의 프록시는 Target을 감싸는 Wrapping Object이며, 그 때문에 코드의 양과 크기가 늘어나게 되는 것이다.
p. 199 확장 - p. 209 순수 자바 AOP 프레임워크
EJB1, EJB2를 써보지 않아서 ‘음 그렇구나..’하고 넘어갔다. AOP가 무엇이고 왜 등장했는지?가 주된 내용인듯해서 정리를 해 보았다.
과거의 프로그램과 현재의 프로그램이 어떤지 생각을 해 보자. 과거에는 computer라는 이름에 걸맞게 주로 ‘계산’하는 용도였다. 복잡한 수식을 연산한다던가, 이동거리를 계산한다거나..
이 때 만들었던 프로그램들은 규모가 작았고 주로 위에서 아래로, 단방향으로 흐르는 절차지향 프로그래밍의 형태를 띄고있다.
시간이 지나면서 프로그램의 규모는 점차 커지게 되었고, 절차지향 방식은 큰 프로그램을 만들고 유지보수하기가 힘들게 되었다. 이 때 객체지향 프로그래밍(OOP)이라는 패러다임이 뜨게 되었다.
단순히 순차적으로 흐르는 명령어의 목록이 아닌, 여러개의 독립적인 단위인 ‘객체’의 모임과 상호작용으로 보는 시각이다.
이 ‘객체’라는 개념으로 모듈화를 하고 이를 통해 어느정도 중복이 줄었다. 또한 과거 절차지향으로 만들어진 코드에 비해 더 유연하고 직관적인 개발 역시 가능해졌다.
하지만 이 OOP를 통해 모듈화를 한다고 한들, 프로그램의 크기가 아주 커지면서 여러가지의 모듈 사이에서도 중복이 생기게 되었다.
예를 들어서 Board내에 있는 로깅하는 기능, User내에 있는 로깅하는 기능, ㅇㅇ내에 있는 로깅하는 기능 … 이것이 횡단관심사이다.
이런 횡단관심사는 모듈화를 저해하는 요인이 된다. AOP의 목적은 이러한 횡단 관심사들을 모듈화 하는 방법을 제시해 주는 것이다.