Topic 28 결합도 줄이기
데이비드 토머스, 앤드류 헌트
느낌표 ! (인상 깊은 문장 | 문맥)
높은 결합도는 변경의 적이다. 결합도가 높으면 이리저리 연결되어 있어서 여러 가지를 동시에 바꿔야 하기 때문이다. 그래서 바꾸기 더 어려워진다. 여러분의 운명은 둘 중 하나다. 바꿔야하는 곳을 모두 찾아내느라 시간을 들이거나, 아니면 ‘딱 하나만’ 바꾸고 결합된 다른 것들은 잊은 채 왜 프로그램이 죽는지 고민하느라 시간을 들이거나.
p.182
책에서는 강의 다리(대교)를 언급하면서 현실 세계에서는 결합도가 높을수록 견고하지만 소프트웨어 세계에서는 변경이 빈번하기 때문에 느슨하게 연결해야한다고 설명하고 있다. 개발을 하다보면 특정 함수를 수정할 때 크고 작은 수정을 해야한다. 규모가 클수록 자신감은 저하되고 버그가 발생할 확률도 높아진다. 물론 테스트 케이스가 잘 되어있다면 낫겠지만 테스트 케이스가 버그 없다는 것을 증명해주지는 않기 때문에 느슨한 코드를 짜는 것이 근원적으로 더욱 중요하다.
결합도가 낮은 코드가 바꾸기 쉽다.
p.184
묻지 말고 말하라 (Tell, Don’t ask, TDA)
이 원칙은 다른 객체의 내부 상태에 따라 판단을 내리고 그 객체를 갱신해서는 안 된다는 것이다.
p.186
묻지 말고 말하라는 캡슐화의 장점을 살려야한다는 것이다.
묻는 코드
customer
.orders
.find(order_id)
.getTotals()
.applyDiscount(discount)
묻지 않는 코드
customer
.findOrder(order_id)
.applyDiscount(discount)
전역 데이터를 쓰는 코드에 단위 테스트를 만들다 보면 이런 문제를 발견하게 된다. 그저 테스트를 실행하려는 것뿐인데 전역 환경을 생성하는 코드를 한참이나 써야 한다.
p.190
전역 변수는 불가불 사용해야한다. 그렇지만 전역 변수가 주는 단점도 명확하다. 그 중 하나로 테스트 케이스 작성의 복잡성이 있다. 전역 변수를 테스트하는 코드와 전역 변수와 얽혀있는 기능을 테스트를 해야하기 때문이다. 저자는 전역 변수를 최대한 사용하지 않기를 권장하며 사용해야한다면 최소한 한 번 랩핑하기를 권장하고 있다.
Topic 28 느낌
Topic 28 에서는 간단하게 결합도를 낮추는 방법에 대해 알아보았다.