Object[5]

책임 할당하기

• 객체에 책임을 할당하는 기본적인 원리
• 데이터보다 행동을 먼저 결정해라(인터페이스를 먼저 작성하라고 생각됨: 뒤에서 잘못됬다고 느낌 인터페이스를 쓰라는게 아니라 메세지를 먼저 작성해라라고 본다) -> 객체에게 중요한것은 데이터가 아니라 외부에 제공하는 행동이다. 클라이언트 관점에서 객체가 수행하는 행동이란 곧 객체의 책임을 의미한다.
• 협력이라는 문맥 안에서 책임을 결정해라
• 메시지를 전송하는 클라이언트 의도에 적합한 책임을 할당해야 한다.(메서드 써놓고 이건 누가 가져가야하지? 즉 문맥을 먼저 작성하고 각책임을 할당해줘라라고 이해된다.)
• 메세지가 객체를 선택하게 해야 한다.("메세지를 전송해야 하는데 누구에게 전송하지?")
• 데이터 중심으로 작성하게 되면 캡슐화를 신경쓰면서 해야됨 누굴 인터페이스로 누굴 구현으로 나누어 주어야하니까 근데 메시지기반으로 하게되면 자연스럽게 캡슐화가 이루어진다고 보여짐

 

GRASP 패턴

• general reponsibility assignment software pattern
• 도메인 개념을 정리하는 데 너무 많은 시간을 들이지 말고 빠르게 설계와 구현을 진행하라.
• 영화를 예매해 메시지의 책임을 수행해라
• 클라이언트(메시지를 전송할 객체는)무엇을 원하는가?
• 서버?(메시지를 수신할 객체는 누구인가?)
• 첫번째 원칙 : 책임을 수행할 정보를 알고 있는 객체에게 책임을 할당하는 것이다.(information expert 정보전문가)패턴
• 책임을 수행하는 객체가 정보를 알고있다고해서 그 정보를 저장할 필요는 없다 그 정보를 알고있는 다른객체나 계산해서 제공할수도있다.
• low coupling pattern, high cohesion pattern 순서
• screening이 MOVIE에 어떤 정보도 모른체 메시지를 생성할수있다.
• 응집도가 높은 인스턴스는 인스턴스가 생성될때 모든 속성을 함께 초기화한다.
• 변경의 이유가 하나 이상인 클래스를 찾아보자
• 다형성 패턴(프로그램을 if else, switch등의 조건 논리를 사용해서 설계한다면 새로운 변화가 일어난 경우 조건 논리를 수정해야 한다. 이것은 프로그램을 수정하기 어렵고 변경에 취약하게 만든다.)
• 구현을 공유해야 할 필요가 있다면 추상 클래스, 구현을 공유할 필요 없이 역할을 대체하는 객체들의 책임(메시지?)만 정의하고 싶다면 인터페이스를 사용하면 된다.
• 변경이 될 가능성이 높은가? 그럼 캡슐화하라 .... ㅠ