Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2장 이상한 나라의 객체 #196

Closed
Tracked by #40
fkdl0048 opened this issue Dec 10, 2023 · 0 comments
Closed
Tracked by #40

2장 이상한 나라의 객체 #196

fkdl0048 opened this issue Dec 10, 2023 · 0 comments

Comments

@fkdl0048
Copy link
Owner

fkdl0048 commented Dec 10, 2023

2장 이상한 나라의 객체

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

객체지향과 인지 능력

책에 나온 실험은 인간이 선천적으로 타고난 인지 능력을 이용해 세상에 존재하는 다양한 객체를 식별하고 분류함으로써 세상을 이해한다는 사실을 보여준다.

많은 사람들이 객체지향을 직관적이고 이해하기 쉬운 패러다임이라고 말하는 이유는 객체지향이 세상을 자율적이고 독립적인 객체들로 분해할 수 있는 인간의 기본적인 인지 능력에 기반을 두고 있기 때문이다.

실제로 객체지향에 대해 공부를 시작한 초창기엔 행동이나 사물에 대해서 상상로 설계해보는 것을 많이 했다.

세상을 더 작은 객체로 분해하는 것은 본질적으로 세상이 포함하고 있는 복잡성을 극복하기 위한 인간의 작은 몸부림이다.

인간은 좀 더 단순한 객체들로 주변을 분해함으로써 자신이 몸담고 있는 세상을 이해하려고 노력한다.

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

객체지향 패러다임의 목적은 현실세계를 모방하는 것이 아니라 현실 세계를 기반으로 새로운 세계를 창조하는 것이다.

실행 중인 객체지향 애플리케이션의 내부를 들여다볼 수 있다면 겉으로는 우리가 알고 있는 세계와 유사해 보이지만 본질적으로는 매우 이질적인 모습을 지닌 세계와 마주치게 될 것이다.

아마 그 세계는 마치 토끼를 뒤쫓던 한 소녀가 경험한 이상한 나라만큼이나 낮설고 기묘할 것이다.

객체, 그리고 이상한 나라

이상한 나라의 앨리스

아마 이상한 나라의 앨리스를 모르는 사람은 없을 것이다.

책 속 앨리스처럼 상상하진 않았지만..(거의 잔혹동화..)

갑자기 그림을 보니 생각난 게임으로 앨리스 매드니스 리턴즈라는 게임이 생각났다.

그림의 앨리스와 비슷한 분위기의 게임인데 상당히 잘 만든 게임..

앨리스 객체

앨리스의 키를 변화시키는 것은 앨리스의 행동이다.

앨리스가 하는 행동에 따라 앨리스의 상태가 변화한다.

앨리스의 상태를 결정하는 것은 행동이지만 행동의 결과를 결정하는 것은 상태이다. (행동의 결과는 상태에 의존적)

동화를 토대로 앨리스를 객체로 생각하여 특징을 정리하면 다음과 같다.

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

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

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

다른 사물과 구분할 수 있으며, 생성 시점을 알 수 있고, 독립적인 하나의 단위로 인식할 수 있는 모든 사물은 객체다.

객체의 다양한 특성을 효과적으로 설명하기 위해서는 객체를 상태, 행동, 식별자를 지닌 실체로 보는 것이 가장 효과적이다.

앨리스는 상태, 행동, 식별자를 지닌 실체다.

그리고 소프트웨어 안에서 창조되는 객체도 상태, 행동, 식별자를 지닌다.

객체란, 식별 가능한 개체 또는 사물이다. 객체는 자동차처럼 만질 수 있는 구체적인 사물일 수도 있고, 시간처럼 추상적인 개념일 수도 있다. 객체는 구별 가능한 식별자, 특징적인 행동, 변경 가능한 상태를 가진다. 소프트웨어 안에서 객체는 상태와 실행 가능한 코드를 통해 구현된다.

상태

왜 상태가 필요한가?

객체가 주변 환경과의 상호작용에 어떻게 반응하는가는 그 시점까지 객체에 어떤 일이 발생했느냐에 좌우된다.

엘레베이터가 움직이기 위해서는 먼저 원하는 층의 버튼을 눌러야 한다.

앨리스가 문을 통과하기 위해서는 부채질을 하거나 버섯의 한쪽을 먹어 문을 통과하기에 충분할 정도로 자신의 키를 작게 줄여야만 한다.

따라서 문을 통과한다는 행동의 결과를 예상할 수 있는 한 가지 방법은 앨리스가 과거에 케이크나 버섯을 먹었던 적이 있는지를 살펴보는 것이다.

그러나 이 방법은 앨리스가 과거에 했던 모든 행동을 기억해야만 가능하기 때문에 행동의 결과를 설명하는 것을 매우 어렵게 만든다.

일반적으로 과거에 발생한 행동의 이력을 통해 현재 발생한 행동의 결과를 판단하는 방식은 복잡하고 번거로우며 이해하기 어렵다.

따라서 인간은 행동의 과정과 결과를 단순하게 기술하기 위해 상태라는 개념을 도입했다.

상태를 이용하면 과거의 모든 이력을 설명하지 않고도 행동의 결과를 쉽게 예측하고 설명할 수 있다.

앨리스의 경우 키와 문의 높이라는 두 가지 상태만 알면 문을 통과하는 행동의 결과를 쉽게 예측할 수 있는 것이다.

상태와 프로퍼티

앨리스는 객체다.

앨리스의 키를 줄이기 위해 사용하는 음료, 케이크, 부채, 버섯, 토끼, 문 모두 객체다.

이들은 뚜렷한 경계를 가지며 식별 가능하고 상태와 행동을 지니고 있다.

그러나 세상에 존재하는 모든 것들이 객체인 것은 아니다.

분명하게 인식할 수 있음에도 객체의 영역에 포함시킬 수 없는 것들도 존재한다.

앨리스의 '키'와 '위치'는 객체가 아니다.

음료와 케이크의 '양'도 객체가 아니다.

숫자, 문자열, 양, 속ㄷ, 시간, 날짜, 참/거짓과 같은 단순한 값들은 객체가 아니다.

C#에선 문자열은 객체이자만. 여기서 말하는 개념이 그 개념을 말하는 것이 아니라는 것에 집중!

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

앨리스가 음료를 들고 있는지 여부는 앨리스라는 객체가 음료라는 객체와 연결돼 있는지 여부로 표현할 수 있다.

결론적으로 모든 객체의 상태는 단순한 값과 객체의 조합으로 표현할 수 있다.

이때 객체의 상태를 구성하는 모든 특징을 통틀어 객체의 프로퍼티라고 한다.

앨리스의 경우 키, 위치, 음료가 앨리스의 프로퍼티가 된다.

일반적으로 프로퍼티는 변경되지 않고 고정되기 때문에 '정적'이다.

반면 프로퍼티 값은 시간이 흐름에 따라 변경되기 때문에 '동적'이다.

객체와 객체 사이의 의미 있는 연결을 링크라고 한다.

객체와 객체 사이에는 링크가 존재해야만 요청을 보내고 받을 수 있다.

즉, 객체의 링크를 통해서만 메시지를 주고받을 수 있다.

객체를 구성하는 단순한 값은 속성이라고 한다.

앨리스의 키와 위치는 단순한 값으로 표현되기 때문에 속성이다.

따라서 객체의 프로퍼티는 단순한 값인 속성과 다른 객체를 가리키는 링크라는 두 가지 종류의 조합으로 표현할 수 있다.

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

객체는 자율적인 존재라는 점을 명심하라.

객체지향의 세계에서 객체는 다른 객체의 상태에 직접적으로 접근할 수도, 상태를 변경할 수도 없다.

자율적인 객체는 스스로 자신의 상태를 책임져야 한다.

외부의 객체가 직접적으로 객체의 상태를 주무를 수 없다면 간접적으로 객체의 상태를 변경하거나 조회할 수 있는 방법이 필요하다.

이때 사용하는 것이 행동이다.

행동은 다른 객체로 하여금 간접적으로 객체의 상태를 변경하는 것을 가능하게 한다.

객체지향의 기본 사상은 상태와 상태를 조작하기 위한 행동을 하나의 단위로 묶는 것이라는 점을 기억하라.

객체는 스스로의 행동에 의해서만 상태가 변경되는 것을 보장함으로써 객체의 자율성을 유지한다.

행동

상태와 행동

객체의 상태는 저절로 변경되지 않는다.

객체의 상태를 변경하는 것은 객체의 자발적인 행동뿐이다.

앨리스의 키가 작아진 이유는 앨리스가 음료를 마셨기 때문이다.

객체의 행동에 의해 객체의 상태가 변경된다는 것은 행동이 부수 효과를 초래한다는 것을 의미한다.

앞에서 말했듯이 객체의 행동은 객체의 상태를 변경시키지만 행동의 결과는 객체의 상태에 의존적이다.

따라서 상태와 행동 사이에는 다음과 같은 관계가 있음을 알 수 있다.

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

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

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

어떤 객체도 섬이 아니다.
: 켄트 벡

객체는 자신에게 주어진 책임을 완수하기 위해 다른 객체를 이용하고 다른 객체에게 서비스를 제공한다.

객체는 다른 객체와 적극적으로 상호작용하며 '협력하는 객체들의 공동체'에 참여하기 위해 노력한다.

객체가 다른 객체와 협력하는 유일한 방법은 다를 객체에 요청을 보내는 것이다.

객체가 다른 객체와 메시지를 통해서만 의사소통할 수 있다는 것을 기억하라.

객체가 어떤 행동을 하도록 만드는 것은 객체가 외부로부터 수신한 메시지다.

객체는 수신된 메시지에 따라 적절히 행동하면서 협력에 참여하고 그 결과로 자신의 상태를 변경한다.

객체는 협력에 참여하는 과정에서 자기 자신의 상태뿐만 아니라 다른 객체의 상태 변경을 유발할 수도 있다.

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

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

상태 캡슐화

현실세계와 객체지향 세계의 중요한 차이점은 현실 속 앨리스는 스스로 음료를 마시는 능동적인 존재지만 음료로는 아무것도 할 수 없는 수동적인 존재다.

현실세계라면 음료의 양을 줄여 상태를 변경시키는 주체는 음료를 목 안으로 밀어 넣은 앨리스가 될 것이다.

그러나 객체지향의 세계에서 모든 객체는 자신의 상태를 스스로 관리하는 자율적인 존재다.

음료객체의 양을 줄이는 것은 음료 자신이어야 한다.

앨리스는 단지 음료에게 자신이 음료를 마셨다는 메시지를 전달할 수 있을 뿐이다.

앨리스가 음료를 마시는 행동은 앨리스 자신의 키를 작게 만든다.

따라서 앨리스 자신의 상태를 변경한다.

메시지를 앨리스에게 전송하는 객체이건 음료에게 메시지를 전송하는 앨리스 객체이건 메시지 송신자는 수신자의 상태 변경에 대해서는 전혀 알지 못한다.

이것이 캡슐화가 의미하는 것이다.

객체가 외부로 노출하는 것은 행동뿐이며, 상태를 캡슐에 감춰둔 채 외부로 노출하지 않는다.

상태를 외부에 노출시키지 않고 행동을 경계로 캡슐화하는 것은 결과적으로 객체의 자율성을 높인다.

왜 캡슐화해야 하는가? 에대한 답변

식별자

객체란 인간의 인지 능력을 이용해 식별 가능한 경계를 가진 모든 사물을 의미한다.

식별 가능하다는 것은 객체를 서로 구분할 수 있는 특정한 프로퍼티가 객체 안에 존재한다는 것을 의미한다.

이 프로퍼티를 식별자라고 한다. (모든 객체는 식별자를 가지며 이를 이용해 객체를 구분한다.)

모든 객체가 식별자를 가진다는 것은 단순한 값들은 식별자를 가지지 않는다는 것을 의미한다.

값과 객체의 가장 큰 차이점은 값은 식별자를 가지지 않지만 객체는 식별자를 가진다는 점이다.

그리고 시스템을 설계할 때는 이런 단순한 값과 객체의 차이점을 명확하게 구분하고 명시적으로 표현하는 것이 매우 중요하다.

값은 숫자, 문자열, 날짜, 시간, 금액 등과 같이 변하지 않는 양을 모델링한다.

흔히 값의 상태는 변하지 않기 때문에 불변 상태를 가진다고 말한다.

값의 상태가 같으면 두 인스턴스는 동일한 것으로 판단하고 상태가 다르면 두 인스턴스는 다른 것으로 판단한다.

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

상태를 이용해 동등성을 판단할 수 없는 이유는 값의 상태가 변하지 않기 때문이다.

객체는 시간에 따라 변경되는 상태를 포함하며, 행동을 통해 상태를 변경한다.

따라서 객체는 가변 상태를 가진다.

타입이 같은 두 객체의 상태가 완전히 똑같더라도 두 객체는 독립적인 별개의 객체로 다뤄야 한다.

어린 시절의 나와 지금의 나는 동일인물이지만 상태는 다르다.

객체 역시 사람과 유사하게 상태와 무관하게 두 객체를 동일하거나 다르다고 판단할 수 있는 프로퍼티를 가진다.

두 객체의 상태가 다르더라도 식별자가 같다면 두 객체를 같은 객체로 판단할 수 있다.

이 처럼 식별자를 기반으로 객체가 같은지 판단할 수 있는 성질을 동일성이라고 한다.

상태를 기반으로 객체의 동일성을 판단할 수 없는 이유는 시간이 흐름에 따라 객체의 상태가 변하기 때문이다.

식별자란 어떤 객체를 다른 객체와 구분하는 데 사용하는 객체의 프로퍼티다. 값은 식별자를 가지지 않기 때문에 상태를 이용한 동등성 검사를 통해 두 인스턴스를 비교해야 한다. 객체는 상태가 변경될 수 있기 때문에 식별자를 이용한 동일성 검사를 통해 두 인스턴스를 비교할 수 있다.

객체 식별자의 개념은 상속, 캡슐화, 다형성과 같은 좀 더 두드러진 개념에 비해 간과하기 쉽다.

그러나 식별자는 객체지향 패러다임의 표현력을 높이는 데 중요한 역할을 한다.

지금까지 다룬 객체의 특성을 다시한번 요약해보면 다음과 같다.

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

기계로서의 객체

객체지향 세계를 창조하는 개발자의 주된 업무는 객체의 상태를 조회하고 객체의 상태를 변경하는 것이다.

일반적으로 조회하는 작업을 쿼리라고 하고 객체의 상태를 변경하는 작업을 명령이라고 한다.

간단한 예시로 블랙박스나 티비의 동작에 대해서 내부 동작을 모르고 버튼을 누르는 사람의 예시이다.

앨리스 객체를 3D형태의 디바이스로 객체화한 모습을 보면 이해가 쉽다.

상태를 조회하고, 상태를 변경하는 명령을 수행한다.

버튼을 눌러서만 상태에 접근할 수 있다는 점을 기억해라

상태와 형태까지 동일하지만 둘은 다른 객체다.

행동이 상태를 결정한다

객체지향에 갓 입문한 사람들이 가장 쉽게 빠지는 함정은 상태를 중심으로 객체를 바라보는 것이다.

초보자들은 먼저 객체에 필요한 상태가 무엇인지를 결정하고 그 상태에 필요한 행동을 결정한다.

앨리스 객체를 설계할 때 초보자는 앨리스 객체에 필요한 상태가 무엇인지를 찾고 키와 위치를 앨리스에 추가한다. 그러고 나서야 키와 위치를 변경하거나 조회할 수 있는 행동이 무엇인지 고민한다.

상태를 먼저 결정하고 행동을 나중에 결정하는 방법은 설계에 나쁜 영향을 끼친다.

첫째, 상태를 먼저 결정할 경우 캡슐화가 저해된다.

상태에 초점을 맞출 경우 상태가 객체 내부로 깔끔하게 캡슐화되지 못하고 공용 인터페이스에 그대로 노출되어버릴 확률이 높아진다.

둘째, 객체를 협력자가 아닌 고립된 섬으로 만든다.

객체가 필요한 이유는 애플리케이션의 문맥 내에서 다른 객체와 협력하기 위해서다.

불행하게도 상태를 먼저 고려하는 방식은 협력이라는 문맥에서 멀리 벗어난 채 객체를 설계하게 함으로써 자연스럽게 협력에 적합하지 못한 객체를 창조하게 된다.

셋째, 객체의 재사용성이 저하된다.

객체의 재사용성은 다양한 협력에 참여할 수 있는 능력에서 나온다.

상태에 초점을 맞춘 객체는 다양한 협력에 참여하기 어렵기 때문에 재사용성이 저하될 수밖에 없다.

협력에 참여하는 훌룡한 객체 시민을 양성하기 위한 가장 중요한 덕목은 상태가 아니라 행동에 초점을 맞추는 것이다.

객체는 다른 객체와 협력하기 위해 존재한다.

객체의 행동은 객체가 협력에 참여하는 유일한 방법이다.

설계자로서 우리는 협력의 문맥에 맞는 적절한 행동을 수행하는 객체를 발견하거나 창조해야 한다.

객체의 적합성을 결정하는 것은 상태가 아니라 행동이다.

객체지향 설계는 애플리케이션에 필요한 협력을 생각하고 협력에 참여하는 데 필요한 행동을 생각한 후 행동을 수행할 객체를 선택하는 방식으로 수행된다.

앞서 커피 공화국을 객체지향 설계의 관점에서 다시 살펴보자.

커피를 손님이 받기 위해서 이뤄지는 협력은 다음과 같다.

1. 손님이 주문한다.
2. 캐시어는 주문을 받는다.
3. 캐시어는 바리스타에게 주문을 전달한다.
4. 바리스타는 커피를 만든다.
5. 바리스타는 커피를 캐시어에게 전달한다.
6. 캐시어는 커피를 손님에게 전달한다.

위와 같은 협력을 통해 커피를 주문하고 받는다.

위 협력에 참여하기 위한 행동은 다음과 같다.

손님 : 주문한다.
캐시어 : 커피 주문을 받는다. 커피 주문을 전달한다.
바리스타 : 커피를 만든다.

위 협력에 참여하기 위한 객체는 다음과 같다.

손님, 캐시어, 바리스타

위 행동에 필요한 상태를 추출한다.

손님 : 원하는 커피
캐시어 : 주문받은 커피
바리스타 : 만들어야 할 커피, 자신만의 레시피에 필요한 재료

위 개념으로 간단한 예제 프로그램을 만들어봐도 좋을 듯하다.

개인적인 생각이지만 요구사항이나 도메인이 예제와 같이 간단하다면 이를 설계하기 위해 객체지향으로 굳이 가지않고 구조적 프로그래밍으로 3가지 메서드를 통해 커피숍을 만들 수도 있을 것 같다. (메서드 3개로)

협력 안에서 객체의 행동은 결국 객체가 협력에 참여하면서 완수해야 하는 책임을 의미한다.

따라서 어떤 책임이 필요한가를 결정하는 과정이 전체 설계를 주도해야 한다.

이 책에선 책임-주도 설계(Responsibility-Driven Design)를 통해 문맥 안에서 객체의 행동을 생각하도록 도움으로써 응집도 높고 재사용 가능한 객체를 만들 수 있게 한다.

행동이 상태를 결정한다.

은유와 객체

두 번째 도시전설

두 번째 도시전설은 '객체지향이란 현실 세계의 모방'이라는 것이다.

객체지향을 현실 세계의 모방이라고 보는 관점은 객체지향 분석/설계란 현실 세계에 존재하는 다양한 객체를 모방한 후 필요한 부분만 취해 소프트웨어 객체로 구현하는 과정을 설명한다.

흔히 객체지향을 현실 세계의 추상화라고 한다.

여기서 추상화란 실제의 사물에서 자신이 원하는 특성만 취하고 필요 없는 부분을 추려 핵심만 표현하는 행위를 말한다.

이런 관점의 중심에는 객체지향 애플리케이션을 분석하고 설계하고 구현하기 위해서는 현실 세계를 면밀히 관찰하고 그 안에 존재하는 실제 객체들의 특징을 감추리고 요약해서 소프트웨어 객체로 추상화할 수 있는 능력이 중요하다는 생각이 자리 잡고 있다.

그러나 계속 강조하는 객체지향은 현실 세계의 모방이 아니다. 새로운 세계의 창조다.

의인화

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

소프트웨어 객체를 창조할 때 결코 현실 세계를 모방하지 않는다.

현실 객체가 가지지 못하는 추가적인 능력을 보유하게 된다.

현실 속의 카드는 스스로 뒤집을 수 없다.

이러한 특징을 의인화라고 한다.

은유

객체지향 분석/설계에 대한 전통적인 조언은 현실 세계의 객체를 자세히 관찰하고 그중에서 소프트웨어 객체에 적합한 속성만 추려내라는 것이다.

위와 같은 전통적인 조언은 개발에 실제적인 도움이 되지 못한다.

모방같은 단어보다 좀 더 명확하게 설명할 수 있는 은유가 적합하다.

은유란 실제로는 적용되지 않는 한 가지 개념을 이용해 다른 개념을 서술하는 대화의 한 형태다.

'시간은 돈이다.'
: 벤저민 프랭클린

이 같은 관계는 객체지향적 모델링에서 발견되는 현실 객체와 소프트웨어 객체의 관계와 일치한다.

은유는 표현적 차이또는 의미적 차이라는 논점과 관련성이 깊다.

은유 관계에 있는 실제 객체의 이름을 소프트웨어 객체의 이름으로 사용하면 표현적 차이를 줄여 소프트웨어 구조를 쉽게 예측할 수 있다.

이상한 나라를 창조하라

우리는 현실세계를 만드는 것이 아니다. (만들 수 없다. 모방도 불가능하다. 추상적 모방만 흉내낼뿐)

그림과 같이 현실 속 객체를 바탕으로 은유를 통해 이상한 나라의 객체를 묘사한다.

느낀점

확실히 한국분이 쓴 책이라 오역이나 오용될 만한 부분이 없어서 좋았다.

객체지향 사고프로세스 책에선 좀 더 코드에 가까웠다면 이 책은 객체지향 설계 철학에 가깝다.

논의사항

  • 객체지향이 항상 정답일까요?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

No branches or pull requests

1 participant