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
의 목적은 이러한 횡단 관심사들을 모듈화 하는 방법
을 제시해 주는 것이다.