[Book] "객체지향의 사실과 오해" 정리

노션에 적어논 것을 티스토리에 옮기니 마크다운을 지원하지 않아서 글꼴이 이상합니다;

 

아래 링크로 보시면 정상적인 글꼴을 보실 수 있습니다.

www.notion.so/72ef860ed57f4e85a00260193175577f

 

1. 협력하는 객체들의 공동체

• 객체는 실생활을 모방했다고 하면 비유는 쉽지만 옳다고 볼순 없다. 객체 지향은 자기 자신만의 새로운 세계를 설계하고 있는 것이다.
• 객체는 자신의 역할에 대한 책임을 다하기 위해 서로 협력하는 존재이다.
• 객체지향의 핵심은 책임을 수행하는 역할 간의 협력 관계 구축이다. (메시지를 주고 받는 객체들)
  • 이 때 협력에 참여하는 객체의 구현 매커니즘이 클래스일 뿐이다.

2. 이상한 나라의 객체

• 객체 == 상태, 행동, 식별자..
  • 객체의 상태를 구성하는 모든 특징 → 프로퍼티
    • 프로퍼티는 변경되지 않는 '정적'이며 프로퍼티 값은 '동적'이다.
  • 객체의 행동은 상태를 변화시킨다.
    1. 객체 자신의 상태 변경
    2. 행동 내에서 협력하는 다른 객체에 대한 메시지 전송
       • 현실과 객체지향 세계의 차이는 [음료]라는 수동적인 존재가 메시지를 받아 능동적으로(스스로) 음료의 양을 줄여야한다는 점이다.
       • 이 때 송신 객체는 수신 객체가 이를 어떻게 처리했는지 상태에 어떤 변화가 있었는지 알지 못한다. (캡슐화)
  • 식별자란 상태처럼 변화하지 않고 객체가 유일하게 가지고 있는 프로퍼티이다.

행동이 상태를 결정한다.

객체 설계 시에는 필요한 행동을 생각한 후 행동에 따라 적절한 상태를 선택 해야한다. (RDD)

은유와 객체

객체지향 세계는 현실의 모습을 조금 참조해 더 많은 특징과 능력을 보유한 객체들로 새로운 세계를 창조하는 것이다. (현실세계에 대한 모방이 아니다.)

• 그렇다면 객체지향과 현실 세계 사이에는 아무런 관련이 없는가? → (은유)
  • 은유 관계에 있는 실객체의 이름을 소프트웨어 객체의 이름으로 사용하면 객체를 쉽게 이해할 수 있다.
    • 예를 들어, 현실의 전화기를 객체에 묘사하면 이 객체는 전화를 걸고 받을 수 있는 객체구나라고 쉽게 이해할 수 있을 것이다.

이를 통해, 우리는 이해하기 쉽고 유지 보수하기 쉬운 소프트웨어를 만들 수 있다.

3. 타입과 추상화

추상화

어떤 세부사항, 구조를 더 명확하게 이해하기 위해 특정 절차나 물체를 의도적으로 생략하거나 감춤으로써 복잡도를 극복하는 방법

추상화의 두 가지 차원

1. 사물들 간 공통점은 취하고 차이점은 버리는 일반화를 통한 단순화
2. 중요한 부분 강조를 위한 의도적 세부 사항 제거 단순화

개념 (추상화 도구)

공통점을 기반으로 객체들을 묶기 위한 그릇

개념을 이용해서 객체를 분류 할 수 있다.

• 객체란 특정한 개념 을 적용할 수 있는 구체적인 사물
• 개념이 어떤 객체에 적용되면 그 객체를 개념의 인스턴스라고 부른다.

개념의 3가지 관점 (객체의 분류 방식에 대한 지침)

1. 심볼 : 개념의 명칭 → '트럼프'
2. 내연 : 개념의 완전한 정의 → 트럼프는 쉽게 뒤집을 수 있고 납작하고 직사각형이다.
3. 외연 : 개념에 속하는 객체들 → 왕비, 병사 트럼프 등

타입

'개념'은 '타입'

개념 은 타입 이라는 용어의 정의와 완전히 동일하다. 좀 더 공학적인 표현이다.

데이터는 용도와 행동에 따라 '분류'되어야 한다.

• 전통적 데이터 타입 (숫자, 문자, 논리형 데이터 타입)
  • 데이터가 어떻게 사용되며 메모리에서 어떻게 표현되는가?
  • 데이터 타입은 메모리 안 데이터를 분류하기 위해 사용되는 메타 데이터.
    이 분류를 통해 어떤 연산(행동)이 해당 데이터에 수행될 수 있는 지 결정.

객체와 타입 - 행동이 중요시 되는 객체

동일한 타입의 객체는 동일한 행동을 하며 서로 다른 데이터를 가지고 있어도 상관 없다.

또한, 어떻게 내부에서 행동을 처리하든 같은 행동만 하면 된다. (다형성)

즉, 객체의 타입을 결정하는 것은 데이터가 아닌 행동이다!

** 중요 **

다형성 ⇒ 동일한 요청에 대해 서로 다른 방식으로 응답할 수 있는 능력

캡슐화 ⇒ 외부에 행동만을 제공하고 데이터는 행동 뒤로 감춘다.

따라서, 행동에 따라 객체를 분류하기 위해 우리는 외부에 제공하는 행동을 먼저 생각해야만 한다. (책임 주도 설계)

일반화/특수화

이 관계를 결정하는 것은 객체의 상태가 아닌 행동이다.

타입의 목적

• 객체는 시간에 따라 그 상태가 시시각각 변화할 수 있다. (동적)

타입은 이러한 객체를 동일한 행동에 따라 분류 하여 시간과 무관한 정적인 모습으로 만들어준다.

타입은 추상화이다. → 객체의 동적인 특성을 추상화하여 단순화 시킨다.

⇒ 객체의 동적 모델과 정적모델...

클래스

타입을 구현할 수 있는 구현 메커니즘 중 하나

타입은 객체를 분류하기 위해 사용하는 개념... →을 구현하는 구현 매커니즘인 클래스

객체지향에서 중요한 것은 동적으로 변하는 객체의 상태와 상태를 변경하는 행동이다.

4. 역할, 책임, 협력

객체지향에서 중요한 것은 개별 객체가 아니라
객체들 사이에 이뤄지는 협력이다.

객체들 간에 이뤄지는 요청과 응답속에서 협력에 집중하자.

협력

객체들은 (하트 잭의 재판)동일한 목적을 달성하기 위해 서로 협력한다.

객체들은 서로에게 요청하고 응답하게 되는데 알맞은 요청을 받은 객체는 응답할 의무가 있다.
이 요청과 응답은 객체가 수행할 책임을 정의한다.

책임

객체가 어떤 요청에 응답할 의무가 있는 경우 책임을 가진다.

• 책임의 분류
  • 하는 것(doing)
    • 다른 객체 제어, 계산을 하는 것
  • 아는 것(knowing)
    • 관련 객체를 아는 것, 정보를 아는 것, 계산할 수 있는 것을 아는 것

메시지

협력을 위해 한 객체가 다른 객체로 접근할 수 있는 유일한 방법

한 객체가 다른 객체로 하여금 요청을 보내 자신의 책임을 수행하게 함.

역할

한 협력 내에서 동일한 책임의 집합을 수행하는 객체들

서로 다른 협력이 참여하는 객체들을 제외하고 과정이 유사하다면 하나의 협력으로 다뤄보자!

역할은 협력 내에서 다른 객체로 대체할 수 있음을 뜻한다.

즉, 역할을 이용해 협력을 추상화할 수 있다.

(인터페이스로 같은 책임 집합을 만들 수 있다.)

• 역할을 대체하기 위해서..(동일한 역할을 수행한다는 것은..)
  • 대체 가능한 객체가 동일한 책임의 집합을 수행할 수 있다는 뜻이다. (동일한 메시지를 이해할 수 있는 객체)
  • 또한, 객체는 역할보다 더 많은 책임을 수행할 수도 있다

⇒ 역할의 가장 큰 가치는 협력 안에 여러 종류의 객체가 참여할 수 있게 함으로써 협력을 추상화 한다는 점이다!

협력의 추상화 (협력에 여러 종류의 객체가 참여 가능)

역할을 사용하면 협력을 추상화 → 다양한 객체가 협력에 참여할 수 있다.
이는 객체지향 설계의 단순성, 유연성, 재사용성을 향상시킨다.

외부에서 접근 가능한 공용서비스(인터페이스) → 객체의 책임을 지정한다고 볼수 있다.

• 책임은 2가지의 목록이다.
  1. 객체의 외부에 제공해줄 수 있는 정보(아는 것)
  2. 객체가 외부에 제공해줄 수 있는 서비스(하는 것)

흔한 오류

1. 첫번째 선입견은 시스템에 필요한 데이터를 저장하기 위해 객체가 존재한다 이다.
   • 데이터는 객체가 행위를 수행하는데 필요한 재료일뿐 중요한 것은 객체의 행동. 즉, 책임이다.
2. 두번째 선입견은 객체 지향이 클래스와 클래스 간의 관계를 표현하는 정적인 측면 이다.
   • 중요한 것은 협력에 참여하는 동적인 객체이며, 클래스는 단지 구현 메커니즘일 뿐이다.

• 올바른 객체 설계 순서
  1. 협력 설계 (객체들이 주고 받을 요청과 응답의 흐름
  2. 요청과 응답의 흐름 → 객체가 협력에 참여하기 위해 수행해야될 책임 == 행동
  3. 행동을 결정한 후 행동에 필요한 데이터를 결정
  4. 행동과 데이터가 결정되었다면 클래스의 구현 방법 결정

책임-주도 설계(RDD)

• 사용자에게 제공해야 하는 기능인 [시스템 책임] 파악
• 이 책임을 더 작은 책임 단위로 분할
• 분할된 책임을 수행할 수 있는 객체 또는 역할을 찾아 책임을 할당하고 서로 다른 객체가 협력해서 큰 책임을 완성

디자인 패턴

패턴은 특정한 상황에서 설계를 돕기 위해 모방하고 수정할 수 있는 과거의 설계 경험을 뜻한다.

문제가 무엇인지 적용할 수 있는 상황은 무엇인지 반복적으로 일어나는 특정 상황에서 어떤 설계가 왜 효과적인지에 대한 이유 → 패턴

테스트 주도 개발

실패하는 테스트코드를 작성한 후 통과하는 코드를 작성해서 이를 리팩터링 하는 것

다양한 패턴과 객체지향에 대한 깊은 이해가 동반되야 더 큰 효과가 나온다.

5. 책임과 메시지

"훌륭하고 성장가능한 시스템을 만들기 위한 핵심은 모듈 내부의 속성과 행동이 어떤가보다는 모듈이 어떻게 커뮤니케이션 하는가에 달려있다."

• 너무 추상적이지도 않으면서 협력의 의도를 뚜렷하게 표현할 수 있을 정도의 구체성
  • 예) 재판 협력 내에서는 '설명하라'는 너무 추상적이고 '증언하라' 정도가 책임의 자율성에 적합하다.
    '설명하라'? 내 인생을..?뭐를..? → 약간의 뚜렷함이 필요함.
• 객체의 외부와 내부가 메시지를 기준으로 분리된다.

다형성

서로 다른 유형의 객체가 동일한 메시지에 대해 서로 다르게 반응하는 것

객체들이 동일한 메시지를 처리할 경우 서로 다른 메서드를 이용해 메시지를 처리할 수 있는 메커니즘(메시지를 어떻게 처리할 지 선택할 수 있는 능력)

• 다형성을 사용하면 송신자가 수신자의 종류를 모르더라도 메시지를 전송할 수 있다.
  • ⇒ 즉, 다형성은 수신자의 종류를 캡슐화 한다.

유연하고 확장 가능하며 재사용성이 높은 협력

1. 협력의 유연성 (송신자는 수신자가 메시지를 이해한다면 누구라도 상관하지 않는다.) [수신자 변경 용이]
2. 협력 수행 방식의 확장성 (어떻게 책임을 수행할 지 선택할 수 있다.) [수신자 책임 수행 방식 변경 용이]
3. 협력 수행 방식의 재사용성 (다양한 객체들이 역할을 대신할 수 있기에 재사용이 가능하다.) [수신자 추상화]

메시지 중심 - (What/Who 사이클)

객체가 메시지를 선택하는 것이 아닌 메시지가 객체를 선택하게 한다 (메시지 중심 협력 설계를 하자)

• 메시지가 객체(수신자)의 책임을 결정한다.
• 어떤 행위(What)를 수행할 것인지를 결정한 후 누가(Who) 그 행위를 할 것인지를 결정한다.
  • 누가 수행할 지 모르기 때문에 객체 내부 상태를 볼 수 없고 수신자의 캡슐화를 증진시킨다.

객체 인터페이스

어떤 두 객체가 서로 상호작용할 수 있게 이어주는 방법

메시지가 인터페이스를 결정

객체가 다른 객체와 상호작용할 수 있는 유일한 방법은 '메시지 전송'이다.

따라서, 객체의 인터페이스는 객체가 "수신할 수 있는 메시지의 목록"으로 구성된다.

인터페이스와 구현의 분리 원칙

객체를 설계할 때 객체 외부에 노출되는 인터페이스와 객체 내부에 숨겨지는 구현을 명확하게 분리 구분해야한다.

⇒ 이것이 중요한 이유? 소프트웨어하는 항상 변경되기 때문에 변경에 대한 파급효과를 최소화하기 위해서!

객체가 가져야할 상태와 메서드 구현은 객체 내부에 속하며 이 부분을 수정해도 객체 외부에 영향을 미치지 않는다.

책임의 자율성이 협력의 품질을 결정

1. 자율적인 책임은 협력을 단순하게 만든다.
   • 자율적인 책임은 세부사항은 제외시키며 중요한 의도만을 표현하여 책임을 추상화한다.
     • 어떻게 할 지 정해주지 말고, 무엇(What)을 원하는지 결정하자.
2. 자율적인 책임은 객체의 외부와 내부를 명확하게 분리한다.
   • 객체는 협력 참여를 위해 외부 노출 부분과 내부 구현 부분을 나눈다.
     • 객체가 캡슐화 되어 인터페이스와 구현이 분리된다.
3. 책임이 자율적일 경우 내부 방식을 변경하더라도 외부에 영향을 미치지 않는다.
   • 구체적인 방식을 정하지 않고 '무엇을' 하는지에 대한 책임만 있으므로 어떻게 할지는 자유이다.
   • 변경의 파급효과가 객체 내부로 캡슐화되어 두 객체간의 결합도가 낮아진다.
4. 자율적인 책임은 협력의 대상을 다양하게 선택할 수 있는 유연성을 제공한다.
   • 이 객체말고 다른 객체를 선택할 수 있다. (재사용성 증진)
5. 객체의 역할을 이해하기 쉽다.
   • 협력 안에서 맡은 책임이 자율적일수록 객체의 존재 이유가 명확하다.
   • 책임이 자유로울수록 객체의 응집도가 높다.

결론, 책임이 자율적일수록 협력과 객체의 '추상화'되며, '응집도'가 높아지고 '결합도'가 낮아지며 '캡슐화가 증진되고 '인터페이스와 구현의 분리'가 명확해지고 설계의 '유연성'과 '재사용성'이 향상된다.

객체지향의 강력함은 ⇒ 책임의 자율화(우리가 만드는 메시지가 결정함) 에서 나온다!!

6. 객체 지도

지도의 핵심은 기능이 아니라 구조를 기반으로 모델을 구축해 좀 더 범용적이고 이해하기 쉽고 변경에 안정적을 만들었다는 것이다.

객체 지향도 자주 변경되는 기능이 아닌 안정적인 구조를 기반으로 시스템을 분할하는 방법을 이용해 역할, 책임, 협력을 구성하는 것이 좋다.

• 예외없이 변경되는 요구사항..
  • 설계가 중요한 이유는 변경을 피할 수 없기 때문이다.
  • 따라서, 설계자는 기능을 제공하는 동시에 변경에 대처할 수 있는 안정적인 구조를 제공해야 한다.
  • 어떤 변경이 생길 지 미리 예측하는 것은 불가능하다. 따라서, 그냥 변경을 쉽게 비용을 낮추게 해야한다.
• 기능 분해 (BAD)
• → 시스템의 기능을 더 작은 기능으로 분해하고 각 기능이 서로 밀접해 변경 발생 시 전체에 영향..
• 책임 분배 (GOOD)

    기능이 더 작은 책임으로 분할되고 적절한 객체에게 분배됨.

  만약, 기능이 변경되더라도 객체 간의 구조는 그대로 유지! (변경을 수용할 수 있는 유연한 소프트웨어)
• → 객체의 구조에 집중하며 기능은 구조를 따르게 만든다.

유스케이스 모델링 : 기능을 수집하고 표현하기 위한 기법

도메인 모델링 : 구조를 수집하고 표현하기 위한 기법

도메인 (구조)

사람들이 관심을 가지고 있는 대상 분야

• 도메인 모델디자인 모델 - 시스템 이미지 - 사용자 모델 (이를 모두 포함한 도메인 모델)
• → 이해관계자들이 바라보는 멘탈 모델

도메인 모델을 기반으로 설계하고 구현함으로써 사용자가 도메인을 바라보는 관점을 그대로 코드에 반영할 수 있게 한다. (코드에 도메인 구조가 녹아있기 때문에 이해와 수정이 쉬워진다.)

결국, 사용자 모델과 설계자 모델의 차이를 줄여 시스템 이미지를 생성하도록 만든다.

⇒ 도메인 모델이 도메인과 관련된 중요한 개념과 관계를 보여주지만 실제로는 기능도 중요하다.
우리는 이러한 기능을 기술한 정보가 필요하다. 때문에 유스케이스 기법을 사용한다.

유스케이스 (기능)

기능적 요구사항을 사용자의 목표를 중심으로 묶은 것

7. 함께 모으기

• 개념관점
  • 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현함.
  • 도메인은 사용자들이 관심을 가지고 있는 특정 분야나 주제를 뜻한다.
  • 사용자가 도메인을 바라보는 관점. 실제 도메인의 규칙과 제약을 가장 유사하게 반영.
• 명세관점
  • 사용자의 영역인 도메인을 벗어나 → 개발자의 영역인 소프트웨어에 초점.
  • 도메인의 개념이 아닌 소프트웨어 안의 객체들의 책임에 초점
  • 객체가 협력을 위해 '무엇'을 할 수 있는가!?
• 구현관점
  • 객체들이 책임을 수행하는 데 필요한 동작하는 코드 작성에 초점
  • 객체의 책임을 '어떻게' 수행할 것인가에 초점.

⇒ 클래스가 은유하는 개념은 도메인 관점.
⇒ 클래스의 공용 인터페이스는 명세 관점.
⇒ 클래스의 속성과 메서드는 구현 관점.

커피를 주문하는 객체들의 협력 관계 설계

1. 필요한 모든 객체를 말해보자.
   • 손님, 메뉴판, 메뉴 항목, 바리스타, 커피 객체들
2. 각 객체들 간의 관계를 살펴보자.
   • 손님은 커피를 주문하기 위해 메뉴를 알아야한다. → 손님 - 메뉴판 (관계 존재)
   • 손님은 선택한 메뉴를 바리스타에게 주문해야한다. → 손님 - 바리스타 (관계 존재)
   • 바리스타는 커피를 제조한다. → 바리스타 - 커피 (관계)
3. 각 객체간 관계가 '어떤' 관계인가.
   • 메뉴판 과 메뉴 항목은 포함(containment)관계 (메뉴 항목이 메뉴판의 일부..마름모로 표시)
   • 메뉴판 과 손님은 연관(association)관계

이를 통해 도메인 모델 뽑아낼 수 있음

⇒ 소프트웨어가 대상으로 하는 영역인 도메인을 단순화해서 표현한 모델 == 도메인 모델!!

도메인 모델의 각 객체에 책임 할당

1. 메시지가 객체를 선택! (메시지 == 커피를 주문하라!)
   • 메시지는 인터페이스 메서드 이름으로 볼 수 있고 인자를 가진다.
2. 수신할 객체 선택. (손님 == 책임을 수행할 객체)
   • 객체이름을 'A'라고 짓는 것보다 '손님'이라고 짓는 것이 객체의 책임과 상태를 쉽게 유추할 수 있게한다. (은유)
   • 손님이 스스로 할 수 없는 일은 무엇인가?
3. 객체가 스스로 처리할 수 없는 일은 다른 객체에게 책임을 할당해서 처리한다.
   • 메뉴 항목은 메뉴판이 찾아줄 책임이 있다.
   • 메뉴 항목에 대한 제조는 바리스타에게 책임이 있다.

각 객체에게 책임을 할당함으로써 협력에 필요한 객체의 종류와 책임, 메시지에 대한 윤곽을 잡을 수 있다.

인터페이스 정리하기

위의 작업을 통해 우리는 객체들의 인터페이스를 얻었다.

객체가 수신한 메시지가 곧 객체 자신의 인터페이스가 된다.

따라서, 협력을 떼고 수신 가능한 메시지만 모아 놓고 보면 객체의 인터페이스가 된다는 뜻이다.

구현하기

손님은 메뉴를 알기 위해 메뉴판 객체에 대한 참조를 알아야하고 커피 주문을 하기 위해 바리스타 객체에 대한 참조를 알아야만한다.

따라서, 손님은 "주문하라"라는 책임을 할당 받을 때 메서드의 인자로 메뉴 객체와 바리스타 객체를 전달 받아서 해결한다. (다른 방법도 가능)

이렇게 필요한 객체에 대한 참조를 알게되면 남은 것은 메서드를 "구현"하는 것이다.

⇒ 이렇게 모든 설계를 완료하면 클래스 다이어그램을 나타낼 수 있다.

하지만, 중요한 것은 설계를 간단하게 끝내고 구현에 빨리 돌입하는 것이다. 그 후 식별되는 것을 수정한다.

도메인 개념을 참조하는 이유

1. 메시지를 수신할 객체를 선택할 때 사용.
2. → 도메인 개념 안에서 가장 적절한 객체를 선택하는 것은 도메인에 대한 일반 지식을 통해 코드의 구조와 의미를 쉽게 유추할 수 있게 한다.
3. 변경에 유연하게 대처하기 위해

→ 여러개의 클래스를 기능으로 분할, 클래스 안에서 인터페이스와 구현을 나누는 이유는??

• 변경이 발견했을 때 코드를 좀 더 수월하게 수정하기 위해서이다!

소프트웨어 클래스가 도메인 개념을 따르면 변경에 쉽게 대응할 수 있다.!

인터페이스와 구현을 분리하라!

명세관점과 구현 관점을 분명히 구분해라.

명세관점은 클래스의 안정적인 측면, 구현 관점은 클래스의 불안정인 측면.

인터페이스가 구현 세부사항을 노출하게 되면 작은 변동에도 전체 협력이 요동친다!!!