smart and get things done

PImpl Idiom

- 인터페이스(Interface)와 구현(Implementation)을 구분해서, Coupling을 최소화
- 구현(Implementation)을 감출 수 있고, 구현의 세부내용이 변경되더라도, Client에서의 재컴파일을 피하게 할수 있다.

다른 이름

- Compilatioin Firewall
- Cheshire Cat
- Handle body

동기

- 클래스를 작성함에 있어서, 일반적으로 Interface정의하고, 클래스내에 실제 구현 클래스를 선언해서 Interface내부에 사용하게 된다. 이때 해당 구현 클래스의 내용이 변경이 되면, 이 클래스의 인터페이스만 참조만(Dll, Lib등) 하는 Client들은 프로젝트 전체를 재 컴파일해야 되는 경우가 발생한다. 또한 클래스간의 의존성(dependency)가 늘어날수록, 작은 변경에도 컴파일 시간이 증가할수 있다.

example)

#Foo.h

#include “impl1.h”   // impl1의 변경되면, impl2.h, foo.h 역시 컴파일이 된다.

#include “impl2.h” // 이역시 마찬가지

Class foo

{

Public:

           Impl2 doSomeThing();

private:

            Impl _impl;

};

해결방법

클래스내에 두개의 구현 클래스로 추상화해서 분리한다. 첫번째로 클래스의 Interface와 구분자를 제공하고(이를 Handle이라고 한다), 두번째는 클래스의 실제 구현을 하게 된다(이를 Body라고 한다)

Example)

 more.. 
 less.. 
  
 
// file String.hpp
class StringRep; // Forward declaration only.
class String {
public:
        String();
        String(const String &s);
        String &operator=(const String &s);
        ~String();
        String(const char *s);
        . . . .
private:
        StringRep *rep; // Pointer to implementation (pimpl)
};
// file String.hpp ends here
 
// file String.cpp
#include "String.hpp"
namespace { // Anonymous namespace
class StringRep {
// This should be in a separate source file than class String, so it can be compiled
// separately, and made invisible to the client
friend class String;
        StringRep(const char *s);
        ~StringRep();
        int count; char *rep;
};
} // anonymous namespace ends
String::String() // constructors and everything else

 less..  

이렇게 Interface와 구현 분리함에 따라, 실제 구현의 내용이 변경되더라도, Interface를 참조하는 Client들의 변경 및 재컴파일이 필요없진다. DLL이나 Lib를 만들어 배포 할 때 좋은 방법이 될수 있다.

Comment

이 방법 역시 dependency를 최소화 한다는 의미에서 범용적으로 사용되는 용법이라고 볼수 있다. 그렇다고 무조건 적으로 이 방법이 효율적이라고 볼수 없는 것이 implementation이 Interface에 Pointer로 선언이 되어 있기 때문에, 구현부 어딘가에는 new/delete가 있어야 되므로, 이를 관리해야 된다는 부담이 없지 않아 있다. 또한 많이 사용되는 클래스라면, 성능상의 부담 또한 신경써야 된다. 때문에, 일반적으로 STL같은 표준라이브러리와 같이 거의 변경이 되지 않는 Object는 그냥 정의해서 사용하고, 구현 변경이 자주 되거나, 동적으로 변경될수도 있으며, 새로 개발하고 있는 구현들에서는 이 용법을 사용하는 것이 유리할것이라고 생각됩니다. 또한 pImpl을 추상화 시키면, Template Method, Factory Method등의 디자인 패턴에서 일반적으로 볼수 있는 형태가 된다.

알려진 사용 예

-       C++ 소프트웨어에서 아주 많이 사용된다.

관련된 Idioms

-       Counted Body(PImpl에서 reference counting개념을 넣었다) 위의 코드의 StringRep::count가 Counted Body에서 사용된다)

-       Smart Pointer(Pointee(라고 하나?)로 사용됨)

-       Envelope Letter(편지봉투라고 하나? -0- ) : PImle에서 구현를 추상화시켜서 사용하는 방식이라고 한다, 봉투(ADT(abstract data type)라고 한다)는 똑 같은데 내용(implementation)이 여러 개가 될수 있다는 건데, 쉽게 Template Method, Factory Method등을 생각하면 편할거 같다)

-       Handle Body Hierarchy : (먼지 모르겠다)

-       Checked delete : (delete의 안정성을 높이는 Idiom이라고 한다. Object의 type check를 통한 안전한 delete(좀 이상하다…sizeof(T)가 0이 될수도 있나? -_- ), 런타임이 아니고 컴파일 타임 체커(boost::checked_delete(), boost::check_array_delete()참조..)

-       Fast Pimpl : comment에서 언급한, new/delete의 문제를 해결 거, 동적 생성을 별도의 allocator(memory pool같은걸로)를 만들어 new/delete overloading 해서 사용한다.

More C++ Idioms 참고

Resource Acquisition Is Initialization(RAII)

- 스코크의 끝에서 자원을 해제를 보장해준다.
- 예외등에서 안전한 해제를 보장해 줄수 있다

동기

- scope(function 또는 function내에서 {} 로 지정된)내에서 new, object locking,file open등과 같은 자원들을 생성한 이후, function내에서 복잡한 분기 후 종료, 예외(exception)등에서 자원을 해제하기가 쉽지 않고, 쉽게 실수 할수 있다. Mutex나 semapore같은 동기화 오브젝트의 사용에 있어서는 어플리케이션에 심각한 Dead Lock이 발생할수도 있다.

해결방법

scope내에 클래스의 생성자에서 자원을 생성하고, 소멸자에서 자원의 해제를 하게 한다.

class AutoDelete

{

  public:

    AutoDelete (T * p) : ptr_(p) {}

    ~AutoDelete () throw() { delete ptr_; } 

  private:

    T *ptr_;

};

class ScopedLock // Scoped Lock idiom

{

  public:

    ScopedLock (Lock & l) : lock_(l) { lock_.acquire(); }

    ~ScopedLock () throw () { lock_.release(); } 

  private:

    Lock& lock_;

};

void foo ()

{

  X * p = new X;

  AutoDelete safe_del(p); // Memory will not leak

  if (...)

    if (...)

      return; 

  // No need to call delete here.

  // Destructor of safe_del will delete memory

}

void X::bar()

{

  ScopedLock safe_lock(l); // Lock will be released certainly

  if (...)

    if (...)

      throw "ERROR"; 

  // No need to call release here.

  // Destructor of safe_lock will release the lock

}

scope내에서 생성된 Object는 콜스택에 저장이 되고, scope가 종료되면서(exception이 발생했을때도 마찬가지) 소멸자가 호출되는 것을 이용해서 쉽고 편하게 자원 해제를 할수 있으며, 자원 해제의 시점도 조절할수 있다.

Comment

프로젝트 진행시 아마 가장 많이 사용되는 Idiom중의 하나 일거 같다.  아마 이름이나 내용을 모르고도 사용하는 개발자도 많을거라 생각된다.(나도 그랬다.... ;;) 하긴, 모든 Idiom들이 다 그렇치머...
 

알려진 사용 예

-       std::auto_ptr()

-       boost::scoped_ptr

-       boost::mutex::scoped_lock

관련된 Idioms

-       Scope Guard (RAII에서 자원의 Release를 사용자가 정할수 있고, 이에 대한 flag를 둠으로서 안전한 자원 해제를 보장하는 방법)

-       Reference Counting( boost::shared_ptr()같이 참조 카운트를 이용한 SmartPtr의 종료 용례를 얘기한거 같은데, 확인해 보니 맞는거 같다. Boost::shared_ptr, std::tr1:;shared_ptr)

-       Scoped Locking(RAII에서 Mutex, Semapore같은 동기화 오브젝트에서만 한정된다)

More C++ Idioms 참고