d****p 发帖数: 685 | 1 I recently got confused about one thing.
Previously I have class design as:
class IFoo { ... } // abstract class
class Foo1 : public IFoo { ... }
class Foo2 : public IFoo { ... }
Recently all the code was modified by a colleague as:
class IFoo { ... }
class Foo1 { Impl *pImpl ... }
class Foo1::Impl { ... }
In short, the implementation was moved from Foo to Foo::impl, which
is an internal class.
What's the benefit of doing so? To me this is not nice since Foo is
suppose to be implementat | t****t 发帖数: 6806 | 2 usually pimpl idiom is to hide the implementation details and break the
compile-time dependency.
but i guess you already know that.
【在 d****p 的大作中提到】 : I recently got confused about one thing. : Previously I have class design as: : class IFoo { ... } // abstract class : class Foo1 : public IFoo { ... } : class Foo2 : public IFoo { ... } : Recently all the code was modified by a colleague as: : class IFoo { ... } : class Foo1 { Impl *pImpl ... } : class Foo1::Impl { ... } : In short, the implementation was moved from Foo to Foo::impl, which
| d****p 发帖数: 685 | 3 Thanks - but that's why I am confused.
If its purpose is to decouple any units include-ing Foo.h and Foo's
actual implementation, the situation already justifies promoting Foo into
a higher level as abstract class such as IFoo.
So basically it is
abstract(IFoo) - semi abstract (Foo) - solid (Foo::Impl)
vs
abstract (IFoo) - abstract (IFoo) - solid (Foo).
Maybe I am missing sth but I deem the second concept is cleaner.
Hmm seems the 1st approach does have merit - its instan
【在 t****t 的大作中提到】 : usually pimpl idiom is to hide the implementation details and break the : compile-time dependency. : but i guess you already know that.
|
|