private implementation class vs derived class

Hi,

My team is encouraging people only have public API present in the
public header file and put the implementation class into the source
directory like this:

<package directory>
i/: all the header files are here and each header file only has
class like this:
class A_Impl;

class A{
public:
A();
API1();
API2();
private:
A_Impl* m_pImpl;
}

s/: all the source files are here and implementation class header
files are also here.

The benefit is each time you change implementation class, there is no
re-compile consequence on other classes. Another benefit is the
implementation is not exposed.

It works well for me in the beginning, but after a while I see
problem. Using the above example, if I have class B derived from class
A and class B and its implementation class needs to access data of
A_Impl, it is not convenient. Here are the reasons:

1. I need to declare a bunch of Get() and Set() in class A while I
know their consumer is pretty much class B. This seems not necessary.

2. I can change m_pImple to protect from private, but this requires
class B in same directory as class A_Impl, this requirement is little
too much.

My questions are as following:

A. Should I take #1 solution as a reasonable compromise? Or in this
case I should move data from A_Impl to protect of class A.

B. In addition to the 2 benefits I listed above, is there any other
benefit using this private implementation technique? My software
source code is not visible to customer, I do not see the 2nd benefit,
hide implementation from others.

C. In addition to the 2 solutions I listed above, is there any other
solution? The private data in A_Impl could be some fairly complex data
structure such as stl::vector and stl::map.

Thanks a lot!

1230987za@gmail.com wrote:

> My team is encouraging people only have public API present in the
> public header file and put the implementation class into the source
> directory like this:
>
> <package directory>
> i/: all the header files are here and each header file only has
> class like this:
>
class A {
public:
A();
API1();
API2();
private:
class Impl;
Impl* m_pImpl;
};

> The benefit is each time you change implementation class, there is no
> re-compile consequence on other classes. Another benefit is the
> implementation is not exposed.
>
> It works well for me in the beginning, but after a while I see
> problem. Using the above example, if I have class B derived from class
> A and class B and its implementation class needs to access data of
> A_Impl, it is not convenient.

Also, note that if you had class B contain a member of A, and B needed
access to the data of A_Impl, it would be the same "problem" wouldn't it.

> My questions are as following:
>
> A. Should I take #1 solution as a reasonable compromise? Or in this
> case I should move data from A_Impl to protect of class A.

Neither.

> B. In addition to the 2 benefits I listed above, is there any other
> benefit using this private implementation technique? My software
> source code is not visible to customer, I do not see the 2nd benefit,
> hide implementation from others.

A google search for "pimple idiom" will will provide a pretty
comprehensive list of benefits and drawbacks.

> C. In addition to the 2 solutions I listed above, is there any other
> solution? The private data in A_Impl could be some fairly complex data
> structure such as stl::vector and stl::map.

Ask yourself, why isn't A taking care of its own internals? Why must B
muck about in them?

While you are pondering that, read up on the brittle base class problem.
(http://www.research.att.com/~bs/bs_f...abstract-class)

On 1 sep, 02:09, 123098...@gmail.com wrote:

>
> The benefit is each time you change implementation class, there is no
> re-compile consequence on other classes. Another benefit is the
> implementation is not exposed.

> B. In addition to the 2 benefits I listed above, is there any other
> benefit using this private implementation technique? My software
> source code is not visible to customer, I do not see the 2nd benefit,
> hide implementation from others.
>

1.Off course, re-compilation does not depends on where are located the
source files.
2.You must understand that private implementation technique is not
used to prevent someone to see your implementation but to reduce the
maintenance cost of your programs. If you can guarantee that the
object state cannot be modified in some ways then you reduce the
number of tests to be written.
3. If you are in a team where people want to hide part of the
implementation, then how can you be sure that what you develop is
based on something that work correctly ! Did you found people that
never make mistakes in their codes ? I think, It's very important to
share the code in order to debug it and to have an external point of
view of what you are doing. IMHO, working alone is not efficient.