개발하면서 이런 코드 한 번쯤은 보신 적 있지 않나요?
String city = order.getCustomer().getAddress().getCity();
처음 봤을 땐 별문제 없어 보이지만, 나중에 유지보수하다 보면 이런 생각이 들기 시작합니다.
“어디서부터 잘못됐지?”
“이거 nullPointer 나면 어디가 문제인 거지?”
“이거 구조 바뀌면 코드 전부 뜯어고쳐야 하잖아…”
이런 문제를 막기 위해 나온 개념이 바로 디미터의 법칙(Law of Demeter)입니다.
🧠 디미터의 법칙이란?
"너와 가까운 친구와만 이야기해라!"
객체는 자신이 직접 알고 있는 객체와만 상호작용해야 한다는 원칙입니다.
쉽게 말하면, 체인처럼 객체를 줄줄이 이어서 호출하지 말라는 이야기 !
// ❌ 디미터의 법칙을 어긴 코드
order.getCustomer().getAddress().getCity();
// ✅ 디미터의 법칙을 지킨 코드
order.getShippingCity(); // 내부에서 customer와 address를 캡슐화
🙋♀️ 왜 중요한가요? (특히 주니어 개발자에게)
- 결합도 감소 - "인생은 짧고, 유지보수는 길다"
디미터의 법칙을 준수하면 객체 간의 결합도가 크게 감소합니다. 각 객체는 자신의 직접적인 "친구"와만 상호작용하기 때문에, 특정 객체의 내부 구조가 변경되어도 영향을 받는 코드가 최소화 된다. - 코드 유지보수성 향상 - "미래의 나에게 선물하기"
결합도가 낮아지면 자연스럽게 코드의 유지보수성이 향상됩니다. 프로젝트가 커질수록 이 이점은 더욱 분명해진다. - 객체의 책임이 명확 !
어떤 데이터든 가져오기 쉽게 만들기보다, 해당 객체가 "해야 할 일"만 하게 만든다. - 캡슐화 강화 - "누구나 알아야 할 것만 알게 하라"
객체의 내부 구조를 외부에 노출하지 않음으로써 캡슐화가 강화된다. 이는 객체 지향 설계의 중요한 원칙 중 하나이다. - null 관련 버그를 줄일 수 있다
중간 단계 객체가 null이면 바로 NullPointerException 터지는데, 디미터의 법칙을 지키면 그 가능성이 줄어든다. - 테스트 용이성 - "테스트하기 쉬운 코드가 좋은 코드"
디미터의 법칙을 따르는 코드는 일반적으로 테스트하기 쉽습니다. 객체 간의 상호작용이 단순하고 직접적이기 때문에, 단위 테스트 작성이 더 쉬워진다.
🛠 실무에서 어떻게 적용할까?
실제 실무에서는 다음과 같이 습관을 들이면 좋습니다.
1. '기차 충돌(Train Wreck)' 패턴 피하기 - 객체 내부 정보를 밖에서 너무 꺼내 쓰지 말자
// ❌ 고객 주소의 도로명을 꺼내 쓰는 경우
String street = order.getCustomer().getAddress().getStreet();대신 이렇게 작성한다.
// ✅ 필요한 정보는 메서드로 감싸서 제공
String street = order.getCustomerStreet();
2. Tell, Don't Ask' 원칙 기억하기 - getter 남용하지 말자
객체지향에서는 "데이터를 꺼내서 처리하는 것"보다는 "객체에 시키는 것"이 더 좋습니다.
// ❌ get 해서 내가 처리
if (order.getStatus().equals("COMPLETED")) { ... }
// ✅ 객체에 메시지 보내서 처리
if (order.isCompleted()) { ... }
💡 좋은 개발 습관이 되는 이유
디미터의 법칙은 단순히 "룰"이 아니라, 코드의 복잡도를 낮추고, 응집도를 높이며, 변경에 강한 코드를 만들 수 있게 해줍니다.
특히 주니어 시절부터 이런 습관을 들여놓으면, 나중에 구조 설계나 리팩터링에서 훨씬 유리합니다.