객체 지향의 사실과 오해를 읽고

1. 주문자, 캐시어, 바리스타의 관계

주문자

-캐시어를 모른다.(그저 메뉴를 파라미터로 호출한다.)

-캐시어가 누가 되든 상관없다.(캐시어는 인터페이스를 구현하는 여러 객체이다.)

-커피만 return해주면 된다.

캐시어

-바리스타를 모른다.

-바리스타가 누가되든 상관없다.

-커피만 return해주면 된다.

바리스타

-파라미터를 보고 return해주면 된다.

-커피 제조는 바리스타마다 자신만의 독특한 방법도 가능(다형성, 즉, 인터페이스 사용)

 

2. 객체의 역할

-여러 객체가 동일한 역할을 수행할 수 있다.(인터페이스, 다형성)

-역할은 대체 가능성을 의미한다.(인터페이스, 다형성)

-각 객체는 책임을 수행하는 방법을 자율적으로 선택할 수 있다.(메서드 오버로딩)

-하나의 객체가 동시에 여러 역할을 수행할 수 있다.(메서드 오버로딩, 파라미터, return형에 따른 여러 역할 가능)

 

3. 객체의 특성

-객체는 능동적이다.(메서드 오버로딩, 다형성을 통해 누가 어떤 역할에 책임을 질 것인지 선택 가능하다.)

-객체는 자유롭다.(그냥 파라미터와 어떤 행동을 호출받으면, 자유롭게 메서드를 실행한다.)

-상태(지역 변수)와 행동(메서드)를 지닌다.

-이전 객체가 이후 객체를 호출할 때, 무엇(인터페이스 정의 api)을 하라고는 지시할 수 있지만, 어떻게(구현 메서드)는 통제하거나 알지 못한다. 또한 상태(지역 변수)도 모른다.(모르는것: 변수, 메서드 동작 아는것: 메서드명)

***위의 이전 객체는 송신자(메시지 전달)라 하고, 이후 객체를 수신자(메시지 받아 수행)이라 한다.

-위의 모르는것과 아는 것을 분리하는 것을 캡슐화로 정의할 수 있는데, private나 protected를 사용하여 직접 접근하지 못하도록 한다.(인터페이스에 public인 캐시어가 바리스타에게 지시할 수 있는 메서드만 정의해둔다. 캐시어는 인터페이스를 보고 바리스타에게 지시한다.)

 

4. 객체 지향 중요한 점

-메시지를 주고받는 객체의 관점으로 사고의 중심을 전환하라.(송신자가 수신자에게 어떤 역할을 시켜야 하는가에 집중)

 

5. 객체의 3요소(요소 별 규칙)

상태(지역 변수) : 행동(메서드)를 통해서만 통제한다.

-특정 시점에 객체가 갖고 있는 정보의 집합, 객체의 구조적 특징을 표현한다.

-정적 상태(Enum, final), 동적 상태로 구성된다.

행동(메서드) : 상태에 의존적이며 상태를 변경시킨다.

-if문과 같은 제어로 상태를 통한 행동을 한다.

-누군가가 협력을 요청하면, 자신의 상태를 변경시키는 행동을 한다.(이 때문에, 모든 객체는 능동적이라 할 수 있겠다.) 

-송신자는 그저 상태가 바뀔 것이라 믿고 행동을 협력 요청하는것.

식별자(클래스명)

-값 타입 : Integer와 같이 값 자체를 나타내는 타입. 메모리 주소는 신경쓰지 않고, 값이 같으면 동일한 객체로 취급.

-참조 타입 : Person과 같이 메모리 주소로 동일한가를 판단하는 타입.

-List<>, String 참조타입 vs Person 참조타입 : List<> 참조 타입 또한 메모리 주소로 동일성이 판단되기 때문에, class와 같은 취급을 해줘야한다.

 

6. 추상화

타입 분류 방법

-컴퓨터 메모리에서의 타입은 비트열 하나 뿐이다. 프로그래머들이 정한 데이터 타입은 비트열에 대한 메타데이터이다.

-데이터 타입은 비트열을 어떤 행동(연산)을 수행하기 위해 분류한 것.

-즉, 타입은 객체가 수행하는 행동으로 분류할 수 있다.

-객체는 철저히 외부로부터 감춰진다.

-객체의 타입 또한 데이터 타입이다.

-즉, 같은 행동을 구현하고 있으면, 어떠한 상태나 식별자를 갖던, 같은 타입이라 볼 수 있다.

-위와 같이 우리는 행동에 따라 객체를 분류할 수 있고, 이는 객체가 외부에 제공해야 하는 행동을 먼저 생각하는 책임 주도 설계를 따라가게 된다.

 

슈퍼 타입/서브 타입

-행동으로 타입을 구분할때, 슈퍼 타입을 상속할 시 서브 타입이라고 한다.

-슈퍼 타입(부모) : 행동1

-서브 타입(자식) : 행동1 + 행동2

 

***타입은 객체의 상태를 정적인 모습으로 다룰 수 있게 해준다는 점 기억하자.

***타입 모델 : 객체와 시간에 따른 모습인 객체를 따로 구분한 것.

***즉, 타입으로 객체를 정의함으로 간단히 추상화 할 수 있다.

 

7. 책임 주도 설계 방법(구현 시)

==> 시스템이 제공해야할 책임을 늘어놓는다.

-책임은 하는 것과 아는 것이 있다.

-하는 것 : 객체 생성, 다른 객체 호출, 다른 객체 활동 제어

-아는 것 : 자신의 상태나 관련 객체의 상태를 return 

-책임의 범위 : 한 클래스를 고칠때, 다른 클래스가 영향받지 않을 만한 범위

==> 이 책임을 분할하여 여러개를 늘어놓는다.

==> 분할된 책임을 수행할 수 있는 객체(역할)을 만든다.

-역할은 위의 추상화에 따라, 행동으로 객체의 데이터 타입이 역할이다. 유지보수를 위해 인터페이스를 통해 구현할 수 있다.

==> 만일, 다른 객체의 도움이 필요하다면, 새로운 객체(역할)을 만든다.

==> 협력하게끔 다듬는다.

 

8. 객체 지향 설계 방법(전체적)

기능 : 목표 달성 위해 사용할 수 있는 시스템의 서비스

구조 : 기능을 구현하기 위한 기반

-도메인 모델을 통해 우리는 구조를 설계할 수 있다.

-구조를 설계한 이후 유스케이스로 기능 또한 설계하자.

-기능까지 설계되었다면, 기능들을 세분화하고, 위의 객체 지향 설계를 사용해 구현하면 된다.

***항상 요청과 응답임을 명심하자.

 

<이 글은 객체지향의 사실과 오해를 읽고 작성되었습니다.>