Object[4]

설계 품질과 트레이드오프

• 역할은 책임의 집합이기 때문에(나는 해당역할에 여러 객체들이 교체될 수 있어 각 객체들의 추상화가 책임인줄알았는데..?)
• 설계는 변경을 위해 존재하고 변경에는 어떤 식으로든 비용이 발생한다. 훌륭한 설계는 합리적인 비용안에서 변경을 수용할 수 있는 구조를 만드는 것이다.
• 객체의 상태가 아닌 행동에 초점을 맞춰라?
• 데이터 중심의 관점에서 객체는 자신이 포함하고 있는 데이터를 조작하는데 필요한 오퍼레이션을 정의한다.
• 책임 중심의 관점에서 객체는 다른 객체가 요청할 수 있는 오퍼레이션을 위해 필요한 상태를 보관한다.

캡슐화

• 상태와 행동을 하나의 객체 안에 모으는 이유는 객체의 내부 구현을 외부로부터 감추기 위해서다.
• 여기서 구현이란 나중에 변경될 가능성이 높은 어떤 것을 가리킨다.
• 객체를 사용하면 변경 가능성이 높은 부분은 내부에 숨기고 외부에는 상대적으로 안정적인 부분만 공개함으로써 변경의 여파를 통제할 수 있다. 상대적으로 안정적인 부분을 인터페이스라고 부른다.
• 가장 기본적인 아이디어는 변경의 정도에 따라 구현과 인터페이스를 분리하고 외부에서는 인터페이스에만 의존하도록 관계를 조절하는 것이다.

응집도

• 응집도는 모듈에 포함된 내부 요소돌이 연관돼 있는 정도
• 모듈 내의 요소들이 하나의 목적을 위해 긴밀하게 협력한다면 그 모듈으 높은 응집도를 가진다.
• 응집도가 높을수록 변경의 대상과 범위가 명확해진다.

결합도

• 의존성의 정도
• 다른 모듈에 대해 얼마나 많은 지식을 갖고 있는지를 나타내는 척도(우리는 file 객체가 아닌 객체에서 s3 bucket의 정보를 알고있다!)
• 한 모듈이 변경되기 위해서 다른 모듈의 변경을 요구하는 정도(만약에 다른 객체가 변경되는 객체에 property를 참조하고 해당 속성이 변경되거나 삭제됬다면 그 속성을 참고하는 모든 객체는 수정이 필요해진다.!!!가아닐까?!)

 

• getter, setter는 private을 public로 바꾸는 효과를 가진다. 사용자에게 property가 뭔지 method를 통해 알려주고 있는 때문에 사용자는 객체에 property를 알아야되므로 결합도가 올라가게 된다.
• 어떤 코드를 수정한 후에 아무런 상관도 없던 코드에 문제가 발생하는 것은 모듈의 응집도가 낮을 때 발생하는 대표적인 증상이다.(우리 코드에 하나 바꾸면 어디선가 터지는 코드가 너무 많다.. 글로벌 서치가 꼭 필요!)
• 단일 책임 원칙은 클래스는 단 한가지의 변경 이유만 가져야 한다는 것이다.(다른 책임 변경으로 인해 해당 객체가 변경된다면 응집도가 낮은거라고 볼 수 있을 것 같다.)->여기서의 책임은 협력 역할 책임과는 다른 의미인 변경과 관련된 개념이다.
•