구현
1. Implementation with Java Swing : Rich Client UI
2. Implementation with Java Struts : Client Browser and WebUI
Low Coupling Pattern
- 문제점: 어떻게 변화에 의한 영향을 줄일 것인가?
- 해결책
- 책임 할당을 통해서 커플링은 낮게 유지함
- 대안을 선택해야 할 때 사용함
- 예) 누가 Payment 인스턴스를 생성하고 이를 Sale에 연관시키는가?
1.Register
- Sale
low Coupling을 고려해서 선택
Register가 Sale에게 위임하는 것이 coupling을 낮출 수 있기 때문에 더 Sale이 Payment를 생성하도록 만드는 것이 좋음
low coupling은 모든 의사 결정을 평가하는 동안 적용해야 하는 평가 원칙
결합
- A가 B를 사용하면 결합이 됨
- Low coupling을 유지하려면 추가적인 결합을 피할 것
- 주의
- java.util은 거의 모든 객체와 결합도를 가짐 ( -> 매우 큰 결합도)
- 불안정한 요소와의 결합도가 문제가 됨
- 장점
- 다른 컴포넌트로부터 영향을 받지 않음
- 독립적으로 이해하기 쉬움
- 재활용이 용이
- 관련된 패턴 또는 원칙
- Protected Validation: 변화 발생 가능성이 클 때 만약 변화가 발생하면 이에 영향을 받아 바뀌지 않도록 미리 대비하는 방법
High Cohesion 패턴
- 문제점: 어떻게 객체들을 집중되도록, 이해하기 쉽게, 관리하게 쉽게 유지하고 그리고 부작용으로 낮은 coupling을 지원하도록 하는가?
- 해결책
- 책임 할당을 통해 Cohesion을 높게 유지함
- 여러 대안이 존재할 때 이 중에서 선택해야하는 경우에 사용
- 예) 어떤 클래스에게 Payment 인스턴스 생성과 Sale과의 연관에 대한 책임을 할당해야 하는가?
- Register
Register은 UI로부터 이벤트를 받기만 하면 됨
- Sale
Register는 컨트롤러와 도메인 계층 역할을 모두 수행해야 함
sale-payment: 도메인 로직
- Register은 시스템 연산에 대한 책임을 수행함
- Paymet까지 수행하게 되면 팽창된 컨트롤러가 됨
-> Sale이 Payment를 생성해야 응집도가 높아짐
- 응집도 수준
- 매우 낮은 응집도: 다른 기능 영역의 대규모 작업을 수행
- 낮은 응집도: 하나의 기능 영역의 일을 수행하나 메서드의 수가 많음
- 높은 응집도: 하나의 기능 영역에서 적당한 책임을 수행하며 협력함
- 유사한 사례: 모듈화 설계
Low Coupling <-> High Cohesion- 장점
- 명확한 설계
- 유지보수 편함
- 낮은 결합도 지원
- 재사용성 증가
정리
if (생성에 대한 문제)
Creator Pattern 적용;
else if (UI의 이벤트 처리)
Controller Pattern 적용;
else
Informaion Expert 적용; //가장 일반적
if (여러 후보 존재하는 경우)
low coupling & high cohesion을 따라서 하나를 선택함;
``