디미터의 법칙

공부한 것

• 디미터의 법칙 (Law of Demeter)

고민한 점 및 생각해본 점

• 디미터의 법칙은 최소 지식의 원칙(Principle of least knowledge)이라고도 불리며, 소프트웨어 개발 특히 객체 지향 프로그래밍을 할 때의 디자인 가이드라인이다.
• 유닛 사이의 약한 결합을 유지할 것을 전제로 한다.
• 약한 결합도를 유지하기 위해, 모든 객체는 하술한 메서드만 사용해야 한다.
  1. 객체 자신의 메서드
  2. 메서드의 매개변수로 넘어온 인자의 메서드
  3. 메서드 내부에서 생성된 객체의 메서드
  4. 메서드가 포함하고 있는 객체의 메서드
• 쉽게 말하면, 객체 a가 객체 b를 가지고 있을 경우 b 안에 있는 메서드라던지, 활용할 수 있다. 하지만 다른 객체로 넘어가기 위해 b를 징검다리 삼아서는 안 된다.
• Swift상에서는, 객체 내부의 메서드나 프로퍼티를 불러오기 위한 .이 지나치게 많을 경우, 디미터의 법칙을 위반한 것은 아닌지 의심해볼 필요가 있다.
• 예를 들자면...

human.brain.isEmpty() 
human.isFool() // 디미터의 법칙을 따를 때 더 적합한 코드

• 물론 그렇다고 .을 하나만 써야 된다는 말은 아니다! 코드를 짜는 과정에서 판단할 수 있을 것.
• 디미터의 법칙을 준수했을 때의 장점은, 코드의 재사용성이 좋아지고 유지보수가 용이해진다는 점이다.
• 물론 단점도 있다. 디미터의 법칙을 준수하고자 한다면, 필요한 값을 사용하기 위해 통칭 Wrapping Method라는 것이 필요해질 수 있다. 이 사용이 너무 많아지면, 유의미한 시간 및 공간적 낭비를 초래할 수 있다.
• 이전 프로젝트에서 코드를 짤 때, 필요한 값을 가져오기 위해 너무 깊이 들어간 적이 있었다. 확실히 좀 지저분했다..

참조

https://en.wikipedia.org/wiki/Law_of_Demeter