Question: File `a.hpp`:

```
class a;
typedef boost::shared_ptr<a> aPtr

class a{
public:
    static aPtr CreateImp();
    virtual void Foo() = 0 ;
    ....
};

```

File `aImp.hpp`:

```
class aImp : public a{

    virtual void Foo();

};

```

File `aImp.cpp`:

```
aPtr a::CreateImp()
{
     return aPtr(new aImp());
}

void aImp::Foo(){}

```

The client must use `CreateImp` to get pointer to `a`, and can't use `a` other ways.
What do you think about this implementation?
What do you think about this kind of implementation?

Answer: 
This looks like a normal implementation if the [Factory Method](http://en.wikipedia.org/wiki/Factory_method) design pattern. The return of `boost::shared_ptr` just makes life of the programmer using this API easier in terms of memory management and exception safety and guards against simple mistakes like calling the function and ignoring the return value.

### Edit:

If this is the only implementation of the base class, then it might be that the author was aiming for [pimpl idiom](http://en.wikipedia.org/wiki/Pimpl_idiom) to hide the implementation details and/or reduce compile-time dependencies.
Looks like good encapsulation, although I don't actually see anything preventing a from being used otherwise. (For example, private constructor and friend class aImp).

No compile unit using class a will have any knowledge of the implementation details except for aImp.cpp itself. So changes to aImp.hpp won't induce recompiles across the project. This both speeds recompilation and prevents coupling, it's helps maintainability a lot.

OTOH, anything implemented in aImp.hpp now can't be inlined, so run-time performance may suffer some, unless your compiler has something akin to Visual C++ "Link-Time Code Generation" (which pretty much undoes any gain to build speed from encapsulation).

As far as the smart pointer is concerned, this depends on project coding standards (whether boost pointers are used everywhere, etc).