Skip to content

Latest commit

 

History

History
165 lines (118 loc) · 11.1 KB

혁주.md

File metadata and controls

165 lines (118 loc) · 11.1 KB

2. 이상한 나라의 객체

객체지향과 인지 능력

  • 객체란 인간이 분명하게 인지하고 구별할 수 있는 물리적인 또는 개념적인 경계를 지닌 어떤 것이다.
  • 객체지향 패러다임의 목적은 현실 세계를 모방하는 것이 아니라 현실 세계를 기반으로 새로운 세계를 창조하는 것이다. 따라서 소프트웨어 세계에서 살아가는 객체는 현실 세계에 존재하는 객체와는 전혀 다른 모습을 보이는 것이 일반적이다.

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

  • 하나의 개별적인 실체로 식별 가능한 물리적인 개념 또는 개념적인 사물은 어떤 것이라도 객체가 될 수 있다.

  • 객체의 다양한 특성을 효과적으로 설명하기 위해서는 객체를

    • 상태(state)
    • 행동(behavior)
    • 식별자(identify)

    를 지닌 실체로 보는 것이 가장 효과적이다.

상태

왜 상태가 필요한가?

  • 어떤 행동의 결과는 과거에 어떤 행동들이 일어났었느냐에 의존한다.
  • 과거에 발생한 행동의 이력을 통해 현재 발생한 행동의 결과를 판단하는 방식은 복잡하고 번거로우며 이해하기 어렵다.
  • 인간은 행동의 과정과 결과를 단순하게 기술하기 위해 상태라는 개념을 고안했다.
  • 상태를 이용하면 과거의 모든 행동 이력을 설명하지 않고도 행동의 결과를 쉽게 예측하고 설명할 수 있다.
    • 앨리스의 키와 문의 높이라는 두 가지 상태만 알면 문을 통과하는 행동의 결과를 쉽게 예측할 수 있다.
  • 상태를 이용하면 과거에 얽매이지 않고 현재를 기반으로 객체의 행동방식을 이해할 수 있다.

상태와 프로퍼티

  • 세상에 존재하는 모든 것들이 객체인 것은 아니다.
    • 앨리스의 ‘키’, ‘위치’, 음료와 케이크의 ‘양’
    • 숫자, 문자열, 양, 속도, 시간, 날짜, 참/거짓과 같은 단순한 값들
  • 다른 객체의 상태를 표현하기 위해 사용됨
  • 모든 객체의 상태는 단순한 값과 객체의 조합으로 표현할 수 있다. 이때 객체의 상태를 구성하는 모든 특징을 통틀어 객체의 프로퍼티(property)라고 한다.
  • 일반적으로 프로퍼티는 변경되지 않고 고정되기 때문에 ‘정적’이다.
  • 프로퍼티 값(property value)은 시간이 흐름에 따라 변경되기 때문에 ‘동적’이다.
  • 객체와 객체 사이의 의미 있는 연결을 링크(link)라고 한다. 객체와 객체 사이에는 링크가 존재해야만 요청을 보내고 받을 수 있다.
  • 객체 간의 선으로 표현되는 링크와 달리 객체를 구성하는 단순한 값은 속성(attribute)이라고 한다.
  • 객체의 프로퍼티 = 속성(단순한 값) + 링크(다른 객체와의 연결)
📌 상태는 특정 시점에 객체가 가지고 있는 정보의 집합으로 객체의 구조적 특징을 표현한다. 객체의 상태는 객체에 존재하는 정적인 프로퍼티와 동적인 프로퍼티 값으로 구성된다. 객체의 프로퍼티는 단순한 값과 다른 객체를 참조하는 링크로 구분할 수 있다.
  • 객체는 자율적인 존재다. 객체지향의 세계에서 객체는 다른 객체의 상태에 직접적으로 접근할 수도, 상태를 변경할 수도 없다.

행동

상태와 행동

  • 객체의 상태는 저절로 변경되지 않는다. 객체가 상태를 변경하는 것은 객체의 자발적인 행동뿐이다.
  • 객체가 취하는 행동은 객체 자신의 상태를 변경시킨다. 객체의 행동에 의해 객체의 상태가 변경된다는 것은 행동이 부수 효과(side effect)를 초래한다는 것을 의미한다.
  • 상태와 행동 사이의 관계
    • 객체의 행동은 상태에 영향을 받는다.
    • 객체의 행동은 상태를 변경시킨다.

협력과 행동

  • 어떤 객체도 섬이 아니다.
  • 객체의 행동은 이 두 가지 관점의 부수효과를 명확하게 서술해야 한다.
    • 객체 자신의 상태 변경
    • 행동 내에서 협력하는 다른 객체에 대한 메시지 전송
📌 행동이란 외부의 요청 또는 수신된 메시지에 응답하기 위해 동작하고 반응하는 활동이다. 행동의 결과로 객체는 자신의 상태를 변경하거나 다른 객체에게 메시지를 전달할 수 있다. 객체는 행동을 통해 다른 객체와의 협력에 참여하므로 행동은 외부에 가시적이어야 한다.

상태 캡슐화

IMG_7041

  • 두 메시지를 보고 앨리스의 키가 줄어든다거나 음료의 양이 줄어든다는 상태 변경을 예상할 수 있겠는가?
  • 메시지를 앨리스에게 전송하는 객체이건 음료에게 메시지를 전송하는 앨리스 객체이건 메시지 송신자는 메시지 수신자의 상태 변경에 대해서는 전혀 알지 못한다. → 캡슐화
  • 사실 객체에게 메시지를 전달하는 외부의 객체는 메시지를 수신하는 객체의 상태가 변경된다는 사실조차 알지 못한다. 메시지 송신자는 단지 자신의 요구를 포장해서 전달할 뿐이다.
  • 메시지를 해석하고 그에 반응해서 상태를 변경할지 여부는 전적으로 메시지 수신자의 자율적인 판단에 따른다.
  • 상태를 잘 정의된 행동 집합 뒤로 캡슐화하는 것은 객체의 자율성을 높이고 협력을 단순하고 유연하게 만든다. 이것이 상태를 캡슐화해야 하는 이유다.

식별자

  • 객체가 식별 가능하다는 것은 객체를 서로 구별할 수 있는 특정한 프로퍼티가 객체 안에 존재한다는 것을 의미한다. 이 프로퍼티를 식별자라고 한다.
  • 값과 객체의 가장 큰 차이점은 값은 식별자를 가지지 않지만 객체는 식별자를 가진다는 점이다.
  • 값(value) : 숫자, 문자열, 시간, 날짜 등 변하지 않는 양을 모델링
    • 동등성(equality) : 상태를 이용해 두 값이 같은지 판단할 수 있는 성질
  • 객체 : 시간에 따라 변경되는 상태를 포함하며 행동을 통해 상태를 변경 → 가변 상태(mutable state)
    • 동일성(identical) : 두 객체의 상태가 다르더라도 식별자가 같다면 두 객체를 같은 객체로 판단할 수 있음
📌 식별자란 어떤 객체를 다른 객체와 구분하는 데 사용하는 객체의 프로퍼티다. 값은 식별자를 가지지 않기 때문에 상태를 이용한 동등성 검사를 통해 두 인스턴스를 비교해야 한다. 객체는 상태가 변경될 수 있기 때문에 식별자를 이용한 동일성 검사를 통해 두 인스턴스를 비교할 수 있다.
  • 대부분의 사람들은 값과 객체의 차이점을 혼란스러워 한다.
    • 대부분의 객체지향 언어에서 두 개념 모두 클래스를 이용해 구현되기 때문
    • 오해의 소지를 줄이고자 참조 객체(reference object), 엔티티(entity)는 식별자를 가진 전통적 의미의 객체를 가리킴
    • 값 객체(value object)는 식별자를 가지지 않는 값을 가리킴

정리

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

기계로서의 객체

  • 쿼리(query): 객체의 상태를 조회하는 작업
  • 명령(command): 객체의 상태를 변경하는 작업

기계 은유

  • 기계의 부품은 단단한 금속 외피 안에 감춰져 있기 때문에 분해하지 않는 한 기계의 내부를 직접 볼 수 없다.
  • 사람은 기계의 외부에 부착된 사각형과 원 모양의 버튼을 이용해서만 기계와 상호작용할 수 있다.

IMG_7042

  • 사각형 버튼 : 상태를 변경하는 명령
  • 둥근 버튼: 상태를 조회하는 쿼리
  • 명령과 쿼리는 객체가 외부에 제공하는 행동이라는 점에 주목하라.
  • 여기서 중요한 것은 명령 버튼과 쿼리 버튼 이외의 다른 방법을 통해서는 앨리스 기계를 사용할 수 없다는 것이다. → 캡슐화 강조

행동이 상태를 결정한다

  • 객체지향에 갓 입문한 사람들이 쉽게 빠지는 함정 : 상태를 중심으로 객체를 바라보는 것.
  • 초보자 : 객체에 필요한 상태 먼저 결정 → 상태에 필요한 행동을 결정
  • 고것은 나쁜 설계
    1. 상태를 먼저 결정할 경우 캡슐화가 저해됨
      • 상태가 객체 내부로 캡슐화되지 못하고 공용 인터페이스에 노출될 확률이 높아짐
    2. 객체를 협력자가 아닌 고립된 섬으로 만듬
      • 상태를 먼저 고려하면 협력이라는 문맥에서 멀리 벗어남 → 협력에 적합하지 못한 객체 창조
    3. 객체의 재사용성 저하됨
      • 상태에 초점을 맞춘 객체는 다양한 협력에 참여하기 어려움
  • 협력에 참여하는 훌륭한 객체 시민을 양성하기 위한 가장 중요한 덕목은 상태가 아니라 행동에 초점을 맞추는 것이다.
  • 행동이 상태를 결정한다!

은유와 객체

두 번째 도시전설

  • “객체지향이란 현실 세계의 모방” X
  • 모방과 추상화라는 개념만으로는 현실 객체와 소프트웨어 객체 사이의 관계를 깔끔하게 설명하지 못한다.

의인화

  • 현실 속의 객체와 소프트웨어 객체 사이의 가장 큰 차이점은?
    • 현실 속에서는 수동적인 존재가 소프트웨어 객체로 구현될 때는 능동적으로 변한다는 것 → 의인화

은유

  • 객체지향 분석/설계에 대한 전통적인 조언
    • “현실 세계의 객체를 자세히 관찰하고 그중에서 소프트웨어 객체에 적합한 속성만 추려내라.”
    • 이 조언은 실제적인 도움을 주지 못함
  • 그렇다고 객체지향 세계와 현실 세계 사이에 전혀 상관이 없는 것은 아님.
    • 모방, 추상화가 아니라 다른 관점에서 유사성을 지닌다.
    • 현실 세계와 객체지향 세계를 좀 더 정확히 설명할 수 있는 단어는 은유(metaphor)다.
  • 은유 관계에 있는 실제 객체의 이름을 소프트웨어의 객체의 이름으로 사용하면 표현적 차이를 줄여 소프트웨어의 구조를 쉽게 예측할 수 있다.
  • 은유를 효과적으로 사용할 경우 표현적 차이를 줄일 수 있으며, 이해하기 쉽고 유지보수가 용이한 소프트웨어를 만들 수 있다.

정리

  • 객체지향 설계자로서 우리의 목적은 현실을 모방하는 것이 아니다. 단지 이상한 나라를 창조하기만 하면 된다.
  • 현실을 닮아야 한다는 어떤 제약이나 구속도 없다.