[객체지향의 사실과 오해] 01 협력하는 객체들의 공동체
1-7까지는 저 스스로의 이해를 위한 단순 책 요약입니다요
01 협력하는 객체들의 공동체
저자는 본격적으로 장을 시작하기에 앞서 객체지향을 “실세계 모델링, 모방” 과 연관 짓는 설명은 단순히 이해와 학습을 위한 것일 뿐 실무적인 관점에서는 매우 부적합한 설명이며, 객체지향의 목표는 실세계 모방이 아닌 새로운 세계의 창조에 목표를 두는 것임을 명확히 한다.
1장에서는 객체 지향을 설명하기 위해 커피를 주문하는 과정을 예시로 든다. 이를 정리하면 다음과 같다.
요청
스스로 해결할 수 없는 문제에 대해 도움을 구하는 것. 일반적으로 하나의 문제를 해결하기 위해서는 다수의 역할이 필요하기 때문에 요청은 연쇄적으로 발생.
응답
요청을 받았을 때, 주어진 책임을 다하며 필요한 지식이나 서비스를 제공하는 것. 응답 역시 요청과 마찬가지로 연쇄적으로 전달.(요청과 역방향으로 전개)
역할
협력 안에서 차지하는 책임이나 임무로, 유연하고 재사용 가능한 협력 관계를 구축하는데 매우 중요한 요소.
역할과 책임
- 여러 사람이 동일한 역할을 수행할 수 있음
- 역할은 대체 가능성을 의미
- 책임을 수행하는 방법은 자율적으로 선택할 수 있음
- 한 사람이 동시에 여러 역할을 수행할 수 있음
객체지향 설계는 적절한 객체에 적절한 책임을 할당하는 것에서 시작되며 얼마나 적절한 책임을 선택하느냐가 애플리케이션의 아름다움을 결정한다.
객체
객체는 협력에 참여하는 주체로서 애플리케이션의 기능을 구현하기 위해 존재. 일반적으로 객체는 다른 객체와의 협력을 통해 기능을 구현하는데, 객체는 협력적이며 자율적이어야 한다. 객체는 사적인 부분은 객체 스스로 관리하고 외부에서 간섭할 수 없도록 차단하며 객체 외부에서는 접근이 허락된 수락을 통해서만 객체와 의사소통해야 한다. 즉, 객체는 다른 객체가 무엇을 수행하는지는 알 수 있지만 어떻게 수행하는지에 대해서는 알 수 없다.
메시지
객체 간의 요청을 뜻함. 객체는 협력을 위해 다른 객체와 메시지를 송수신한다.
메시지를 수신한 객체가 실행 시간에 메서드를 선택할 수 있다는 점은 프로시저 호출에 대한 실행 코드를 컴파일 시간에 결정하는 절차적인 언어와 확연히 구분되는 특징이다.
요약 - 객체지향의 본질
- 객체지향이란 시스템을 상호작용하는 자율적인 객체들의 공동체로 바라보고 객체를 이용해 시스템을 분할하는 방법
- 자율적인 객체란 상태와 행위를 함께 지니며 스스로 자기 자신을 책임지는 객체를 의미
- 객체는 시스템의 행위를 구현하기 위해 다른 객체와 협력. 각 객체는 협력 내에서 정해진 역할을 수행하며, 역할은 관련된 책임의 집합
- 객체는 다른 객체와 협력하기 위해 메시지를 전송하고, 메시지를 수신한 객체는 메시지를 처리하는 데 적합한 메서드를 자율적으로 선택
마지막으로, 코드를 담는 클래스의 관점에서 메시지를 주고받는 객체의 관점으로 사고의 중심을 전환해야 하며 객체지향의 핵심은 클래스가 아니라, 적절한 책임을 수행하는 역할 간의 유연하고 견고한 협력 관계를 구축하는 것임을 강조. 객체지향의 중심에는 클래스가 아니라 객체가 위치하며, 클래스들의 정적인 관계가 아닌 메시지를 주고받는 객체들의 동적인 관계가 중요하다.
++
절차적인 언어
절차적 프로그래밍(PP) vs 객체지향 프로그래밍(OOP)
UML(Unified Modeling Language)
통합 모델링 언어(시스템을 모델링하기 위한 언어. 즉, 설계도를 그리기 위한 언어)로, 객체 지향 프로그래밍 소프트웨어 집약 시스템을 개발할 때 산출물을 명세화, 시각화, 문서화할 때 사용한다. 크게 클래스 다이어그램(Class Diagram), 객체 다이어그램(Object Diagram) 등의 구조 다이어그램(Structure Diagram)과 활동 다이어그램(Activity Diagram), 상태 머신 다이어그램(State Machine Diagram) 등의 행위 다이어그램(Behavior Diagram)으로 나뉜다.
ex) 클래스 다이어그램 
링크