객체지향 설계 개념

객체지향의 목표는 실세계를 모방하는 것이 아니다.

실세계를 추상화하고 은유하여 새로운 세계를 창조하는 것이다.

실세계에 대한 비유는 객체지향의 다양한 측면을 이해하는데 도움이 된다

1. 객체를 스스로 생각하고 결정하는 현실세계의 사물에 비유하는 것은 상태와 행위를 ‘캡슐화’하는 객체의 ‘자율성’을 잘 설명

2. 현실의 암묵적인 약속, 명시적 계약을 기반으로 협력하여 목표를 달성하는 과정은 ‘메시지’를 주고 받으며,  ‘협력’하는 객체들의 관계를 잘 설명

 

설계는 간단히 끝내고 빨리 구현에 돌입하라.
실제 코드를 작성해가면서 협력의 전체적인 밑그림을 그리면서 수정해 나가라.
사람의 인지능력 한계로 인해 설계를 완벽히 끝내고 코드 작성을 하겠다는 어려운 일이다.

 

객체지향의 본질

 1. 시스템은 상호협력하는 자율적인 객체들의 공동체이다.

 2. 자율적인 객체란 상태와 행위를 지니며 스스로 자기 자신의 책임을 지는 객체

 3. 객체는 협력 내에서 정해진 역할을 수행, 역할은 관련된 책임의 집합이다.

 4. 객체는 협력을 위해 메시지를 전송하고, 메시지를 수신한 객체는 메시지 처리를 위한 적합한 메서드(구현)를 자율적으로 선택

 

클래스(Class)

 - 객체지향의 핵심은 클래스가 아님, 클래스는 협력에 참여하는 객체를 만드는 구현 메커니즘일 뿐(타입을 구현하는 보편적인 방법)

 - 클래스의 정적관계가 아닌, 메시지를 주고 받는 객체들의 동적 관계가 중요

 

객체

 - 인간이 분명하게 인지하고 구별할 수 있는 개체 또는 사물. 자동차처럼 만질 수 있는 구체적인 사물일 수도 있고, 시간처럼 추상적인 개념일 수도 있음

- 객체는 구별 가능한 식별자, 특징적인 행동, 변경 가능한 상태를 가짐

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

- 객체지향 설계는 '행동'이 상태를 결정 : 시스템에 필요한 협력을 생각 -> 협력에 필요한 행동 결정 -> 행동을 수행할 객체 선택 -> 행동에 필요한 상태 결정

 1. 상태: 특정 시점에 객체가 가지고 있는 정보의 집합. 객체의 프로퍼티는 단순값과 다른객체를 참조하는 링크로 구성

 2. 행동: 외부요청에 응답하기 위해 동작하고 반응하는 활동. 행동의 결과로 자신의 상태변경이나 다른 객체에게 메시지 전달 가능. 외부에 가시적

 3. 식별자: 어떤 객체를 다른 객체와 구분하는데 사용하는 객체의 프로퍼티. 객체는 시간에 따라 상태가 변경되기 때문에 식별자를 이용한 동일성 검사로 인스턴스 비교.

 

타입과 추상화

 1. 추상화: 복잡성을 이해하기 쉬운 수준으로 단순화하는 것

    - 사물간의 공통점은 취하고, 차이점은 버리는 일반화를 통해 단순화

    - 중요한 부분을 강조하기 위해 불필요한 부분을 제거하는 단순화

    -개념: 공통점을 기반으로 객체들을 묶기 위한 그릇(ex. 자동차, 비행기 등 구체적인 객체의 명이 아닌 묶음의 의미)

            '심볼: 개념을 가리키는 명칭(ex. 트럼프)

            '내연: 개념의 정의(ex. 몸이 납작, 손발이 네모 모서리에 달려 있음 등)

            '외연: 개념에 속하는 모든 객체의 집합(ex.하트왕, 하트 여왕, 병사 등)   

    - 분류: 객체에 특정한 개념을 적용하여 그 개념의 외연에 포함하는 작업

    - 추상화 방법

       1. 분류와 인스턴스화: 개념,타입을 적용. (자동차 - A사 자동차,B사 자동차)

       2. 일반화와 특수화: is-a규칙. (운송수단 - 자동차, 자전거, 비행기)

       3. 집합과 분해: 복잡성은 연쇄적인 계층 형태를 가짐, (자동차 - 엔진, 차체, 타이어)

 

 2. 타입: 컴퓨터 공학에서의 개념(개념과 동일함)

    * ‘데이터타입: 메모리 안에서 저장된 데이터의 종류를 분류하는데 사용하는 메모리집합에 관한 메타데이터.

      데이터의 종류는 어떤 연산을 수행할 수 있는지에 따라 구분(ex. +, -, 문자열, true/false 연산 등)

      타입의 데이터를 메모리에 어떻게 표현하는지 외부로부터 감춰 짐

    - 객체의 타입을 결정(분류)하는 것은 객체의 ‘행동' 뿐이다. 객체의 데이터, 상태는 아무런 영향도 미치지 않는다

    - 타입과 타입사이에는 일반화(슈퍼타입)/특수화(서브타입) 관계가 존재 가능(특수화는 일반화의 모든 행위를 포함하고 자신만의 행위도 가짐)

    - 타입을 사용하는 이유는 시간에 따라 동적으로 변하는 객체의 복잡성을 단순화,추상화 함

     

책임, 역할, 협력

 - 책임-주도 설계: Application의 기능은 더 작은 ‘책임'으로 분할, 책임은 적절한 ‘역할'을 수행하는 객체에 의해 수행, 객체는 책임 수행 중 다른 객체와의 연쇄적인 ‘협력’ 진행

 - 역할을 이용하면 협력을 추상화 가능, 역할은 구체적인 객체로 대체될 수 있는 추상적인 협력자.

    객체가 역할을 대체하기 위해서는 행동이 호환돼야 함, 객체는 역할에 주어진 책임보다 많은 책임을 가질 수도 있음(일반화/특수화)

 - 디자인 패턴: 공통으로 사용할 수 있는 역할,책임,협력의 템플릿. 책임-주도 설계의 결과물인 동시에 지름길.

 - TDD/리팩토링: 협력안에서 객체의 역할과 책임이 무엇인지를 명확히 해주고, 최종 목표에 안전적이고 빠르게 도달 가능하게 함

 

책임과 메시지

1. 메지시

  -  자율적인 책임의 특징은 객체가 ‘어떻게(HOW)’해야 하는지가 아니라 ‘무엇(WHAT)’을 해야하는가이다.

     필요한 메시지가 무엇(WHAT)인지 결정 -> 누가(WHO) 수행할 것인가 결정 -> 어떻게(HOW) 수행할 것인가 자율적으로 선택

  - 시스템의 행동은 책임을 지닌 객체에게 전송된 메시지에 의해 시작된다. 메시지는 행동에 대한 요청을 표현하고, 요청을 수행하는데 필요한 정보는 인자를 통해 전달.

 

2. 다형성

  - 다형성은 송신자, 수신자 간의 객체타입에 대한 결합도를 메시지에 대한 결합도로 낮춤으로써 달성.

  - 다형성을 사용하면 메시지를 이해할 수 있는 어떤 객체와도 협력할 수 있는 유연하고 확장 가능한 구조를 만들 수 있다

 

3. 인터페이스

   - 객체가 수신할 수 있는 메시지의 목록(메시지가 인터페이스를 결정)

   - 객체가 다른 객체와 협력하기 위한 접점

   - 인터페이스 설계 원칙

     1. 좀 더 추상적인 인터페이스: 인터페이스를 좀 더 일반화 시키고 나머지는 자율적인 책임에 맡겨라, 많이 구체적인 인터페이스는 객체 수정 시 영향 커짐, 확장/대체의 어려움

     2. 최소 인터페이스: 인터페이스의 노출을 줄여서 캡슐화(객체 내부 수정의 영향 최소화)

     3. 인터페이스와 구현의 명확한 분리: 객체의 자율적인 구현 방식의 변경에 따른 영향 최소화, 유연성 확보

 

 

기능과 구조

 - 객체지향 설계를 위한 2가지 재료

1. 안정적인 구조(도메인 모델)

  - 시스템을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태(모델: 대상을 단순화한 형태 / 도메인: 시스템을 사용하는 분야)

  - 이해관계자들이 바라보는 멘탈모델.

  - 객체지향은 추상화,은유를 통해 도메인 구조와 최대한 유사하게 코드를 구조화 가능 -> 변경에 안정적(기능은 빈번하게 변하지만 도메인구조는 안정적)

 

2. 불안정한 기능(유즈케이스)

  - 시스템을 기능(책임)의 관점에서 상호작용의 흐름을 정리한 것

  - 하나의 시나리오가 아닌 여러 시나리오의 집합, 실제 설계 및 세부정보를 표현 안함 

 

결론은 안정적인 구조에 불안정적인 기능을 포함하여 설계하라!!

     

객체지향 설계에 존재하는 3가지 관점

1. 개념 관점: 도메인 안제 존재하는 개념과 개념들 사이의 관계 표현, 실제 도메인 규칙과 제약을 최대한 유사하게 반영하는 것이 핵심

2. 명세 관점: 객체 협력을 위해 '무엇(WHAT)'을 해야하는가 초점, 인터페이스 관점

3. 구현 관점: '어떻게(HOW)' 협력을 수행(구현)할 것인가 초점