설계<=> 품질 트레이드오프
역할, 책임, 협력중 가장 중요한 것은 책임이다.
객체 지향 설계란, 올바른 객체에게 올바른 책임르 할당하면서 낮은 결합도와 높은 응집도를 가진 구조를 창조하는 활동이다
1. 책임이 핵심
2. 책임을 할당하는 작업이 결합도, 응집도 같은 품질과 깊이 연관돼어 있다.
합리적인 비용 안에서 변경이 가능한 좋은 설계
느슨하게 결합돼어있는 요소
객체의 상태가 아니라 객체의 행동에 초점을 맞추어야 한다
상태는 구현에 속한다. 구현은 불안정하기에 변하기 쉽다
객체의 책임은 인터페이스에 속한다.
응집도 : 내부 요소가 연관된 정도.
결합도 : 다른 모듈을 얼마나 아는 정도
오늘의 기능을 수행하고, 내일의 변경을 수용할 수 있는 정보
응집도 : 변경이 발생할 때 모듈 내부에서 발생하는 변경의 정보
하나의 변경을 수용하기 위해 모듈 전체가 함께 변경된다면 응집도가 높다.
결합도가 높아도 괜찮은 경우 : 일반적으로 변경될 확률이 매우 낮은 안정적인 모듈에 의존하는 것은 괜찮다
데이터 중심 설계 : 캡슐화 위반, 높은 결합도, 나은 응집도
캡슐화 위반
바깥에서 내부에 데이터를 그대로 꺼내올 수 있다.
이를 퍼블릭 인터페이스에 너무 잘 노출한다.
접근자와 수정자에 너무 의존하는 것을 추측에 의한 설계 전략 이다.
그래서 내부 구현이 숨겨지지 않는다
높은 결합도
하나가 바뀌면, 게터를 통해 가져온, 다른 클라이언트까지 영향을 받는다. 그래서 결합도 적으로 최악이다.
낮은 응집도
하나의 모듈을 수정하기 위해 의존한 다른 것까지 전부 수정 해야함
캡슐화를 지켜라. 정의된 메서드를 통해서만 상태에 접근할 수 있지만, 이게 단순히 수정자, 생성자는 아니고, 외부로 노출하는 것을 막아야 한다.
public boolean isDiscountable(int sequence){} 같은 경우를 보면, 순서라는게 있다는 것을 포함하고 있다는 것을 노출한다고 볼 수가 있다.
public MovieType getMovie(){}같은 것은 문제가 없지만
public Money calculateAmountDiscountedFee(){}
public Money calculatePercentDsicountedFee(){}
public Money calculateNoneDiscountedFee(){}
같은 것이 있다고 했을 때 생기는 문제는 3가지 할인 방법이 있다는 것을 만천하에 알리고 있다는 문제가 있다.
따라서 이를 제대로 캡슐화 하지 못한다
높은 결합도.
"구현"에 의존하는 것은 다른 부분이 변경되었을 때 같은 것으로 계속 영향을 받는다.
데이터에 대한 구현을 바깥으로 내보내는 경우가 나올 수밖에 없는데, 이 과정이 문제를 일으킨다
