DI 되는 객체는 대체 가능해야 한다

DI에 대해 이야기하다가, 의존성은 계산되어져야할 뿐만 아니라 변형(대체가능)되어야한다는 생각을 하게 되었다.

구체적인 클래스들이 약간씩 다르게, 변형이 되어지고 대체 가능해야 해당 클래스를 사용하는 클라이언트 클래스는 수명이 길것이다.

물론 저래야 테스트도 쉬워진다.

따라서 의존성이 생겨버린 객체는 대체 가능해야 하고 그래서 주입이 필요하다.

다만, ‘수명이 완전히 같아서’ 변형이 필요없다고 판단되면 주입하지 않고 완전히 가져도 될것이다.

건축 보다는 영화 제작

소프트웨어는 건축에 비유되곤 한다.
특이하게 그림에 비유되기도함

그림에 비교되는 이유는 art-예술과 비슷하다는 점에서. 혼자서 작업가능한 창작물이라는 점에서..

생각해보면 대규모 창작엔 영화가 있다. 영화제작에는 감독이 있고 촬영감독이 있고 여러 감독이 있으며, 시나리오 작가, 배우, 등등이 있다.

이런면에서 소프트웨어는 영화와 많은면이 비슷하다는 생각을 하게 되었다.

방어적 코드와 클린코드

외부에서 잘 전달된 코드에는 방어적인 null 체크가 없을것이다. AOP라는 측면에서 본연의 문제가 아닌 방어적 코드는 클린코드와는 거리가 멀다.

따라서 깔끔하게 validation 처리 하는 방식이 고려된다. (계약에 의한? )

고민해볼것 : null check / null 안던지기

cf.클린코드 측정이 WTF / line 이라는게.. 정말 공감간다. 클린코드는 나보다는 외부에 의해 평가되는 측면이 크다.