루비로 배우는 객체지향 디자인

처음 구매 했을때는 주변 루비 개발자분들이 좋은책 이라고 해서 구매했지만 막상 읽지를 않고 책장에 꽃혀있던 책을 블로그 포스팅을 위해 꺼내서 읽었습니다.

작성은 각 장에서 깨달은 내용을 적을 예정이고 총 9장까지 있습니다.

책 제목은 루비지만 꼭 루비가 아니더라도 객체지향 디자인을 원하는 사람에게는 좋은 책이라는걸 느꼈습니다.

5. 오리 타입으로 비용 줄이기

오리 타입, Duck Typing 은 예전부터 굉장히 많이 나오고 실제로 사용하고 있던 방법 중에 하나 입니다.

그런데 이번에 글을 읽을때 어떻게 설명이 되는지 굉장히 기대가 되었는데 기대 이상으로 좋은 내용이였습니다.

먼저 오리 타입, 덕 타이핑을 사용하는 큰 이유는 “특정 클래스에 종속 되지 않은 퍼블릭 인터페이스” 이기 때문에 클래스에 대한 의존을 메세지에 대한 의존으로 대치 시킵니다. 이는 덕 타이핑 객체가 클래스 보다는 행동에 의해 규정되기 때문입니다. 행동에 의해 규정 된다는건 덕 타이핑의 이름대로 “오리처럼 꽥꽥대고 오리처럼 걷는다면 이 객체는 오리가 맞다.” 를 의미합니다.

이런 오리타입이 나오게 되는 생각의 전환점은 어떤 객체가 하나의 인터페이스에만 반응할 수 있다는 생각입니다.

사람마다 생각이 다르듯 객체를 사용하는 사람에 따라 그 객체의 쓰임은 달라질 수 있습니다. 그리고 객체를 사용하는 사람은 객체의 클래스가 무엇인지를 신경 쓸 필요가 없습니다. 클래스는 객체가 퍼블릭 인터페이스를 갖기 위한 하나의 수단일 뿐입니다. 진짜 중요한 것은 객체가 무언기가가 아니라 어떻게 행동 하는가 입니다.

이전 예제에서 여행을 준비할때 정비공에게 여행에 사용할 자전거를 준비하는 코드가 있었습니다.

class Trip
	attr_reader :bicycles
	
	def prepare(mechanic)
		mechanic.prepare_bicycles(bicycles)
	end
end

여기서 여행에 필요한 준비 요소가 늘었다고 생각이 되면 기존의 코드를 같은 방식으로 더 추가하게 됩니다.

class Trip
	attr_reader :bicycles, :vehicle
	
	def prepare(preparers)
		preparers.each do |preparer|
			case preparer
			when Mechanic
				preparer.prepare_bicycles(bicycles)
			when Driver
				parparer.gas_up(vehicle)
				parparer.fill_water_tank(vehicle)
			end
		end
	end
end

지금은 하나만 추가 되었지만 상황에 따라서는 점점 코드가 길고 복잡해지고 점점 코드 수정 비용이 늘어날 것 입니다.

이때 Trip 의 prepare 의 목적에 대해서 생각해봅니다. prepare 는 사실 여행을 준비하기 위한 메서드 입니다.

각각의 Mechanic 와 Driver 이 prepare 의 목적에 맞는 메서드를 구현할거라고 믿고 코드를 작성해보겠습니다.

class Trip
	attr_reader :bicycles, :vehicle
	
	def prepare(preparers)
		preparers.each do |preparer|
			preparer.prepare_trip(self)
    end
	end
end

여기서 얻을 수 있는 이점이 있습니다.

첫번째 코드는 구체적이기 때문에 이해하기 쉽지만 확장에는 위험합니다. 하지만 두번째 코드는 추상적이라 이해하기는 쉽지 않지만 손쉬운 확장을 제공합니다.

코드의 수정 비용이 중요한 포인트라면 이처럼 코드의 덕 타이핑이 가능한 시점을 찾아내 수정하면 앞으로의 코드 수정 비용에는 확실히 도움이 될겁니다.

객체지향 디자인에서 구체적인 코드를 작성하는 비용과 추상적인 코드를 작성하는 비용 사이의 고민에서는 결코 자유로울 수 없기 때문에 상황에 따라 잘 선택 할 수 있도록 다양한 방법을 이해하고 익혀두는게 중요하다고 생각이 듭니다.