핌플 이디엄 Pimpl idiom

 

Pimple은 Pointer to Implementation의 약자이다.

즉, 구현부를 포인터로 참조하는 관례를 뜻한다. 기술적인 측면에서 Pimpl  관례가 무슨 역할을 하는지 알아보자.

Cat class의 헤더이다.

// Cat.h
#pragma once

// forward-declare
class CatImpl;

class Cat
{
public:
	Cat();
	virtual ~Cat();

	void setAge(int age);
	void setColor(int color);

	int getAge() const;
	int getColor() const;

private:
	
	CatImpl *impl;
};

 

class Cat의 cpp 파일이다. 인터페이스와 구현 부가 분리된 것을 알 수 있다.

#include "Cat.h"

class CatImpl
{
public:
	CatImpl()
		:age(0)
		,color(0) {
	}
	~CatImpl() {
		;
	}

	void setAge(int age) {
		this->age = age;
	}
	void setColor(int color) {
		this->color = color;
	}
	int getAge() const {
		return age;
	}
	int getColor() const {
		return color;
	}

private:
	int age;
	int color;
};

Cat::Cat()
	: impl(new CatImpl()) {

}

Cat::~Cat() {
	delete impl;
}

void Cat::setAge(int age) {
	impl->setAge(age);
}
void Cat::setColor(int color) {
	impl->setColor(color);
}

int Cat::getAge() const {
	return impl->getAge();
}

int Cat::getColor() const {
	return impl->getColor();
}
​

 

Pimpl 장점

사용자에게 private 변수 및 함수를 숨길 수 있다.
API 인터페이스와 구현이 분리된다.
전방 선언을 사용하여 코드 간의 의존성을 낮추어 컴파일 소모 시간을 줄일 수 있다.

 

Pimpl 단점

유지 보수 노력 증가 - 세부 구현 사항 구현 및 수정 모두 수정해야 한다.
동적 할당으로 메모리 사용량이 증가된다.
성능 손실(내용을 인라인 하지 못할 수 있다고 합니다)

 Pimpl idiom 은 자주 변경되는 코드에는 부적합하다고 생각이 든다. 실제 사용 시에는 코드 수정이 적은 쪽에서 사용하는 것이 좋다고 본다. 필자는 오픈소스 라이브러리(Third-party OpenSource)를 사용할 때 주로 사용한다.