[Chapter 22] 급여 관리 사례 연구(2부)

급여 관리 사례 연구(2부) Key Point 🔑

• 패키지 다이어그램은 의존 관계가 아래쪽으로 향하도록 그린다 → 관례적 표현
• 항상 동일한 변화에 동일하게 폐쇄되어 있는지 패키지 점검 (CCP)
• 거의 아무도 A패키지에 의존하지 않는다! → A는 책임이 없는 패키지!
• A패키지는 어떤 것도 의존하지 않는다! → A는 독립적인 패키지!
• 애플리케이션이 얼마나 안정적인지, 자주 바뀌는지, 재사용할 클라이언트는 어느정도인지에 원칙의 적용 정도가 달라진다! 자주 바뀌지도 않고 재사용할 클라이언트도 거의 없으며, 매우 안정적이라면 원칙을 철저하게 적용하여 의존 관계 아키텍쳐가 복잡해지게 되는 것이 더 손해일 수 있다!
• 처음에는 간단히 시작하고 필요에 따라 패키지 구조를 발전시키는 것이 best
• 해당 패키지로 들어오는 결합을 막기 위해 private같은 접근 제어자를 사용 가능하다 → 다른 패키지에서 알 필요 없는 클래스들을 숨기는 목표
• 세부 구현이 담긴 클래스를 자유롭게 고치고 싶다면, 다른 누구도 그 클래스에 의존하지 못하도록 만들어야한다
• 책에서 나오는 측정법
  • 관계 응집도
  • 들어오는 결합
  • 나가는 결합
  • 추상도
  • 불안정도
  • 주계열로부터의 거리
  • 정규화된 주계열로부터의 거리
• 이런 측정값을 자동으로 계산해주는 도구도 존재!
• 이런 측정값을 프로젝트에 적용하며 상대적으로 주계열로부터 멀거나 응집도가 낮은 패키지들을 수정할 수 있게 된다 → 더욱 패키지 응집도와 결합도를 신경 쓴 구조가 된다!
• 패키지 다이어그램이 엉켜있으면 관리가 매우 힘들다 → 계속 실용적으로 사용할 수 있도록 간단하게 유지하자
• 추상 패키지들은 변경에 폐쇄되어 있고, 재사용 가능하고, 자신들은 별로 많이 의존하지 않도록! 그리고 많은 의존의 대상이 되도록! → (안정적 패키지)
• 구체적 패키지들은 재사용성에 바탕을 두고 분리한다. 일반적으로 추상 패키지들에게 매우 의존하는 형태이다. 그렇기에 심한 의존의 대상이 되어서는 안된다! → (불안정적 패키지)