강한 결합을 직접 느껴보는 차시 — 읽기 자료
class OrderService {
private MailSender mail = new GmailSender();
void order() {
// ... 주문 처리
mail.send("주문 완료");
}
}
아무 문제 없어 보입니다. 이렇게 짜는 게 자연스럽죠. 그런데 — 한 줄짜리 요구사항이 들어옵니다.
"이메일이 자꾸 스팸으로 빠집니다. 카카오톡 알림으로 바꿔주세요."
한 클래스의 한 줄을 바꾸면 끝일 것 같지만, 실제로는:
OrderService 의 new GmailSender() → new KakaoSender() 로 변경KakaoSender 의 메서드 이름이 send() 가 아니고 notify()?OrderService 안에서 호출 코드도 수정CartService, UserService) 에도 있다면? 모두 수정한 줄 요청이 코드베이스 여러 군데를 부수는 사건이 됩니다.
클래스 안에서 new ConcreteClass() 로 직접 객체를 생성하면, 그 클래스는 해당 구체 클래스에 꽉 묶여 있게 됩니다. 인터페이스가 아니라 실체에 의존하는 상태입니다.
강한 결합은 부품을 갈아끼울 수 없는 일체형 가전과 같습니다. 메인보드 하나만 고장나도 통째로 버려야 하죠. 반면 모듈식 PC 는 부품 하나만 교체하면 됩니다.
다음 두 차시에서 다룰 IoC (제어 역전) 와 DI (의존성 주입) 는, 클래스 안에서 직접 new 하지 않고 외부에서 객체를 받아쓰는 방식을 도입합니다. 이 방식이 「부품 교체」를 코드 수정 없이 가능하게 만듭니다.
객체가 어떻게 만들어지는지 안다 — new 가 자연스럽다고 느낌.
new 의 함정을 손으로 느꼈다. 부품 교체가 왜 어려운지 안다. 다음 도구의 동기가 분명해진다.