「책소개 | 객체지향 사실과 오해」객체지향 설계 실전예시

//책내용 발췌

 

커피 전문점이라는 세상

 개발에 들어가기 전에 먼저 커피 전문점을 구성하는 요소들에 관해 잠시나마 고민해 보는 것이 도움될 것이다. 객체지향 패러다임의 가장 중요한 도구는 객체이므로 커피 전문점을 객체들로 구성된 작은 세상으로 바라보자.

 

커피 전문점 안에는 메뉴판이 존재한다. 메뉴판에는 아메리카노, 카푸치노, 카라멜 마끼아또, 에스프레소 네 가지 커피 메뉴가 적혀 있다. 객체지향의 관점에서 메뉴판은 하나의 객체다. 메뉴판은 네 개의 메뉴 항목으로 구성돼 있는데 메뉴 항목들 역시 객체로 볼 수 있다. 따라서 메뉴판은 네 개의 메뉴 항목 객체들을 포함하는 객체라고 볼 수 있다. 

 

손님은 메뉴판을 보고 바리스타에게 원하는 커피를 주문한다. 객체의 관점에서 보면 손님 역시 하나의 객체다. 손님 객체는 메뉴판 객체 안에 적힌 메뉴 항목 객체들 중에서 자신이 원하는 메뉴 항목 객체 하나를 선택해 바리스타 객체에게 전달할 것이다. 

 

바리스타는 주문을 받은 메뉴에 따라 적절한 커피를 제조한다. 바리스타가 제조할 수 있는 커피의 종류는 아메리카노, 카푸치노, 카라멜 마끼아또, 에스프레소의 네 가지다. 바리스타는 자율적으로 커피를 제조하는 객체로 볼 수 있으며, 바리스타가 제조하는 커피 역시 메뉴판, 메뉴 항목, 바리스타와 구별되는 자신만의 경계를 가지므로 객체로 볼 수 있따. 

 

종합해 보면 객체지향의 관점에서 커피 전문점이라는 도메인은 손님 객체, 메뉴 항목 객체, 메뉴판 객체, 바리스타 객체, 커피 객체로 구성된 작은 세상이다. 

 

 

 

 

1 관계설정

 어떤 객체가 존재하는지 살펴봤으므로 이제는 객체들 간의 관계를 살펴볼 시간이다. 손님은 메뉴판에서 주문할 커피를 선택할 수 있어야 한다. 따라서 손님은 어떤 식으로든 메뉴판을 알아야 하며, 이것은 두 객체 사이에 관계가 존재한다는 것을 암시한다. 손님은 바리스타에게 주문을 해야 하므로 손님과 바리스타 사이에도 관계가 존재한다. 바리스타는 커피를 제조하는 사람이므로 당연히 자신이 만든 커피와 관계를 맺는다.

 

인간의 두뇌는 세상을 이해하기 위해 객체를 직접적으로 다룰 수 있을 만큼 효율적이지 못하다. 우리가 할 수 있는 일은 동적인 객체를 정적인 타입으로 추상화해서 복잡성을 낮추는 것이다. 타입은 분류를 위해 사용된다는 것을 기억하라. 동일한 상태와 동일한 행동을 가질 수 있는 객체는 같은 타입의 인스턴스로 분류할 수 있다.

 

손님 객체는 '손님 타입'의 인스턴스로 볼 수 있다. 바리스타 객체는 '바리스타 타입'의 인스턴스로 볼 수 있다. 아메리카노 커피, 에스프레소 커피, 카라멜 마끼아또 커피, 카푸치노 커피 모두 '커피 타입'의 인스턴스로 볼 수 있다. 메뉴판 객체는 '메뉴판' 타입의 인스턴스다. 메뉴판 객체는 '아메리카노', '에스프레소', '카라멜 마끼아또', '카푸치노'라는 네 개의 메뉴 항목 객체를 포함할 수 있다. 네 개의 메뉴 항목 객체 역시 모두 동일한 '메뉴 항목 타입'의 인스턴스로 모델링할 수 있다.

 

커피 전문점을 구성하는 범주로서 손님 타입, 메뉴판 타입, 메뉴 항목 타입, 바리스타 타입, 카피 타입이 갖춰졌다. 이제 타입 간의 어떤 관계가 존재하는지 살펴보자.

 

하나의 메뉴판 객체는 다수의 메뉴 항목 객체로 구성돼 있다. 메뉴판과 메뉴 항목 객체는 따로 떨어져 존재하지 않으며 하나의 단위로 움직인다. 이런 관점에서 메뉴 항목 객체가 메뉴판 객체에 포함돼 있다고 할 수 있는데 이를 메뉴판 타입이 메뉴 항목 타입 간의 합성 관계로 단순화하면 좀 더 보기 수월할 것이다.

 

'그림 7.3'은 메뉴판 타입과 메뉴 항목 타입 간의 관계를 나타낸 것이다. 메뉴판 타입에서 메뉴 항목 타입 쪽으로 향하는 선에 그려진 속이 찬 마름모는 포함(containment)관계 또는 합성(composition)관계를 나타내는 것으로, 메뉴 항목이 메뉴판에 포함된다는 사실을 표현한다. 메뉴 항목 아래의 4라는 숫자는 메뉴판에 포함되는 메뉴 항목이 4개라는 것을 의미한다. 

 

그림7.3 메뉴판 타입과 메뉴 항목 타입 간의 포함관계

 

 손님 타입은 메뉴판 타입을 알고 있어야 원하는 커피를 선택할 수 있다. 메뉴판 타입은 손님의 일부가 아니므로 이 관계는 합성 관계가 아니다. 이 경우 타입들 사이를 단순한 선으로 연결한다. 이처럼 한 타입의 인스턴스가 다른 타입의 인스턴스를 포함하지는 않지만 서로 알고 있어야 할 경우 이를 연관(association)관계라고 한다.

 

그림7.4 손님과 메뉴판 사이의 연관 관계

 

 바리스타 타입은 커피를 제조해야 하므로 커피 타입을 알고 있어야 한다. 메뉴판 타입과 커피 타입 중 어떤 것도 바리스타의 일부가 아니므로 이 관계 역시 포함관계는 아니다. 

 

'그림 7.5'는 커피 전문점 도메인을 구성하는 타입들의 종류와 관계를 표현한 것이다. 이 그림은 커피 제조와 관련된 객체들을 타입과 관계를 이용해 추상화한 일종의 모델이다. 이처럼 소프트웨어가 대상으로 하는 영역인 도메인을 단순화해서 표현한 모델을 도메인 모델이라고 한다. 

 

그림7.5 커피 전문점을 구성하는 타입들

 

 커피 전문점이라는 도메인을 단순화해서 이해했으므로 이제 초점을 소프트웨어로 옮길 때다. 객체지향의 세계는 협력하는 자율적인 객체들의 공동체라는 점을 기억하라. 다음 단계는 지금까지 배운 지식을 총동원해서 협력을 설계하는 것이다. 즉, 적절한 객체에게 적절한 책임을 할당하는 것이다. 

 

* 참고  실제로 도메인 모델을 작성하는 단계에서 어떤 관계가 포함 관계이고 어떤 관계가 연관 관계인지는 중요치 않다. 초점은 어떤 타입이 도메인을 구성하느냐와 타입들 사이에 어떤 관계가 존재하는지를 파악함으로써 도메인을 이해하는 것이다. 여기서는 설명을 위해 포함 관계와 연관 관계를 구분하고 있지만 실제로는 메뉴판과 메뉴 항목 사이, 손님과 메뉴판 사이에 관계가 존재한다는 사실을 이해하는 것만으로도 충분하다.

 

 

 

2 설계 및 구현

｜커피를 주문하기 위한 협력 찾기

객체지향 설계의 첫 번째 목표는 훌륭한 객체를 설계하는 것이 아니라 훌륭한 협력을 설계하는 것이라는 점을 잊지 말자. 훌륭한 객체는 훌륭한 협력을 설계할 때만 얻을 수 있다. 

 

협력을 설계할 때는 객체가 메시지를 선택하는 것이 아니라 메시지가 객체를 선택하게 해야 한다. 이 말은 메시지를 먼저 선택하고 그 후에 메시지를 수신하기에 적절한 객체를 선택해야 한다는 것을 의미한다. 이제 메시지를 수신할 객체는 메시지를 처리할 책임을 맡게 되고 객체가 수신하는 메시지는 객체가 외부에 제공하는 공용 인터페이스에 포함된다. 

 

현재 설계하고 있는 협력은 커피를 주문하는 것이다. 아마도 첫 번째 메시지는 '커피를 주문하라'일 것이다.

 

그림7.6 협력을 시작하게 하는 첫 번째 메시지

 

메시지 위에 붙은 화살표는 메시지에 담아 전달될 부가적인 정보인 인자를 의미한다. 이 경우 '아메리카노를 주문하라' 메시지는 나중에 '메뉴를 주문하라(아메리카노)'와 같이 인자를 포함하는 형식으로 구현될 것이다. 

 

메시지를 찾았으니 이제 메시지를 처리하기에 적합한 객체를 선택해야 한다. 소프트웨어 객체는 현실 객체의 은유라는 것을 기억하자. 그렇다면 어떤 객체를 은유해야 하는가?

 

이미 우리는 커피 전문점을 추상화한 도메인 모델이라는 훌륭한 재료를 가지고 있다. 메시지를 처리할 객체를 찾고 있다면 먼저 도메인 모델 안에 책임을 수행하기에 적절한 타입이 존재하는지 살펴보라. 적절한 타입을 발견했다면 책임을 수행할 객체를 그 타입의 인스턴스로 만들어라. 현실 속의 객체와 소프트웨어 객체가 완전히 동일할 수는 없겠지만 적어도 소프트웨어 객체에게 현실 객체와 유사한 이름을 붙여 놓으면 유사성을 통해 소프트웨어 객체가 수행해야 하는 책임과 상태를 좀 더 쉽게 유추할 수 있다. 

 

본론으로 돌아와서 '커피를 주문하라'라는 메시지를 수신할 객체는 무엇인가? 다른 말로 표현해 어떤 객체가 커피를 주문할 책임을 져야 하는가? 당연히 손님일 것이다. 따라서 메시지를 처리할 객체는 손님 타입의 인스턴스다. 이제 손님 객체는 커피를 주문할 책임을 할당받았다. 

 

그림7.7 첫 번째 메시지가 손님이라는 객체를 선택

 

손님이 커피를 주문하는 도중에 스스로 할 수 없는 일이 무엇인지 생각해보자. 손님이 할당된 책임을 수행하는 도중에 스스로 할 수 없는 일이 있다면 다른 객체에게 이를 요청해야 한다. 이 요청이 바로 손님 객체에서 외부로 전송되는 메시지를 정의한다.  손님은 메뉴 항목에 대해서는 알지 못한다. 메뉴 항목은 고객의 일부가 아니라 메뉴판의 일부라는 사실을 기억하라. 따라서 고객은 자신이 선택한 메뉴 항목을 누군가가 제공해 줄 것을 요청한다. '메뉴 항목을 찾아라'라는 새로운 메시지의 등장이다. 

 

그림7.8 스스로 할 수 없는 일은 메시지를 전송해 다른 객체에게 도움을 요청 함

 

 이 경우 메시지에 '메뉴 이름'이라는 인자를 포함해 함께 전송한다. 화살표 아래에 붙은 손님으로 향하는 작은 화살표는 이 메시지를 수신한 객체가 손님에게 무엇을 응답해야 하는지를 나타낸다. 이 경우 '메뉴 항목을 찾아라'라는 메시지를 수신한 객체는 '메뉴 이름'에 대응되는 '메뉴 항목'을 반환해야 한다.

 

메뉴 항목을 찾을 책임을 누구에게 할당하는 것이 좋을까? 메뉴 항목을 가장 잘 알고 있는 객체에게 할당하는 것이 적절할 것이다. 메뉴판 객체는 메뉴 항목 객체를 포함하기 때문에 이 책임을 처리할 수 있는 가장 적절한 후보다. 

 

그림7.9 두 번째 객체를 선정

 

*참고 현실 속의 메뉴판은 자기 스스로 메뉴 항목을 찾지 않을 것이다. 현실 속에서 메뉴판은 손님에 의해 펼쳐지거나 닫혀지는 수동적인 존재다. 그러나 객체지향의 세계로 들어오면 수동적인 메뉴판이라는 개념은 더 이상 유효하지 않다. 객체지향 세계에서는 모든 객체들이 능동적이고 자율적인 존재다. 메뉴판은 마치 생명을 가진 존재처럼 자기 스스로 메뉴 항목을 찾는다. 따라서 설계자는 무생물을 생물처럼 '의인화'해야 한다.  소프트웨어 세상 속의 메뉴판은 현실 속의 메뉴판으로부터 모티브를 따왔지만 현실 속의 메뉴판보다 더 많은 일을 할 수 있다. 소프트웨어 안의 메뉴판은 현실 속의 메뉴판이 제공하는 개념을 기반으로 하기 때문에 어떤 일을 수행하는지를 유추하기 쉽다. 소프트웨어 객체는 현실 속의 객체를 모방하거나 추상화한 것이 아니다. 단지 의미를 쉽게 유추할 수 있도록 '은유'할 뿐이다.

 

손님은 자신이 주문한 커피에 대한 메뉴 항목을 얻었으니 이제 메뉴 항목에 맞는 커피를 제조해달라고 요청할 수 있다. 새로운 요청은 새로운 메시지가 필요하다는 행복한 신호다. 손님은 커피를 제조하는 메시지의 인자로 메뉴 항목을 전달하고 반환값으로 제조된 커피를 받아야 한다. 

그림7.10 새로운 메시지

 

누가 커피를 제조해야 하는가? 당연히 바리스타다.

 

그림7.11 '커피를 제조하라'는 메시지가 바리스타라는 객체를 선택했음

 

*참고 협력을 가시화하기 위해 사용한 표기법은 UML표준이 아니다. UML2.0표준에서는 협력을 표현하기 위한 용도로 커뮤니케이션 다이어그램을 제공한다. 여기서 커뮤니케이션 다이그램과 유사하지만 약간 다른 표기법을 사용한 이유는 메시지의 방향과 주고받는 데이터를 좀더 쉽게 표현하고 쉽기 때문이다. 의사소통이라는 목적에 부합한다면 용도에 맞게 얼마든지 UML을 수정하고 뒤틀어라. UML은 의사소통을 위한 표기법이지 꼭 지켜야 하는 법칙이 아니다.

 

 바리스타는 커피를 제조하는 데 필요한 모든 정보를 알고 있다. 만약 아메리카노를 만들어야 한다면 바리스타의 머릿속에는 이미 아메리카노를 만드는 데 필요한 모든 방법이 들어 있을 것이다. 바리스타는 아메리카노를 만드는 데 필요한 정보와 기술을 함께 구비하고 있는 전문가다. 아메리카노를 만들기 위한 지식은 바리스타의 상태로, 기술은 바리스타의 행동으로 간주할 수 있다. 이런 관점에서 바리스타는 스스로의 판단과 지식에 따라 행동하는 자율적인 존재다.

 

커피 주문을 위한 협력은 아래 그림과 같이 바리스타가 새로운 커피를 만드는 것으로 끝난다.

 

그림7.12 커피 주문을 위한 객체 협력

 

협력에 필요한 객체의 종류와 책임, 주고받아야 하는 메시지에 대한 대략적인 윤곽이 잡혔다. 남은 일은 메시지를 정제함으로써 각 객체의 인터페이스를 구현 가능할 정도로 상세하게 정제하는 것이다.

 

 

 

 

｜인터페이스 정리하기

우리가 힘들여 얻어낸 것은 객체들의 인터페이스다. 객체가 수신한 메시지가 객체의 인터페이스를 결정한다는 사실을 기억하라. 메시지가 객체를 선택했고, 선택된 객체는 메시지를 자신의 인터페이스로 받아들인다. 그리고 각 객체를 협력이라는 문맥에서 떼어내서 수신 가능한 메시지만 추려내면 객체의 인터페이스가 된다. 객체가 어떤 메시지를 수신할 수 있다는 것은 그 객체의 인터페이스 안에 메시지에 해당하는 오퍼레이션이 존재한다는 것을 의미한다. 

 

손님 객체의 인터페이스 안에는 '제품을 주문하라'라는 오퍼레이션이 포함돼야 한다. 메뉴판 객체의 인터페이스는 '메뉴 항목을 찾아라'라는 오퍼레이션을 제공하며, 바리스타 객체의 인터페이스는 '커피를 제조하라'라는 오퍼레이션을, 커피 객체는 '생성하라'라는 오퍼레이션을 제공한다. 

그림7.13 각 객체들이 수신하는 메시지는 객체의 인터페이스를 구성 함

 

객체들의 협력은 실행 시간에 컴퓨터 안에서 일어나는 상황을 동적으로 묘사한 모델이다. 실제로 소프트웨어의 구현은 동적인 객체가 아닌 정적인 타입을 이용해 이뤄진다. 따라서 객체들을 포괄하는 타입을 정의한 후 식별된 오퍼레이션을 타입의 인터페이스에 추가해야 한다. 

 

객체의 타입을 구현하는 일반적인 방법은 클래스를 이용하는 것이다. 협력을 통해 식별된 타입의 오퍼레이션은 외부에서 접근 가능한 공용 인터페이스의 일부라는 사실을 기억하라. 따라서 인터페이스에 포함된 오퍼레이션 역시 외부에서 접근 가능하도록 공용(public)으로 선언돼 있어야 한다. 클래스의 인터페이스는 자바스크립트의 문법을 이용해 표기했다.

 

class Customer{
	constructor(){ 
	   //작성...
	}
	order(menuName){ new throw error }
}


class Menu{
	constructor(){
	   this.menuItem = null;
	}
	chooseMenu(name){
	   console.log(this.name);
	}
}


class Barista{
	constructor(){
		this.espressoMachine = null;
	}

	makeCoffee(menuItem){
	   let espresso = this.espressoMachine.makeEspresso()
	   return espresso;
	}
	set espressoMachine(espressoMachine){
	   this.espressoMachine = espressoMachine;
	}
}


class EspressoMachine{
	constructor(){
	   this.price = 300000;
	}
	makeEspresso(){
	   return new Espresso();
	}
}

 

 

 

 

｜구현하기

 클래스의 인터페이스를 식별했으므로 이제 오퍼레이션을 수행하는 방법을 메서드로 구현하자. 먼저 Customer의 협력을 살펴보자. Customer는 Menu에게 menuName에 해당하는 MenuItem을 찾아달라고 요청해야 한다. 그리고 MenuItem을 받아 이를 Barista에게 전달해서 원하는 커피를 제조하도록 요청해야 한다. 

 

그림7.14 손님의 구현은 메뉴판과 바리스타와 협력관계 형성

 

문제는 Customer가 어떻게 Menu 객체와 Barista객체에 접근할 것인가에 있다. 객체가 다른 객체에게 메시지를 전송하기 위해서는 먼저 객체에 대한 참조를 얻어야 한다. 따라서 Customer객체는 어떤 방법으로든 자신과 협력하는 Menu객체와 Barista객체에 대한 참조를 알고 있어야 한다. 

 

객체 참조를 얻는 다양한 방법이 있지만 여기서는 Customer의 order( )메서드의 인자로 Menu와 Customer객체를 전달받는 방법으로 참조 문제를 해결하기로 한다. 이 결정은 결과적으로 Customer의 인터페이스를 변경한다.

 

class Customer{
	constructor(){
	   //코드작성...
	}
	order(menuName,menu, barista){}
}

//남은 것은 order()메서드의 구현을 채우는 것뿐이다


class Customer{
	constructore(){
       //코드작성...
	}
	order(menuName,menu,barista){
	   //코드작성...
    }
}

 

 

구현 도중에 객체의 인터페이스가 변경될 수 있다는 점에 유의한다.

 

*참고 구현하지 않고 머릿속으로만 구상한 설계는 코드로 구현하는 단계에서 대부분 변경된다. 설계 작업은 구현을 위한 스케치를 작성하는 단계지 구현 그 자체일 수는 없다. 중요한 것은 설계가 아니라 코드다. 따라서 협력을 구항하는 단계에 너무 오랜 시간을 쏟지 말고 최대한 빨리 코드를 구현해서 설계에 이상이 없는지, 설계가 구현 가능한지를 판단해야 한다. 코드를 통한 피드백 없이는 깔끔한 설계를 얻을 수 없다.

 

 Menu는 menuItem에 해당하는 MenuItem을 찾아야 하는 책임이 있다. 이 책임을 수행하기 위해서는 Menu가 내부적으로 MenuItem을 관리하고 있어야 한다. 간단하게 Menu가 MenuItem의 목록을 포함하게 하자. Menu의 choose()메서드는 MenuItem의 목록을 하나씩 검사해가면서 이름이 동일한 MenuItem을 찾아 반환한다.

 

Class Menu{
	constructor(){
	   this.menuItem = null;
	   this.usrSlc = null;   
	   choose(this.menuItem,this.usrSlc)
	}
    
	set menuItem(menu){
	   this.menuItem = menu;
	}
    
	choose(menuItem,usrSlc){
		for(let item of menuItem){
			if(item == usrSlc){  
				return item; 
			}
		}
	}
        
	set userSelection(item){
	   this.usrSlc = item
	}
}

 

*참고 MenuItem의 목록을 Menu의 속성으로 포함시킨 결정 역시 클래스를 구현하는 도중에 내려졌다는 사실에 주목하라. 객체의 속성은 객체의 내부 구현에 속하기 때문에 캡슐화되어야 한다. 객체의 속성이 캡슐화된다는 이야기는 인터페이스에는 객체의 내부 속성에 대한 어떤 힌트도 제공되어서는 안 된다는 것을 의미한다. 이를 위한 가장 훌륭한 방법은 인터페이스를 정하는 단계에서는 객체가 어떤 속성을 가지는지, 또 그 속성이 어떤 자료 구조로 구현됐는지를 고려하지 않는 것이다. 객체에게 책임을 할당하고 인터페이스를 결정할 때는 가급적 객체 내부의 구현에 대한 어떤 가정도 하지 말아야 한다. 객체가 어떤 책임을 수행해야 하는지를 결정한 후에야 책임을 수행하는 데 필요한 객체의 속성을 결정하라. 이것이 객체의 구현 세부 사항을 객체의 공용 인터페이스에 노출시키지 않고 인터페이스와 구현을 깔끔하게 분리할 수 있는 기본적인 방법이다.

 

그리고 Barista는 MenuItem을 이용해서 커피를 제조한다.

class Barista{
	constructor(){
	   this.coffee = null;
	   //생략...    
	}
	makeCoffee(){
	   this.coffee = new Coffee(menuItem);
	   return this.coffee;
	}
}

 

또한, Coffee는 자기 자신을 생성하기 위한 생성자를 제공한다. Coffee클래스는 커피 이름과 가격을 속성으로 갖고 있으며, 생성자 안에서 MenuItem에 요청을 보내 커피 이름과 가격을 얻은 후 Coffee의 속성에 저장한다.

 

class Coffee{
	constructor(){
	   this._name;
	   this._price;    
	}
	set Coffee(menuItem){
	   this._name = menuItem.getName();
	   this._price = menuItem.cost();
	}
}

 

이제 MenuItem은 getName( )과 cost( )메시지에 응답할 수 있도록 메서드를 구현해야 한다. 

 

class MenuItem{
	constructor(name, price){
	   this.name = name;
	   this.price = price;
	}
	cost(){
	   return this.price;
	}
	getName(){
	   return this.name;
	}
}

 

[참고] MenuItem의 인터페이스를 구성하는 오퍼레이션들은 MenuItem을 구현하는 단계에 와서야 식별했다는 점을 눈여겨보기 바란다. 이것은 부끄러워해야 할 일이 아니다. 인터페이스는 객체가 다른 객체와 직접적으로 상호작용하는 통로다. 인터페이스를 통해 실제로 상호작용을 해보지 않은 채 인터페이스의 모습을 정확하게 예측하는 것은 불가능에 가깝다. 설계를 간단히 끝내고 최대한 빨리 구현에 돌입하라. 머릿속에 객체의 협력 구조가 번뜩인다면 그대로 코드를 구현하기 시작하라. 설계가 제대로 그려지지 않는다면 고민하지 말고 실제로 코드를 작성해가면서 협력의 전체적인 밑그림을 그려보라. 테스트-주도 설계로 코드를 구현하는 사람들이 하는 작업이 바로 이것이다. 그들은 테스트 코드를 작성해 가면서 협력을 설계한다.

 

 커피전문점 객체지향 설계는 '메시지가 객체를 결정한다는 말의 의미', '책임을 따라 설계가 이뤄지는 과정', '인터페이스와 구현의 분리'와 같은 다양한 이슈에 대해 개념을 잡기에 유용하다.

 

 

 

 

 

코드와 세가지 관점

｜코드는 세 가지 관점을 모두 제공해야 한다

 

위에서 작성한 코드는 개념 관점, 명세 관점, 구현 관점에서 각기 다른 사항들을 설명해준다. 먼저 개념 관점에서 코드를 바라보면 Customer, Menu, MenuItem, Barista, Coffee클래스가 보인다. 이 클래스들을 자세히 살펴보면 커피 전문점 도메인을 구성하는 중요한 개념과 관계를 반영한다는 사실을 쉽게 알 수 있다. 소프트웨어 클래스가 도메인 개념의 특성을 최대한 수용하면 변경을 관리하기 쉽고 유지보수성을 향상시킬 수 있다. 가령, 커피를 제조하는 과정을 변경해야 한다면 어디를 수정해야 할까? 현실세계에서 커피를 제조하는 사람은 바리스타다. 따라서 현실 세계와 동일하게 소프트웨어 안에서도 Barista라는 클래스가 커피를 제조할 것이라고 쉽게 유추할 수 있다. 소프트웨어 클래스와 도메인 클래스 사이의 간격이 좁을수록 기능을 변경하기 위해 뒤적거려야 하는 코드의 양도 줄어든다.

 

 명세 관점은 클래스의 인터페이스를 바라본다. 클래스의 public 메서드는 다른 클래스가 협력할 수 있는 공용 인터페이스를 드러낸다. 공용 인터페이스는 외부의 객체가 해당 객체에 접근할 수 있는 유일한 부분이다. 인터페이스를 수정하면 해당 객체와 협력하는 모든 객체에게 영향을 미칠 수 밖에 없다. 객체의 인터페이스는 수정하기 어렵다는 사실을 명심하라. 최대한 변화에 안정적인 인터페이스를 만들기 위해서는 인터페이스를 통해 구현과 관련된 세부사항이 드러나지 않게 해야 한다. 변화에 탄력적인 인터페이스를 만들 수 있는 능력은 객체지향 설계자의 수준을 가늠하는 중요한 척도다.

 

 구현 관점은 클래스의 내부 구현을 바라본다. 클래스의 메서드와 속성은 구현에 속하며 공용 인터페이스의 일부가 아니다. 따라서 메서드의 구현과 속성의 변경은 원칙적으로 외부의 객체에게 영향을 미쳐서는 안 된다.(원칙적이라는 말 속에는 현실적으로 100%파급 효과가 미치는 것을 막는 것이 불가능한 경우도 있다는 사실을 암시한다) 이것은 메서드와 속성이 철저하게 클래스 내부로 캡슐화돼야 한다는 것을 의미한다. 메서드와 속성은 클래스 내부의 비밀이다. 외부의 클래스는 자신이 협력하는 다른 클래스의 비밀 때문에 우왕좌왕해서는 안 된다.

 

 개념 관점, 명세 관점, 구현 관점은 동일한 코드를 바라보는 서로 다른 관점이다. 훌륭한 객체지향 프로그래머는 하나의 클래스 안에 세 가지 관점을 모두 포함하면서도 각 관점에 대응되는 요소를 명확하고 깔끔하게 드러낼 수 있다. 다른 사람이 여러분의 코드를 읽으면서 세 가지 관점을 쉽게 포착하지 못한다면 세 가지 관점이 명확하게 드러날 수 있게 코드를 개선하라. 그것이 변경에 유연하게 대응할 수 있는 객체지향 코드를 작성하는 가장 빠른 길이다.

 

 

 

 

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

어떤 메시지가 있을 때 그 메시지를 수신할 객체를 어떻게 선택하는가? 첫 번째 전략은 도메인 개념 중에서 가장 적절한 것을 선택하는 것이다. 도메인 개념 안에서 적절한 객체를 선택하는 것은 도메인에 대한 지식을 기반으로 코드의 구조와 의미를 쉽게 유추할 수 있게 한다. 이것은 시스템의 유지보수성에 커다란 영향을 미친다.

 

소프트웨어는 항상 변한다. 설계는 변경을 위해 존재한다. 여러 개의 클래스로 기능을 분할하고 클래스 안에서 인터페이스와 구현을 분리하는 이유는 변경이 발생했을 때 코드를 좀 더 수월하게 수정하길 간절히 원하기 때문이다. 그러므로 소프트웨어 클래스가 도메인 개념을 따르면 변화에 쉽게 대응할 수 있다.

 

 

 

 

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

 다시 한 번 강조하지만 인터페이스와 구현을 분리하라.

 

명세 관점과 구현 관점이 뒤섞여 머릿속을 함부로 어지럽히지 못하게 하라. 명세 관점은 클래스의 안정적인 측면을 드러내야 한다. 구현 관점은 클래스의 불안정한 측면을 드러내야 한다. 인터페이스가 구현 세부사항을 노출하기 시작하면 아주 작은 변동에도 전체 협력이 요동치는 취약한 설계를 얻을 수밖에 없다.

 

「마틴 파울러」에 의하면, 개념적·명세 관점 사이는 그렇게 중요하지 않은 경우가 많지만 명세·구현 관점을 분리하는 것은 매우 중요하다. 개발자 입장에서 가장 많이 접하게 되는 것은 코드이므로 구현 관점을 가장 빈번하게 사용하겠지만 실제로 훌륭한 설계를 결정하는 측면은 명세 관점인 객체의 인터페이스다. 명세 관점이 설계를 주도하게 되면 설계의 품질이 향상될 수 있다는 사실을 기억하자. 중요한 것은 우리가 클래스를 봤을 때, 클래스를 명세 관점과 구현 관점으로 나눠볼 수 있어야 한다는 것이다. 캡슐화를 위반하여, 구현을 인터페이스 밖으로 노출해서도 안 되고, 인터페이스와 구현을 명확하게 분리하지 않고 흐릿하게 섞어놓아서도 안 된다. 결국 세 가지 관점 모두에서 클래스를 바라볼 수 있으려면, 훌륭한 설계가 뒷받침되어야 하는 것이다.