[객체지향] 객체지향의 사실과 오해 - 1
본 글은 "객체지향의 사실과 오해"를 읽고 작성하는 독후감입니다.
안녕하세요? 이번 포스팅에서는 객체지향의 사실과 오해라는 책을 읽고 요약한 내용을 공유하고, 읽으면서 들었던 고민을 나눠볼까 합니다.
사실 이 책을 읽고 정리한 지 꽤 되었습니다. 최근 블로그 포스팅으로 고민을 노출해야겠다고 결심하고 가장 먼저 작성하고 싶었던 독후감입니다. 해당 서적은 코드를 설명하지 않습니다. 하지만 개발 패러다임에서 가장 영향력 있는 객체지향 원칙의 본질에 대해 알기 쉽게 설명합니다. 그런 의미에서 개발을 시작하는 사람에게 너무나도 추천하는 도서입니다.
“객체지향 설계자로서 우리의 목적은 현실을 모방하는 것이 아니다. 단지 이상한 나라를 창조하기만 하면 된다. 현실을 닮아야 한다는 어떤 제약이나 구속도 없다” - 객체 지향의 사실과 오해 -
제 1, 2 장
객체의 품질 결정
1. 객체는 충분히 협력해야 합니다.
객체들의 협력은 메시지를 통해 이루어집니다. 그리고 각 객체들은 수신된 메시지를 메서드를 통해 자율적으로 처리합니다.
이 과정에서 메세지와메시지와 메서드는 엄격하게 분리되어야 합니다. 외부의 요청이 무엇인지를 표현하는 메시지와 요청을 처리하기 위한 구체적인 방법인 메서드를 분리하는 것은 객체의 자율성을 높이는 핵심 메커니즘이자, 캡슐화와 밀접하게 관련되어 있습니다.
2. 객체는 자율성이 보장되어야 합니다.
객체는 상태와 행동을 함께 지닌 실체라는 명제가 성립되어야 자율성을 보장할 수 있습니다.
객체의 관점에서 자율성은 내부와 외부의 엄격한 구분에서 시작됩니다. 객체가 하는 일은 외부로부터 간섭받지 않아야 합니다. 즉, 객체는 서로 무엇(what)을 수행하는지는 알지만 어떻게(how) 수행하는지는 몰라야합니다. 즉, 자율성은 관심사의 분리로 이어집니다. 자율적이고 각자의 관심사가 잘 분리된 공동체는 유지보수가 쉽고, 재사용이 용이한 시스템을 구축할 수 있습니다.
객체지향의 오해
객체지향 패러다임의 목적은 현실 세계를 모방하는 것이 아니라 현실 세계를 기반으로 새로운 세계를 창조하는 것입니다. 객체는 생성 시점을 알 수 있고, 독립적인 하나의 단위로 인식할 수 있는 모든 사물을 말합니다.
상태
객체 내에서 행동의 결과는 과거 어떤 행동들이 일어났었느냐에 의존합니다. 상태는 인간의 행동 과정과 결과를 단순하게 기술하기 위해 도입한 개념입니다. 일반적으로 과거에 발생한 행동의 이력을 통해 현재 발생한 행동의 결과를 판단하는 방식은 복잡하고 번거로우며 이해하기 어렵습니다. 상태를 이용하면 과거에 얽매이지 않고 현재를 기반으로 객체의 행동 방식을 이해할 수 있습니다. 즉 상태는 인지 과부하를 줄일 수 있는 중요한 수단입니다.
소프트웨어 구조상에서의 상태 재정의
특정 시점에 객체가 가지고 있는 정보의 집합입니다. 객체의 상태는 정적인 프로퍼티와 동적인 프로퍼티로 구성됩니다. 객체의 프로퍼티는 단순한 값과 다른 객체를 참조하는 링크로 구성됩니다.
⇒ 정적 프로퍼티와 동적 프로퍼티의 구분이 필요합니다.
행동
행동은 “외부의 요청 또는 수신된 메시지에 응답하기 위해 동작하고 반응하는 활동”로 정의할 수 있습니다. 행동의 결과는 다른 객체에게 메시지를 전달할 수 있습니다. 객체는 행동을 통해 다른 객체와 협력하므로 행동은 외부에 가시적이어야 합니다.
상태와 행동
상태는 객체 자신만이 알고 있어야 합니다. 자신의 상태를 외부에 노출하지 않는 것이 캡슐화입니다. 객체는 행동으로 주거받은 메서지를 통헤 스스로 상태를 변경할지 결정합니다. 상태를 잘 정의된 행동 집합 뒤로 캡슐화하면 객체의 자율성을 높이고 협력을 단순하고 유연하게 만들 수 있습니다.
동일성(identical)
객체의 상태가 아닌 식별자를 기반으로 두 객체를 비교하는 기준입니다.
⇒ 상태가 가변적인 두 객체의 동일성을 판단하기 위해서는 상태 변경에 독립적인 별도의 식별자를 이용할 수 밖에 없습니다.
참조 객체 또는 entity로 부르기도 합니다.
조회와 명령의 분리
query와 command만으로 우리는 객체에게 메세지를메시지를 전달할 수 있습니다. 객체가 조회 및 명령 행동만으로 메시지를 잘 전달받아 스스로 상태를 바꾸며 동작한다면, 올바르게 프로그래밍되어 있다고 볼 수 있습니다.
행동 중심 - 책임 주도 설계(Responsibility-Driven Design)
객체의 상태는 행동이 결정합니다. 객체가 올바르게 캡슐화되고, 협력이라는 문맥안에서 잘 기능하려면 객체는 행동을 중심으로 설계되어야 합니다. 협력 안에서 객체의 행동은 결국 객체가 협력에 참여하면서 완수해야 하는 책임을 의미합니다.
제3장: 타입과 추상화
추상화
추상이란 어떤 양상, 세부사항, 구조를 좀 더 명확하게 이해하기 위해 특정 절차나 물체를 의도적으로 생략하거나 감춤으로써 복잡도를 극복하는 방법이다.
복잡도를 다루기 위해 추상화는 두 차원에서 이루어집니다.
- 첫 번째 차원은 구체적인 사물들 간 공통점은 취하고 차이점은 버리는 일반화를 통해 단순하게 만드는 것
- 두 번째 차원은 중요한 부분을 강조하기 위해 불필요한 세부 사항을 제거함으로써 단순하게 만드는 것
즉, 객체지향 패러다임은 객체라는 추상화를 통해 현실의 복잡성을 극복합니다. 우리는 객체지향 패러다임을 이용해 유용하고 아름다운 애플리케이션을 개발할 수 있습니다.
“기껏해야 트럼프에 불과해”
이상한 나라의 앨리스에 등장하는 정원사, 병사, 왕자와 공주, 하객들은 모두 구별됩니다. 하지만 앨리스는 위와 같이 언급하며 개념을 그룹 지으며 상황을 단순화합니다. 우리는 공통점을 기반으로 객체들을 묶습니다. 그리고 우리는 그 공통점을 개념이라고 부릅니다. 개념이란 우리가 인식하고 있는 다양한 사물이나 객체에 적용할 수 있는 아이디어나 관념이죠.
객체를 다시한번 정의할 수 있습니다. 객체는 특정한 개념을 적용할 수 있는 구체적인 사물입니다. 그리고 개념 안에서 묶인 개체 하나하나를 인스턴스라고 부를 수 있습니다. 현실세계에서 우리는 개념을 찾아내죠. 하지만 소프트웨어를 설계할 때는 현실세계와 달리 개념을 창조해야 합니다. 이러한 점에서 객체지향은 현실세계의 모방보다는 기반의 창조가 맞지 않을까요?
“분류는 단지 추상화를 위한 도구입니다.”
개념의 분류는 객체들의 복잡성을 극복하기 위한 추상화 도구입니다. 설계자는 필요하다고 생각하는 부분만 고르고 나머지를 쳐내며 객체를 추상화합니다.
마지막으로, 추상화된 객체는 설계자의 의도대로 개념으로 분류됩니다. 설계자는 분류와 추상화를 통해 복잡한 세상을 소프트웨어 세계 속에서 제어합니다. 여기서 우리는 개념을 대체할 다른말을 사용할 수 있습니다. 수학에서 우리는 type을 빌려올 수 있어요. 타입은 우리가 인식하는 다양한 사물이나 객체에 적용할 수 있는 아이디어와 관념입니다. (여기서 말하는 타입은 int, char와 같은 원시타입이 아닌 객체를 분류하는 개념으로 조금 더 포괄적으로 쓰입니다.)
“데이터 타입은 메모리 안에 저장된 데이터의 종류를 분류하는 데 사용하는 메모리 집합에 관한 메타데이터다. 데이터에 대한 분류는 암시적으로 어떤 종류의 연산이 해당 데이터에 대해 수행될 수 있는지를 결정한다.”
행동이 타입을 결정한다? (제일 흥미로웠던 부분이자 간과했던 부분)
동일한 행동 == 동일한 책임
동일한 책임 == 동일한 메세지의 수신
동일한 타입에 속한 객체는 내부의 데이터 표현 및 처리 방식이 다르더라도, 동일한 메시지를 수신하고 이를 처리할 수 있습니다. 여기서 내부에서 처리하는 방식이 다르다는 말은 다형성에 의미를 부여할 수 있습니다.
동일한 메세지를 다른 방식으로 처리하기 위해서는 결국 동일한 메시지를 수신할 수 있어야 합니다.
우리는 동일한 메세지를 다양한 방식으로 처리하기 위해 결국 계층을 나누고, 추상화하며 상속합니다. 그리고 다양한 방식은 곧 행동을 의미합니다. 우리가 나누는 슈퍼, 서브 타입은 모두 행동으로 구분됩니다.
또한 타입은 시간의 흐름에 따라 상태가 변하는 객체를 식별가능하게 해 줍니다. 따라서 우리는 타입을 통해 동적이라는 복잡한 특성을 정적이라는 단순한 특성으로 변화시킬 수 있습니다.