03 타입과 추상화 (2) 타입

00. 타입

타입은 개념이다.

 

타입은 공통점을 기반으로 객체들을 묶기 위한 틀이다.

타입은 개념과 마찬가지로 심볼, 내연, 외연을 이용해 서술할 수 있으며 타입에 속하는 객체 역시 타입의 인스턴스라고 한다.

 

타입은 개념과 동일하다.
따라서 타입이란 우리가 인식하고 있는 다양한 사물이나 객체에 적용할 수 있는 아이디어나 관념을 의미한다.
어떤 객체에 타입을 적용할 수 있을 때 그 객체를 타입의 인스턴스라고 한다.
타입의 인스턴스는 타입을 구성하는 외연인 객체 집합의 일원이 된다.

 

타입이 근본적으로 개념과 동일하다고 하더라도 일단 컴퓨터 내부로 들어오는 순간 좀 더 기계적인 의미로 윤색될 수 밖에 없다.

기계적인 의미는 종종 개발자들의 머리를 혼란스럽게 만든다.

 

컴퓨터 안에 살아가는 데이터를 목적에 따라 분류(숫자형, 문자열형, 논리형,,)하기 시작하면서 프로그래밍 언어 안에는 서서히 타입 시스템(type system)이 자라나기 시작했다.

타입 시스템은 메모리 안에 저장된 0과 1에 대해 수행 가능한 작업과 불가능한 작업을 구분함으로써 데이터가 잘못 사용되는 것을 방지한다.

결과적으로 타입 시스템의 목적은 데이터가 잘못 사용되지 않도록 제약사항을 부과하는 것이다.

 

✔ 타입은 데이터가 어떻게 사용되느냐에 관한 것이다.

    - 숫자형 데이터 : 데이터를 더하거나 빼거나 곱하거나 나눌 수 있다.

    - 문자열형 데이터 : 두 데이터를 연결해 새로운 문자열로 만들 수 있고, 데이터에 포함된 문자의 길이를 알 수 있다.

 : 데이터가 어떤 타입에 속하는지를 결정하는 것 = 데이터에 적용할 수 있는 작업

 

연산자(operate) : 데이터를 이용해 수행할 수 있는 작업 (ex: +, -, *, / -> 산술 연산자의 일종)

여기서 !! 연산자의 종류가 아니라 어떤 데이터에 어떤 연산자를 적용할 수 있느냐가 그 데이터의 타입을 결정한다.

 

✔ 타입에 속한 데이터를 메모리에 어떻게 표현하는지는 외부로부터 철저하게 감춰진다.

데이터 타입의 표현은 연산 작업을 수행하기에 가장 효과적인 형태가 선택되며,

개발자는 해당 데이터 타입의 표현 방식을 몰라도 데이터를 사용하는 데 지장이 없다.

 

데이터 타입은 메모리 안에 저장된 데이터의 종류를 분류하는 데 사용하는 메모리 집합에 관한 메타데이터다.
데이터에 대한 분류는 암시적으로 어떤 종류의 연산이 해당 데이터에 대해 수행될 수 있는지를 결정한다.

---

객체지향 프로그램을 작성할 때 우리는 객체를 일종의 데이터처럼 사용한다.

따라서 객체를 타입에 따라 분류하고 그 타입에 이름을 붙이는 것은 결국 프로그램에서 사용할 새로운 데이터 타입을 선언하는 것과 같다.

 

동일한 책임을 수행하는 일련의 객체는 동일한 타입에 속한다고 말할 수 있다.

-> 같은 타입에 속한 객체는 행동만 동일하다면 서로 다른 데이터를 가질 수 있다.

 

여기서, 동일한 행동 = 동일한 책임 = 동일한 메세지

-> 동일한 타입에 속한 객체는 내부의 데이터 표현 방식이 다르더라도 동일한 메시지를 수신하고 이를 처리할 수 있다.

     다만 내부의 표현 방식이 다르기 때문에 동일한 메시지를 처리하는 방식을 서로 다를 수밖에 없다.

-> 이것은 다형성에 의미를 부여한다.

     (다형성 : 동일한 요청에 대해 서로 다른 방식으로 응답할 수 있는 능력) -> 다형적인 객체들은 동일한 타입(또는 타입 계층)에 속한다.

 

훌륭한 객체지향 설계는 외부에 행동만을 제공하고 데이터는 행동 뒤로 감춰야 한다. -> 캡슐화 

-> 공용 인터페이스 뒤로 데이터를 캡슐화하는 오래된 격언은 객체를 행동에 따라 분류하기 위해 지켜야하는 기본적인 원칙이다.

 

행동에 따라 객체를 분류하기 위해서는 객체가 내부적으로 관리해야 하는 데이터가 아니라 객체가 외부에 제공해야 하는 행동을 먼저 생각해야 한다. 이를 위해서는 객체가 외부에 제공해야 하는 책임을 먼저 결정하고 그 책임을 수행하는 데 적합한 데이터를 나중에 결정한 후, 데이터를 책암을 수행하는 데 필요한 외부 인터페이스 뒤로 캡슐화해야 한다.

책임-주도 설계(Responsibility-Driven Design)라고 부르는 객체지향 설계 방법은 데이터를 먼저 생각하는 데이터-주도 설계(Data-Driven Design) 방법의 단점을 개선하기 위해 고안됐다.

 

객체를 결정하는 것은 행동이다.

데이터는 단지 행동을 따를 뿐이다.

이것이 객체를 객체답게 만드는 가장 핵심적인 원칙이다.

 

01. 타입의 계층

일반화/특수화

일반적인 타입이란 특수한 타입이 가진 모든 행동들 중에서 일부 행동만을 가지는 타입을 가리킨다.

특수한 타입이이란 일반적인 타입이 가진 모든 타입을 포함하지만 거기에 더해 자신만의 행동을 추가하는 타입을 가리킨다.

 

슈퍼타입/서브타입

일반화/특수화 관계는 좀 더 일반적인 한 타입과 좀 더 특수한 한 타입 간의 관계다.

이 때 좀 더 일반적인 타입을 슈퍼타입(Supertype)이라고 하고 좀 더 특수한 타입을 서브타입(Subtype)이라고 한다.

 

슈퍼타입과 서브타입에서 중요한 것은 두 타입 간의 관계가 행동에 의해 결정된다.

-> 어떤 타입이 다른 타입의 서브타입이 되기 위해서는 행위적 호환성을 만족시켜야 한다.

-> 일반적으로 서브타입은 슈퍼타입의 행위와 호환되기 때문에 서브타입은 슈퍼타입을 대체할 수 있어야 한다.

 

02. 정적 모델

왜 타입을 사용해야 하는가? 객체지향은 객체를 지향하는 것이므로 객체만 다루면 되지 않는가?

: 타입을 사용하는 이유는 인간의 인지 능력으로는 시간에 따라 동적으로 변하는 객체릐 복잡성을 극복하기가 너무 어렵기 때문이다.

 

타입을 사용하면 동적으로 변하는 객체의 상태를 정적인 관점에서 표현할 수 있다.

 

✔ 타입은 추상화다.

    타입을 이용하면 객체의 동적인 특성을 추상화할 수 있다.

    결국 타입은 시간에 따른 객체의 상태 변경이라는 복잡성을 단순화할 수 있는 효과적인 방법이다.

 

✔ 객체를 생각할 때, 우리는 두 가지 모델을 동시에 고려하고 있다.

 

    1. 객체가 특정 시점에 구체적으로 어떤 상태를 가지느냐?

       → 이를 객체의 스냅샷(snapshot)이라고 한다.

       → 객체지향 모델링을 위한 표준 언어(UML)에서 스냅샷은 객체 다이어그램(object diagram)이라고도 불린다.

     스냅샷처럼 실제로 객체가 살아 움직이는 동안 상태가 어떻게 변하고 어떻게 행동하는지를 포착하는 것을 동적 모델(dynamic model)라고 한다.

 

     2. 객체가 가질 수 있는 모든 상태와 모든 행동을 시간에 독립적으로 표현하는 것

        → 일반적으로 이런 모델을 타입 모델(type diagram)이라고 한다.

      이 모델은 동적으로 변하는 객체의 상태가 아니라 객체가 속한 타입의 정적인 모습을 표현하기 때문에 정적 모델(static model)이라고 한다.

 

* 객체지향 어플리케이션을 설계하고 구현하기 위해서는 객체 관점의 동적 모델과 객체를 추상화한 타입 관점의 정적 모델을 적절히 혼용해야 한다.

객체지향 프로그래밍 언어를 이용해 클래스를 작성하는 시점에는 시스템을 정적인 관점에서 접근하는 것이다.

그러나 실제로 애플리케이션을 실행해 객체의 상태 변경을 추적하고 디버깅하는 동안에는 객체의 동적인 모델을 탐험하고 있는 것이다.

 

✔ 객체지향 프로그래밍 언어에서 정적인 모델은 클래스를 이용해 구현된다.

    따라서 타입을 구현하는 가장 보편적인 방법은 클래스를 이용하는 것이다.

    - 타입 : 객체를 분류하기 위해 사용하는 개념

    - 클래스 : 단지 타입을 구현할 수 있는 여러 구현 메커니즘 중 하나일 뿐

    (실제로 자바스트립트와 같은 프로토타입 기반의 언어에는 클래스가 존재하지 않는다.)

---

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

⭐  클래스는 타입을 구현하기 위해 프로그래밍 언어에서 제공하는 구현 메커니즘이라는 사실을 기억하자. ⭐