전체는 부분의 합보다 크다
엄청 공감되는 내용은 아니다..
아리스토텔레스가 이야기하는 각각의 텔로스가
모두 비슷한 방향성이라는 전제가 필요할 것 같다
객체지향의 목적은 실세계를 추상화 하는 것이 아니라
새로운 세계를 창조하는 것이다
이 부분은 조금.. 어렵다
실세계에 있는 개념을 창조한다고 하면 맞는 말이라고 여겨질까 싶기도 하고
전혀 새로운 것을 창조한다고 할 수 있을까..
객체를 생명체에 비유하는 것은 상태와 행위를 캡슐화 하는 소프트웨어 객체의
자율성을 설명하는데 효과적이다
메시지를 주고 받으며 공동의 목표를 달성하기 위해 협력하는
객체들의 관계를 설명하는 데 적합하다
사물을 기반으로 소프트웨어 객체를 식별하고 구현하는 것은
객체지향 설계의 핵심 사상인 연결완전성을 설명하는데 적합하다
실무에서는 실세계의 모방이라는 객체지향의 개념은 부적합하다
위와 같은 부분에서 객체지향의 오해에 대해서 이야기하는 것 같다
협력하는 사람들
커피공화국의 아침
카페의 분업과 협력에 대해 설명하면서
객체 또한 그렇다고 말하는듯 하다
각자의 역할과 책임을 다하고 협력하여 하나의 공동 목표를 달성하는 것
이 것이 객체지향의 목적이라고 말하는 것 같다
요청과 응답으로 구성된 협력
손님 >> (커피 주문) >> 캐셔 >> (커피 제조 요청) >> 바리스타
손님 << (완성된 커피) << 바리스타요청과 응답 이라는 커뮤니케이션을 통해
협력 을 하고 협력의 성공은 각 개인이 요청에 대한 역할을 얼마나 성실히
이행했는가에 달렸다고 한다
역할과 책임
협력의 과정에서 개인은 특정한 역할을 부여받는다
역할은 협력에 참여하는 특정한 개인이 협력 안에서 차지하는 책임이나 의무를 의미한다
역할은 책임이라는 개념을 내포한다
협력을 위해 특정 역할을 맡고 역할에 적합한 책임을 수행한다
사람들의 협력에서는 다음과 같은 중요한 개념이 있다
- 여러 사람이 동일한 역할을 수행할 수 있다
- 역할은 대체 가능하다
- 책임을 수행하는 방법이 자율적이다
- 한 사람이 여러 역할을 수행할 수 있다
역할, 책임, 협력
기능을 구현하기 위해 협력하는 객체들
커피를 주문하는 과정에서
사람을 객체로, 요청을 메시지로, 요청 처리를 메서드로 바꾸면
객체지향에 대한 설명을 할 수 있다
이 것이 실세계를 객체지향에 대입하여 설명하는 이유
역할과 책임을 수행하며 협력하는 객체들
목표는 협력을 통해 달성되고 더 작은 책임으로 분할되어
책임을 수행할 수 있는 적절한 역할을 가진 사람에 의해 수행된다
각 개인은 책임을 수행하기 위해 다른 사람에게 요청하기도 하며
이를 통해 연쇄적 요청과 응답으로 구성된 협력 체계가 완성된다
이쯤 되니 무엇을 말하고자 하는지 알겠다
추상화, SOLID 원칙 등 객체지향을 설명하는 많은 것들보다
역할과 책임의 적절한 분배와 협력으로 프로그래밍을 하는 것
객체지향의 근원적인 목적에 대해서 이야기 하고싶은 것 같다
어떤 객체도 섬이 아니다
객체의 역할에도 사람과 같은 특징을 지닌다
- 여러 객체가 동일한 역할을 수행할 수 있다
- 역할은 대체 가능하다
- 각 객체는 책임을 수행하는 방법을 자율적으로 선택할 수 있다
- 하나의 객체가 여러 역할을 수행할 수 있다
역할은 유연하고 재사용 가능한 협력 관계를 구축하는데 중요한 설계 요소로
대체 가능한 역할과 책임은 다형성과도 깊은 연관을 갖는다
협력 속에 사는 객체
객체지향 애플리케이션의 윤곽을 결정하는 것은 역할, 책임, 협력이지만
이 것들의 주체는 객체다
객체는 애플리케이션의 기능을 구현하기 위해 존재한다
아주 작은 기능도 객체들 간의 협력으로 이루어지고
객체의 품질은 결국 협력의 품질이다
객체의 덕목
- 객체는 충분히 협력적이어야 한다
스스로 모든 것을 처리하려는 객체는 내부 복잡도에 의해 자멸하게 된다 - 객체는 충분히 자율적이어야 한다
요청과 응답으로 협력을 하지만 내부 과정은 객체 스스로 처리할 수 있어야 한다
상태와 행동을 함께 지닌 자율적 객체
객체는 상태와 행동을 함께 지닌 실체 (필드와 메서드)
객체의 자율성은 내부와 외부를 명확히 구분하는 것으로 나온다
객체는 서로 다른 객체가 무엇을 수행하는지는 알아도 어떻게 하는지는 알 수 없다
과거의 전통적 개발 방식은 데이터와 프로세스를 엄격하게 구분하지만
객체지향에서는 데이터와 프로세스를 객체라는 하나의 틀 안에 묶어놓음으로
객체 자율성을 보장한다
협력과 메시지
객체지향에서는 메시지라는 한 가지 수단으로 의사소통을 정의한다
다른 객체에게 요청하는 것은 메시지 전송,
요청을 받는 것은 메시지 수신이라고 한다
메시지를 전송하는 객체는 송신자(sender),
메시지를 수신하는 객체를 수신자(receiver) 라고 부른다
메서드와 자율성
객체는 다른 객체와 협력하기 위해 메시지를 전송한다
수신자는 수신 받은 메시지를 처리할 수 있는 지 점검 후, 메시지를 처리한다
메시지를 처리하는 방법을 메서드라고 부른다
객체지향에서의 메서드는 클래스 내부의 함수 또는 프로시저를 통해 구현된다
메시지를 수신한 수신자가 실행 시간에 메서드를 선택할 수 있다는 것이
객체지향의 핵심 특징 중 하나다
메시지와 메서드 분리는 객체들 간의 자율성을 증진시킨다
외부의 요청이 무엇인지를 표현하는 메시지와
요청을 처리하기 위한 구체적 방법인 메서드를 분리하는 것은
객체의 자율성을 높이는 핵심 매커니즘으로 캡슐화와 깊이 연관되어 있다
객체지향의 본질
- 시스템 상호작용하는 자율적인 객체들의 공동체
- 자율적인 객체는 상태와 행위를 함께 지니며 스스로 책임을 갖는다
- 각 객체는 다른 객체와 협력, 각 객체는 협력 내에서 각자의 역할을 수행하며 역할은 관련된 책임의 집합이다
- 객체는 다른 객체와 협력하기 위해 메시지를 전송하고, 메시지를 수신한 객체는 메시지 처리에 대한 메서드를 자율적으로 선택한다
객체를 지향하라
현재의 객체지향은 계속 부풀려진 결과다
객체지향은 클래스와 상속이 아니다
클래스가 객체지향 프로그래밍 언어 관점에서 매우 중요한 구성요소이지만
객체지향이 핵심은 아니다
프로토타입 기반 객체지향만 봐도 클래스를 사용하지 않고
상속을 클래스가 아닌 객체간의 위임 매커니즘을 기반으로 한다
애플리케이션을 협력하는 객체들의 공동체가 아닌
클래스로 구성된 설계도로 보는 관점은
유연하고 확장 가능한 애플리케이션 구축을 방해한다
객체지향 설계자가 되기 위한 첫 번째 과제
클래스에서 벗어나 메시지를 주고 받는
객체의 관점으로 사고의 중심을 전환하는 것
어떤 클래스가 필요한지 보다는 어떤 객체들이 어떤 메시지를 주고 받으며
협력하는가에 초점을 맞춰야 한다
클래스는 객체들의 협력 관계를 코드로 옮기는 도구에 불과하다
클래스 구조와 메서드 보다는 객체의 역할, 책임, 협력에 집중하자
