출처 : 객체지향의 사실과 오해 조영호 저 | 위키북스
자율적인 책임
설계의 품질을 좌우하는 책임
- 적절한 책임을 적절한 객체에게 할당하는 과정에서 적절한 책임이 자율적인 객체를 만든다.
- 자율적인 객체들이 모여 유연하고 단순한 협력을 만듬
자율적인 객체
- 자율적인 객체 : 스스로 정한 원칙에 따라 판단하고 스스로의 의지를 기반으로 행동하는 객체
- 자율적인 객체가 되기 위해선 할당되는 책임이 자율적이어야 함 -> 왕은 모자장수에게 '글로 요약하라', '시간 순서대로 말하라' 처럼 상세한 요청이 아닌 '증언하라'라는 자율성이 충분히 보장된 책임을 할당
- 왕의 입장에서 모자 장수가 어떤 방법으로 증언하는 지는 전혀 중요 X
- how가 아닌 what을 생각 -> '시간 순서대로 말하라' 처럼 '어떻게'가 아닌 '증언하라' 처럼 '무엇'을 해야 하는 지 결정하도록
너무 추상적인 책임
- 협력의 의도를 명확하게 표현하지 못할 정도의 추상적인 책임은 오히려 문제
- '증언하라'가 아닌 그냥 '설명하라' 였다면? 뭘 설명해야 하지..?
- '증언하라'라는 책임은 자율성을 보장할 수 있을 정도로 충분히 추상적 + 협력의 의도 뚜렷
메시지와 메서드
메시지
- 객체와 객체 사이 유일한 의사소통 방법
- 메시지 이름 : '증언하라'
- 인자를 통해 추가 정보 제공 가능 : 증언하라(어제, 왕국)
- 수신자 정보 명시 : 모자장수.증언하라(어제, 왕국)
메시지를 수신받은 객체는 먼저 해당 메시지를 처리할 수 있는지 판단한다. 처리할 수 있다는 것은 그 객체가 해당 메시지에 해당하는 행동을 수행해야 할 책임이 있다는 뜻이다. 따라서 메시지의 개념은 책임의 개념과 연결된다.
- 객체의 외부와 내부가 메시지를 기준으로 분리 -> 모자장수가 수행하는 방법을 변경해도 왕은 알 수 없음.
- 메시지를 처리하는 방법은 외부의 다른 객체가 볼 수 없는 객체 자신의 사적인 영역
메서드
- 메시지를 처리하기 위해 내부적으로 선택하는 방법
- 처리할 수 있는 메시지가 오면 책임을 다하기 위해 처리할 방법인 메서드 선택
- 어던 메서드를 선택할 것인지는 전적으로 수신자의 결정
- 객체가 실행 시간에 메서드를 선택할 수 있다는 것은 객체 지향 언어만의 특징
다형성
- 서로 다른 유형의 객체가 동일한 메시지에 대해 다르게 반응하는 것
- 서로 다른 타입에 속하는 객체들이 동일한 메시지를 요청받았을 경우 서로 다른 메서드를 이용해 메시지를 처리할 수 있는 힘
- 하나의 메시지와 하나 이상의 메서드 사이의 관계 -> '전송하라'라는 메시지 - 엘리스, 모자장수 증인들의 자율적인 메서드
- 서로 다른 객체들이 다형성을 만족? 객체들이 동일한 책임을 공유한다는 것
- 왕의 입장에선 그저 다 증인일 뿐.. 그들은 모두 증인 역할 수행 가능
- 다형성 = 동일한 역할을 수행할 수 있는 객체들 사이의 대체 가능성 -> 앨리스와 모자장수는 서로 대체 가능
- 다형성을 사용하면 수신자의 종류를 몰라서 메시지 전송 가능 -> 왕은 메시지를 요청하지만 누가 수신할 지는 알 필요 X, 그저 증인 역할이기만 하면 OK
- 다형성을 사용하면 메시지를 이해할 수 있는 어떤 객체와도 협력할 수 있는 유연한 구조가 가능
유연하고 확장 가능하고 재사용성이 높은 협력의 의미
- 협력이 유연해진다.
- 메시지를 처리만 해준다면 수신자가 누구든 상관 X
- 유연하게 변경 가능
- 협력이 수행되는 방식 확장 가능
- 대체 가능한 수신자로 수행 방식 쉽게 수정 가능
- 협력이 동작하는 방식은 바뀌지만 재판이라는 협력의 구조 자체는 변화 X
- 협력이 수행되는 방식 재사용 가능
- 미래의 누군가가 재판이라는 협력을 할 때 재사용 가능
송신자와 수신자를 약하게 연결하는 메시지
- 메시지가 결합도를 낮춰서 유연하고 확장 가능하고 재사용 가능하도록 함
메시지를 따라라
객체지향의 핵심, 메시지
- 클래스 기반의 객체 지향 언어를 사용하다 보면 객체지향 애플리케이션을 클래스의 집합으로 오해
- 클래스가 코드를 구현하기 위해 사용할 수 있는 추상화 도구인 것은 맞으나 객체지향의 강력함은 메시지로부터
- 클래스를 정의하는 것이 먼저가 아닌 객체들의 속성과 행위를 식별하는 것이 먼저
- 개별 객체가 아닌 객체 사이의 메시지에 초점
- 객체가 메시지를 선택하는 것이 아닌 메시지가 객체를 선택하도록
책임-주도 설계
- 적절한 책임을 적절한 객체에게 할당하면서 메시지를 기반으로 협력하는 객체들의 관계를 만드는 과정
- 객체가 책임을 완수하기 위해 다른 객체의 도움이 필요하면 필요한 메시지를 결정 후 적합한 객체를 선택
What/Who 사이클
- 어떤 행위(What)가 필요한지 먼저 결정 후 이 행위를 수행할 객체(Who)를 결정하는 과정
- 메시지를 먼저 결정하고 객체를 선택하는 것
- 메시지 중심의 설계는 메시지 수신자의 캡슐화 증진 효과 -> 느슨한 결합 + 자유로운 객체
- 수신 가능한 메시지가 모여 객체의 인터페이스를 구성
객체 인터페이스
인터페이스 : 어떤 두 사물이 마주치는 경계 지점에서 서로 상호작용할 수 있게 이어주는 장치
- 인터페이스의 사용법을 익히면 내부 구조나 동작 방식을 몰라도 쉽게 조작 가능
- 인터페이스 자체는 변경하지 않고 내부 구성이나 작동 방식만 변경하는 것은 클라이언트에게 영향 X
- 대상이 변경되더라도 동일한 인터페이스만 제공하면 아무 문제 X
메시지가 인터페이스를 결정한다
- 객체들 간의 유일한 상호작용 방법은 메시지 전송뿐이기 때문에 객체의 인터페이스는 객체가 수신할 수 있는 메시지의 목록으로 구성됨
공용 인터페이스
- 외부에서 접근 가능한 공용 인터페이스 vs 내부에서만 접근 가능한 사적인 인터페이스
- 공용이건 사적이건 모든 인터페이스는 메시지 전송을 통해서만 접근
- 단지 메시지 송신자가 다른 객체인지 자신인지만 다를 뿐
- 객체의 공용 인터페이스를 구성하는 것은 객체가 외부로부터 수신할 수 있는 메시지의 목록 -> 왕과 모자 장수 사이에는 '증언하라'라는 메시지를 전송/수신할 수 잇는 인터페이스 존재
인터페이스와 구현의 분리
객체 관점에서 생각하기
- 좀 더 추상적인 인터페이스
- 최소 인터페이스 : 외부에서 사용할 필요가 없는 인터페이스는 최대한 노출 X
- 인터페이스와 구현 간에 차이가 있다는 점 인식
구현?
- 객체지향에서 내부 구조와 작동방식을 가리키는 구현
- 객체를 구성하지만 공용 인터페이스에 포함되지 않는 모든 것 -> 상태를 어떻게 표현할 것인지, 메서드 등
인터페이스와 구현의 분리 원칙
- 훌륭한 객체는 구현을 모른 채 인터페이스만 알면 상호작용이 가능한 객체
- 객체를 설계할 때 객체 외부에 노출되는 인터페이스와 객체의 내부의 구현을 명확하게 분리
- 객체의 상태와 메서드는 객체 내부로 이 부분을 수정하더라도 객체 외부에 영향이 없어야 한다.
- 외부에 영향을 미치는 변경은 공용 인터페이스를 수정하는 경우 뿐
캡슐화
- 객체의 자율성을 위해 구현을 외부로부터 감추는 것
- 상태와 행위의 캡슐화 : 데이터 캡슐화
- 사적인 비밀의 캡슐화 : 구현과 관련된 세부 사항
- 구현을 변경할 때 외부에 대한 영향을 최소화하기 위해 외부의 객체는 구현이 아닌 공용 인터페이스에만 의존해야 한다.
- 어떤 것도 동시에 객체의 내부와 외부에 포함될 수는 없다. 명확하게 구분할것!
책임의 자율성이 협력의 품질을 결정한다
- 자율적인 책임은 협력은 단순하게 만든다!
- 증언만 하면 되니까 '증언하라'라는 하나의 문장으로 표현함으로써 협력을 단순하게 만듦
- 자율적인 책임은 모자 장수의 외부와 내부를 명확하게 분리
- 모자장수는 증언할 방법을 자율적으로 선택
- 캡슐화로 인한 인터페이스와 구현의 분리
- 책임지 자율적이면 내부적인 방법을 변경해도 외부에 영향 X
- 시간순으로 증언하다가 글로 증언하는 방법으로 바꿔도 영향 X
- 자율적인 책임은 유연성을 제공
- 모자 장수가 아닌 어떤 사람이 해도 상관 X
- 자율적일수록 역할을 이해하기 쉽다
- 증언하라 라는 책임만으로 증인이라는 역할이 명확해짐
'JAVA > 객체지향의 사실과 오해' 카테고리의 다른 글
객체 지향의 사실과 오해 - 역할, 책임, 협력 (0) | 2022.02.13 |
---|---|
객체 지향의 사실과 오해 - 타입과 추상화 (0) | 2022.02.11 |
객체 지향의 사실과 오해 - 이상한 나라의 객체 (0) | 2022.02.11 |
객체 지향의 사실과 오해 - 협력하는 객체들의 공동체 (0) | 2022.02.06 |