객체지향의 사실과 오해 Chapter 02 리뷰

Chapter 02 이상한 나라의 객체

“객체지향 패러다임은 지식을 추상화하고 추상화한 지식을 객체 안에 캡슐화함으로써 실세계 문제에 내재된 복잡성을 관리하려고 한다. 객체를 발견하고 창조하는 것은 지식과 행동을 구조화하는 문제다.” -Rebecca Wirfs-Brock-

 

객체지향과 인지 능력

심리학자인 엘리자베스 스펠크와 필립 켈만의 인지 실험 실험 결과를 토대로, 인간은 본능적으로 세상을 독립적이고 식별 가능한 객체의 집합으로 바라본다.

인간이 직접적으로 지각할 수 있는 물리적인 경계를 지닌 객체인 구체적인 사물들의 한계를 넘어서 추상적인 사물까지 객체적으로 인식할 수 있다.

즉, 객체는 인간이 분명하게 인지할 수 있고 구별할 수 있는 물리적인 또는 개념적인 경계를 지닌 어떤 것이다.

객체지향의 패러다임은 현실 세계를 모방하는 것이 아니라 현실 세계를 기반으로 새로운 세계를 창조하는 것이다. 소프트웨어 세계에서 살아가는 객체는 현실세계에 존재하는 객체와는 전혀 다른 모습으로 나타난다.

 

✨소프트웨어에서의 객체와 실제 세계의 객체 간의 차이를 이해하는데 많은 어려움이 있었던 이유를 이 구절에서 찾았다. 첫 객체지향 프로젝트에서 소프트웨어 세계에서는 실제 현실과는 다른 역할이 존재하고 경계도 미묘하게 달라 이질감을 느꼈었다. 너무 실제 세계와 연관지어서 생각하지 말고 소프트웨어 세계에서는 소프트웨어 세계만의 방식대로 설계를 해야겠다고 깨달았다!

객체, 그리고 이상한 나라

앨리스의 상태를 결정하는 것은 행동이지만, 행동의 결과를 결정하는 것은 상태다. (앨리스의 키를 변화시키는 것은 앨리스의 행동이다. 앨리스가 하는 행동에 따라 앨리스의 상태가 변하게 된다.)

어떤 행동의 성공 여부는 이전에 어떤 행동들이 발생했는지에 영향을 받는다. = 행동의 순서가 중요하다.

 

앨리스의 특징을 요약해보자면

• 앨리스는 상태를 가지며 상태는 변경 가능하다.
• 앨리스의 상태를 변경시키는 것은 앨리스의 행동이다.
  • 행동의 결과는 상태에 의존적이며 상태를 이용해 서술할 수 있다.
  • 행동의 순서가 결과에 영향을 미친다.
• 앨리스는 어떤 상태에 있더라도 유일하게 식별 가능하다.

객체, 그리고 소프트웨어 나라

인간의 인지 능력 안에서 개수를 셀 수 있고, 다른 사물과 비교할 수 있고, 생성 시점을 알 수 있고, 독립적인 하나의 단위로 인식할 수 있는 모든 사물은 객체다.

객체를 효과적으로 이해하기 위해서 객체를 상태 state, 행동 behavior, 식별자 identify를 지닌 실체로 보는 것이 가장 효과적이다.

⚡ 객체는 물리적으로 구체적인 사물일 수도, 추상적으로 개념적인 사물일 수도 있다. 식별자, 특징적인 행동, 변경 가능한 상태를 가진다. 소프트웨어 안에서 객체는 저장된 실행 가능한 코드를 통해 구현된다.

 

📌앨리스 얘기를 들으면서 이해된 객체의 추상적인 개념들을 한번에 정리해서 객체의 정의와 특징을 한번에 이해할 수 있었다.

 

왜 상태가 필요한가?

상태를 이용하면 과거의 모든 행동 이력을 설명하지 않고도 행동의 결과를 쉽게 예측하고 설명할 수 있다. 상태는 근본적으로 세상의 복잡성을 완화하고 인지 과부화를 줄일 수 있는 중요한 개념이다.

 

상태와 프로퍼티

객체의 상태를 나타내는 단순한 값들은 그 자체로 독립적인 의미를 가지기보다는 다른 객체의 특성을 표현하는 데 사용된다.

하지만!! 때로는 단순한 값이 아니라 객체를 사용해 다른 객체의 상태를 표현해야 할 때가 있다.

 

“앨리스가 현재 음료를 들고 있는 상태를 표현하고 싶다면 어떻게 할 것인가?”

가장 간단하고 직관적인 방법은 앨리스의 상태 일부를 음료라는 객체를 이용해 표현하는 것이다.

 

결론적으로 모든 객체의 상태는 단순한 값과 객체의 조합으로 표현할 수 있다. 객체의 상태를 구성하는 모든 특징을 객체의 프로퍼티 property라고 한다. 일반적으로 프로퍼티는 정적이다.

 

객체와 객체 사이의 의미 있는 연결을 링크 link라고 한다. 객체와 객체 사이에는 링크가 존재해야만 요청을 보내고 받을 수 있다. 즉, 객체의 링크를 통해서만 메시지를 주고 받으며 협력이 가능하다.

 

[예시]

 

 

 

 

 

 

 

 

원래 앨리스의 상태는 앨리스가 음료를 가지고 있기 때문에 음료와의 link가 존재하고, 이 link를 통해서 앨리스와 음료 간의 협력이 가능하다. 하지만 변경된 앨리스의 상태를 보면 앨리스와 음료간의 link가 없기 때문에 앨리스와 음료는 협력하지 못한다.

 

 

링크는 객체가 다른 객체가 참고할 수 있다는 것을 의미하며, 일반적으로 한 객체가 다른 객체의 식별자를 알고 있는 것으로 표현된다.

 

객체를 구성하는 단순한 값은 속성 attribute라고 한다. (앨리스의 키와 위치는 단순한 값으로 표현되기 때문에 속성이다.)

 

📌모든 것이 객체라고 이해할 수 있다는 시점에서 객체와 객체가 아닌 것을 구분해주는 내용이 이어졌다. 객체는 서로 다 연결이 되어있다는 점을 항상 리마인드하면서 소프트웨어의 객체를 이해해야겠다.

 

⚡ 객체는 특정 시점에 객체가 가지고 있는 정보의 집합으로 객체의 구조적 특징을 표현한다. 객체의 상태는 객체에 존재하는 정적인 프로퍼티와 동적인 프로퍼티 값으로 구성된다. 객체의 프로퍼티는 단순한 값과 다른 객체를 참조하는 링크로 구분할 수 있다.

✨객체는 자율적인 존재이란 걸 명심! 객체는 다른 객체의 상태에 직접적으로 접근할 수도, 상태를 변경할 수도 없다. 갹체지향의 기본 사상은 상태와 상태를 조작하기 위한 행동을 하나의 단위로 묶는 것임을 기억하자! 객체는 스스로의 행동에 의해서만 상태가 변경되는 것을 보장함으로써 객체의 자율성을 유지한다.

 

행동

객체가 취하는 행동은 객체 자신의 상태를 변경시킨다. 객체의 상태를 변경하는 것은 객체의 자발적인 행동뿐이다. 객체의 행동에 의해 객체의 상태가 변경된다는 것은 행동이 부수 효과 side effect를 초래한다는 것을 의미한다. 부수 효과의 관점에서 객체의 행동을 이해할 수 있다.

[예시]

• 앨리스가 음료를 마시는 행위는 앨리스의 키를 작게 변화시키고, 음료수의 양을 줄이는 부수효과를 야기한다.
• 앨리스가 문을 통과하는 행위는 앨리스의 위치를 변경시키는 부수 효과를 초래한다.

첫 번째 예시에서, 음료를 마시는 행동의 결과가 앨리스의 키에 의존한다는 것을 의미한다.

상태와 행동 사이에는 다음과 같은 관계가 있다.

• 객체의 행동은 상태에 영향을 받는다.
• 객체의 행동은 상태를 변경시킨다.

이것을 상태라는 개념을 이용해 행동을 다음의 두 가지 관점에서 서술할 수 있음을 의미한다.

• 상호작용이 현재의 상태에 어떤 방식으로 의존하는가.
• 상호작용이 어떻게 현재의 상태를 변경시키는가.

협력과 행동

객체는 자신의 주어진 책임을 완수하기 위해서 다른 객체들을 이용하고 다른 객체들에게 서비스를 제공한다. 객체는 수신된 메세지를 따라 적절한 행동을 하면서 협력에 참여하고 그 결과로 자신의 상태를 변경한다. 

 

객체의 행동으로 인해 발생하는 결과는 두 가지 관점에서 설명할 수 있다. 

• 객체 자신의 상태 변경
• 행동 내에서 협력하는 다른 객체에 대한 메세지 전송

⚡ 행동이란 외부의 요청 또는 수신된 메세지에 응답하기 위해 동작하고 반응하는 행동이다. 행동의 결과로 객체는 자신의 상태를 변경하거나 다른 객체에게 메세지를 전달할 수 있다. 객체는 행동을 통해 다른 객체와의 협력에 참여하므로 행동은 외부에 가시적이어야 한다.

 

상태 캡슐화

📌현실 세계와 객체 세계에서의 중요한 차이점이 있다면, 객체지향의 세계에서는 모든 객체는 자신의 상태를 "스스로" 관리하는 존재라는 것이다. 앨리스가 물을 마시면 물의 양은 줄어들게 된다. 이 때 앨리스가 물을 마셨다는 메세지를 물에게 전달할 뿐, 앨리스가 물의 양을 변하게 만들지는 않는다. 물의 양을 줄이는 건 메세지를 수신한 물이 결정할 사항이다.

 

객체는 상태를 캡슐 안에 감춰둔 채 외부에 노출하지 않는다. 객체가 외부에 노출하는 것은 행동뿐이며, 외부에서 객체에 접근할 수 있는 유일한 방법 역시 행동뿐이다. 

결론적으로 상태를 잘 정의된 행동 집합 뒤로 캡슐화하는 것은 객체의 자율성을 높이고 협력을 단순하고 유연하게 만든다. 

 

식별자

모든 객체는 식별자를 가지며 식별자를 이용해 객체를 구별할 수 있다. 값과 객체의 가장 큰 차이점은 값은 식별자를 가지지 않지만 객체는 식별자를 가진다는 점이다. 

 

값value는 숫자, 문자열, 날짜, 시간 등과 같이 변하지 않는 양을 모델링하고 불변 상태를 가진다. 

값이 같은지 여부는 상태가 같은지를 이용해 판단한다. 값의 상태가 같으면 ➡ 두 인스턴스는 동일한 것으로 판단하고, 값의 상태가 다르면 ➡ 두 인스턴스는 다른 것으로 판단한다.

이 처럼 상태를 이용해 두 값이 같은지 판단할 수 있는 성질을 동등성 equality이라고 한다.

 

객체는 시간에 따라 변경되는 상태를 포함하며, 행동을 통해 상태를 변경한다. 객체는 가변 상태를 가진다. 타입이 같은 두 객체의 상태가 완전히 똑같더라도 두 객체는 독립적인 별개의 객체로 다뤄야 한다.

객체 역시 상태와 무관하게 두 객체를 동일하거나 다르다고 판단할 수 있는데, 이 처럼 식별자를 시반으로 객체가 같은지를 판단할 수 있는 성질을 동일성 identical이라고 한다.

 

✨상태를 기반으로 객체의 동일성을 판단할 수 없는 이유는 시간의 흐름에 따라 객체의 상태가 변하기 때문이다. 상태가 가변적인 두 객체의 동일성을 판단하기 위해서는 상태 변경에 독립적인 별도의 식별자를 이용할 수 밖에 없다!

 

💡값과 객체의 차이점에서 오는 혼란

갑솨 객체 두 개념 모두 프로그래밍 언어에서 클래스를 이용해 구현되기 때문에 혼란이 올 수 있다. 

참조 객체 reference object, 엔티티 entity는 식별자를 지닌 전통적인 의미의 객체를 가리키는 용어다.

값 객체 value object는 식별자를 가지지 않는 값을 가리키는 용어다.

 

⚡ 객체는 어떤 상태에 있더라도 유일하게 식별 가능하다.

 

기계로서의 객체

객체의 상태를 조회하는 작업을 퀴리 query라고 하고, 객체의 상태를 변경하는 작업을 명령 command라고 한다. 객체가 외부에 제공하는 행동의 대부분은 퀴리와 명령으로 구성된다.

 

마이어가 제시한 기계 은유를 빌리서 이해를 할 수 있다. 사용자가 객체 기계의 버튼을 눌러 상태를 변경하거나 상태 조회를 요청하는 것은 객체의 행동을 유발하기 위해 메세지를 전송하는 것과 유사하다. 버튼을 누르는 것은 기계의 사용자지만 눌린 버튼에 따라 어떤 방식으로 동작할지는 기계 스스로 결정한다. 

✨ 객체에 접근할 수 있는 유일한 방법은 객체가 제공하는 행동뿐이다! 즉, 사용자는 인터페이스를 통해서만 객체에 접근할 수 있다는 걸 잊지 말자!

 

행동이 상태를 결정한다

✨가장 쉽게 빠지는 함정은 상태를 중심으로 객체를 바라보는 것이다. 상태가 무엇인지를 결정하고 그 상태에 필요한 행동을 결정하는 것은 설계의 나쁜 영향을 끼친다. 캡슐화가 저해되고, 객체를 협력자가 아닌 고립된 섬으로 만들고, 객체의 재사용이 저하된다.

 

⚡ 객체의 행동에 초점을 맞추는 것이 중요하다! 객체의 적합성을 결정하는 것은 상태가 아니라 객체의 행동이다.
⚡ 행동이 상태를 결정한다!⚡

설계자로서 우리는 협력의 문맥에 맞는 적절한 행동을 수행하는 객체를 발견하거나 창조해야 한다. 결과적으로 우리가 애플리케이션 안에서 어떤 행동을 원하느냐가 어떤 객체가 적합한지를 결정한다. 

 

객체지향 설계는 애플리케이션에 필요한 협력을 생각하고 협력에 참여하는 게 필요한 행동을 생각한 후 행동을 수행할 객테를 선택하는 방식으로 수행된다. 행동을 결정하고, 행동에 필요한 정보가 무엇인지를 고려하게 되며 이 과정에서 필요한 상태가 결정된다. 

 

협력 안에서 객체의 행동은 결국 객체가 협력에 참여하면서 완수해야 하는 책임을 의미한다. 따라서 어떤 책임이 필요한가를 결정하는 과정이 전체 설계를 주도해야 한다. 책임-주도 설계 Responsibilty-Driven는 협력이라는 문맥 안에서 객체의 행동을 생각해 응집도 높고 재사용이 용이한 객체를 만들 수 있어야 한다! 

 

⚡ 객체지향 설계자로서 우리의 목적은 현실을 모방하는 것이 아니다. 단지 이상한 나라를 창조하기만 하면 된다.

 

📌느낀점

소프트웨어 세계에서 설계는 현실 세계를 모방하는 것이 아니라 필요한 부분들만 가져와야 된다는 깨달음이 가장 컸다. 또 UML을 설계하는 과정에서 자연스럽게 값value를 먼저 생각하고 있는 나를 발견했다. 프로그램을 설계할 때 처음부터 복잡하게 생각하지 말고 단순하게 시작을 하는 것이 더 쉽고 빠르게 만들 수 있는 방법같다. 내가 이 책을 읽기 전에 만들었던 프로그램들이 눈 앞을 지나가면서 나는 객체지향을 완전히 이해하지 못하고 여태까지 좀 비효율적인 코드를 만들었다고 느꼈다. 이 책을 끝내고 내가 만든 프로그램들을 다시 공부해보는 것도 좋을 것 같다고 생각했다.

객체지향 어플리케이션을 잘 분석하고 설계하기 위해서는 현실 세계를 자세히 관찰하고 그 안에 존재하는 실체 객체들의 특징을 간추리고 요약해서 소프트웨어 객체로 추상화할 수 있는 능력이 중요하다고 느꼈다. 평소에 현실 세계를 객체들의 협력 공간으로 생각하고 분석하는 힘을 기르기로 다짐했다. 

마지막으로 수동적인 프로그램이 아니라 객체들이 능동적으로 협력할 수 있는 프로그램을 만들어야겠다고 느꼈다. 현실의 객체보다 소프트웨어 세계안에서의 객체는 더 많은 일을 수행할 수 있기 때문에 내가 생각하지 못한 부분들도 추상화 시켜서 더 객체들 간의 협력이 좋고 유지보수가 쉬운 프로그램을 설계하고 싶다! 

 

📌 같이 스터디 중인 김경욱님의 포스팅 첨부!

https://velog.io/@kimku1018/%EA%B0%9D%EC%B2%B4%EC%A7%80%ED%96%A5%EC%9D%98-%EC%82%AC%EC%8B%A4%EA%B3%BC-%EC%98%A4%ED%95%B4-Study-2 

객체지향의 사실과 오해 Study - (2)