객체지향의 사실과 오해 1 · 2장

해당 책을 가볍게 읽으면서 생각해 보는 시간을 갖도록 합니다.

 

1, 2장을 읽으면서 솔직히 들었던 생각은 재미있는데 아직은 완전히 와 닿지 않는다는 생각이었다. 책을 읽으면서 계속해서 드는 생각은 이를 어떻게 코드에 잘 녹여낼 수 있을까라는 생각이었는데 사실 너무 욕심인 것 같기도 하다. 책 한 번 읽는다고 적용이 쉽게 된다면 프로그래밍이 너무 쉬울테니까 말이다. 그래서 그냥 교양 책 한 권 읽는다는 생각으로 가볍게 접근했다.

 

1, 2장에서 개인적으로 중요하다고 느꼈던 점은 용어에 대한 이해를 어느 정도 해야 한다는 점이었다. 역할, 책임, 협력, 메시지, 상태, 행동 등 정말 다양한 용어가 등장하는데 이것을 잘 이해하고 우리의 현재 상황에 잘 빗대어 생각하는 것이 중요해보였다.

객체지향의 핵심은 클래스가 아니다. 핵심은 적절한 책임을 수행하는 역할 간의 유연하고 견고한 협력 관계를 구축하는 것이다. ~ (중략) ~ 클래스의 구조와 메서드가 아니라 객체의 역할, 책임, 협력에 집중하라.

객체지향을 클래스를 중심으로 바라보지 말고, 각각의 역할과 책임 그리고 협력 관계에 집중하라는 부분이 인상적이었다. 우리는 항상 코드를 대할 때 클래스, 구조체 등등을 어떻게 만들지만 고민하지 그 객체의 역할에 대해 깊게 고민한 적은 없던 것 같다. 역할,책임,협력에 대해서 이해하는 것이 객체지향의 이해의 시작이라는 생각이 들었다.

 

---

 

그리고 상태와 행동에 대한 표현이 여러 번 등장했는데 개인적으로 이해한 것으로는 상태란 어떤 변화하는 내용인 것 같고, 행동이란 변화를 일으키는 어떠한 동작 또는 수단인 것 같다. 간단히 대입해보면 상태는 프로퍼티, 또다른 객체, 다른 객체를 연결하는 링크가 될 수 있을 것 같고 행동은 변화를 일으키는 메서드라고 볼 수 있을 것 같다.

상태를 외부에 노출시키지 않고 행동을 통해서 접근하는 것이 곧 캡슐화이고, 객체의 자율성을 높이는 작업이라고 한다. 그동안 객체 안의 프로퍼티 또는 상태에 너무 직접적으로 접근하고 있지 않았나라는 생각도 들었다.

 

---

 

'값과 객체는 동일성, 동등성의 차이가 있다. 값은 오직 상태만을 이용해 동등성을 판단하기 때문에 인스턴스를 구별하기 위한 별도의 식별자를 필요로 하지 않는다.' - 이 부분에서 뭔가 equatable과 identifiable 프로토콜이 떠올랐다.

 

---

 

'상태를 먼저 결정하고 행동을 나중에 결정하는 방법은 설계에 나쁜 영향을 끼친다.', '어떤 책임이 필요한가를 결정하는 과정이 전체 설계를 주도해야 한다.' - 아직 이 말이 확 와닿지는 않는다. 좀 더 찾아보아야 할 것 같다.

 

 

loc	sentence
30p	객체지향 설계라는 예술은 적절한 객체에게 적절한 책임을 할당하는 것에서 시작된다.
31p	객체지향 프로그래밍에 경험이 많은 사람들조차 역할의 중요성을 간과하곤 한다. 역할은 유연하고 재사용 가능한 협력 관계를 구축하는 데 중요한 설계 요소다.
33p	객체의 내부와 외부를 명확하게 구분하는 것으로부터 나온다. 객체의 사적인 부분은 객체 스스로 관리하고 외부에서 일체 간섭할 수 없도록 차단해야 하며, 객체의 외부에서는 접근이 허락된 수단을 통해서만 객체와 의사소통해야 한다. 객체는 다른 객체가 무엇을 수행하는지는 알 수 있지만 어떻게 수행하는지에 대해서는 알 수 없다.
34p	객체지향의 세계에서는 오직 한 가지 의사소통 수단만이 존재한다. 이를 메시지라고 한다. 한 객체가 다른 객체에게 요청하는 것을 메시지를 전송한다고 말하고 다른 객체로부터 요청을 받는 것을 메시지를 수신한다고 말한다.
34~35p	객체는 다른 객체와 협력하기 위해 메시지를 전송한다. 수신자는 먼저 수신된 메시지를 이해할 수 있는지 여부를 판단한 후 미리 정해진 자신만의 방법에 따라 메시지를 처리한다. 메시지를 처리하는 방법을 메서드라고 부른다. 외부의 요청이 무엇인지를 표현하는 메시지와 요청을 처리하기 위한 구체적인 방법인 메서드를 분리하는 것은 객체의 자율성을 높이는 핵심 매커니즘이다. 이것은 캡슐화라는 개념과도 깊이 관련돼 있다.
47p	객체란 식별 가능한 개체 또는 사물이다. 객체는 자동차처럼 만질 수 있는 구체적인 사물일 수도 있고, 시간처럼 추상적인 개념일 수도 있다. 객체는 구별 가능한 식별자, 특징적인 행동, 변경 가능한 상태를 가진다. 소프트웨어 안에서 객체는 저장된 상태와 실행 가능한 코드를 통해 구현된다.
51p	객체지향의 세계에서 객체는 다른 객체의 상태에 직접적으로 접근할 수도, 상태를 변경할 수도 없다. 자율적인 객체는 스스로 자신의 상태를 책임져야 한다. 외부의 객체가 직접적으로 객체의 상태를 주무를 수 없다면 간접적으로 객체의 상태를 변경하거나 조회할 수 있는 방법이 필요하다.
56p	객체는 상태를 캢슐 안에 감춰둔 채 외부로 노출하지 않는다. 객체가 외부에 노출하는 것은 행동뿐이며, 외부에서 객체에 접근할 수 있는 유일한 방법 역시 행동뿐이다. 상태를 외부에 노출시키지 않고 행동을 경계로 캡슐화하는 것은 결과적으로 객체의 자율성을 높인다.
57p	객체가 식별 가능하다는 것은 객체를 구분할 수 있는 특정한 프로퍼티가 객체 안에 존재한다는 것을 의미한다. 이 프로퍼티를 식별자라고 한다.
64p	상태를 먼저 결정하고 행동을 나중에 결정하는 방법은 설계에 나쁜 영향을 끼친다.
65p	협력 안에서 객체의 행동은 결국 객체가 협력에 참여하면서 완수해야 하는 책임을 의미한다. 어떤 책임이 필요한가를 결정하는 과정이 전체 설계를 주도해야 한다. (RDD) → 응집도 높고 재사용 가능한 객체를 만들 수 있게 한다.