Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Making all members of pimpl classes public

Reply
Thread Tools

Making all members of pimpl classes public

 
 
werasm
Guest
Posts: n/a
 
      03-07-2006

Phlip wrote:
> werasm wrote:
>
> RCM didn't invented it.


No, Barbara Liskov did. I think references can be found in Herb Sutters
EC++.

> Until now I have avoided discussing the two /DP/ factories, because most
> programs need only Prototype, or less.


Yes, I realised we weren't talking about the same thing. You were
talking about Factory Method, I was talking about Abstract Factories.
The latter is more common for creating families of products.

> Abstract factory returns common base types for each element it creates.


Thank you for that bit of insight .

> There's no common base of all elements; there is at least one for each
> type. The example distinguishes Window with PMWindow and MotifWindow, then
> ScrollBar with PMScrollBar and MotifScrollBar. Of course Window and
> ScrollBar have no common base class. Clients of AbstractFactory are still
> insulated from PM and Motif.


Yes, I read GOF years ago. I see you use their example well.

>
> FactoryMethod encapsulates creation within a derived method. So (in C++) the
> returned type must be a member of a type hierarchy.


Yes, we weren't talking about the same thing. I was giving AFactory as
example from the start of my argument

> Can you please rename the thing you so eagerly defend to something other
> than Pimpl? I fully support defending that thing!


"The Bridge Pattern" - which makes use of the "Pimpl idiom". Yes, we
need to discern between Architectural Patterns, Design Patterns and
Idioms. Pimpl is the latter, that is used in a Design Pattern (bridge).

> And (per /DP/) there's no such thing as a "concrete interface", and designs
> should program "to the interface".


Ohhh, but you do get something with a consistent interface. Does that
require to be abstract as well? Actually, most things have consistent
interfaces. Its the implementation that varies, mostly. Read about
"Bridge Patten" - RCM tells you all about that too. I got most of my
OOP ideas from him.

> Right - polymorphism strikes again. The interface to the lib is still
> abstract, still virtual. It just might not use the virtual keyword.


Not true. Certainly not for STL and BOOST (but they not applicable in
this discussion as they are not pure OOP libs. The paradigm "generic
programming" comes into play).

> Uh, sure, if you actually need all that...


Oh, makes it alot easier for the client.

> Whyyyyyyyyy not?


Because of the paradigm shift, see.

> All interfaces should be narrow. Per RCM, there should be one, different,
> interface for each category of client to an object.


Yes, I've emphasized that already. This is a good rule of thumb.
Exceptions are always a consideration, though. As long as one knows the
pros and cons.

W

 
Reply With Quote
 
 
 
 
werasm
Guest
Posts: n/a
 
      03-07-2006

> Phlip wrote:
> > werasm wrote:


> > Right - polymorphism strikes again. The interface to the lib is still
> > abstract, still virtual. It just might not use the virtual keyword.

>
> Not true. Certainly not for STL and BOOST (but they not applicable in
> this discussion as they are not pure OOP libs. The paradigm "generic
> programming" comes into play).


Sorry, I misread what you were saying. You right - this is yet another
form of polymorphism - without the virtual keyword (at least from
clients perspective). The interface to the library is abstract in the
sense that the true implementation is only decided at runtime by the
Abstract Factory, however, as far as physical structure is concerned
(in coding terms), it is non-abstract i.e. the client instantiates a
non-abstract class. If you reason that a class is abstract just because
it aggregates abstract classes, well then yes - in that case all
classes are always abstract, because most class interface to abstract
classes.

Regards,

W

 
Reply With Quote
 
 
 
 
Phlip
Guest
Posts: n/a
 
      03-07-2006
werasm wrote:

>> Can you please rename the thing you so eagerly defend to something other
>> than Pimpl? I fully support defending that thing!

>
> "The Bridge Pattern" - which makes use of the "Pimpl idiom". Yes, we
> need to discern between Architectural Patterns, Design Patterns and
> Idioms. Pimpl is the latter, that is used in a Design Pattern (bridge).


Suppose we write a UML diagram on a whiteboard. Now you point to one box,
and say "oh, make that one a Pimpl".

I can do that by drawing a jagged line across the box and writing <<pimpl>>
on it. Expressing the trivial extra design in UML is possible, but it's
still implementation-level, below the level of the abstract design.

I can't simplify any other class's design. (Gee, of course I can simplify
their headers, and that might take pressure off them. I can't simplify them
in terms of what methods they call on our Pimpl-ed class.)

Now suppose you point to one box and say, "Escallate that into interfaces,
one for each category of clients". I shouldn't write that as a <<tag>>. I
should write some base classes, and should point the clients at them. This
provides an opportunity to simplify those classes. And, because C++ is
wonderful^W pragmatic^W vaguely utilitarian, a client that depends on an
abstract base class doesn't need to compile all the headers that its
derived class implementation needs.

You guys have gotten hung up on Pimpl as if it were a high-level design
pattern, or a good goal. It's just a technique. Clean code with a mature
design doesn't need it.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
 
Reply With Quote
 
werasm
Guest
Posts: n/a
 
      03-08-2006

Phlip wrote:
> werasm wrote:
> > "The Bridge Pattern" - which makes use of the "Pimpl idiom". Yes, we
> > need to discern between Architectural Patterns, Design Patterns and
> > Idioms. Pimpl is the latter, that is used in a Design Pattern (bridge).

>
> You guys have gotten hung up on Pimpl as if it were a high-level design
> pattern, or a good goal. It's just a technique. Clean code with a mature
> design doesn't need it.


Well, seems you know UML too :->. Congats.
Clearly, You did not read what I wrote, else your response would have
been either naught, or different. I stated that the pimpl is and idiom
e.g. a implementation technique - a use to a means. The Design Pattern
is called "The Bridge Pattern". The "C++" idiom "Pimpl" is used in C++
to implement the Bridge Pattern. What you stating is in actual fact the
exact opposite. We only use pimpl to implement a high level design
pattern (like a list is used to implement the Subject-Observer Pattern
and the SO Pattern is used to implement the MVC Architectural Pattern.
I say again and again and again. It's only an idiom. Sometimes it is
used to, as you mentioned - fix the rotten smell. Other times, it has
roles to play in good design. If you can't see this, well - so sad,
your loss.

Kind regards,

Werner
>
> --
> Phlip
> http://www.greencheese.org/ZeekLand <-- NOT a blog!!!


 
Reply With Quote
 
werasm
Guest
Posts: n/a
 
      03-08-2006
> Suppose we write a UML diagram on a whiteboard. Now you point to one box,
> and say "oh, make that one a Pimpl".


No, I would not say that. I would expect you to use the best
implementation technique for the circumstance. I'm also, like you not
interested in the details. This is however not a design group and the
details are relevant.

> I can do that by drawing a jagged line across the box and writing <<pimpl>>
> on it. Expressing the trivial extra design in UML is possible, but it's
> still implementation-level, below the level of the abstract design.


So? What has this got to do with my previous post.

> I can't simplify any other class's design. (Gee, of course I can simplify
> their headers, and that might take pressure off them. I can't simplify them
> in terms of what methods they call on our Pimpl-ed class.)


We just realise the interfaces (or the requirement), whether
implemented as abstract or not is not relevant during conceptual
design.

> Now suppose you point to one box and say, "Escallate that into interfaces,
> one for each category of clients". I shouldn't write that as a <<tag>>. I
> should write some base classes, and should point the clients at them. This
> provides an opportunity to simplify those classes. And, because C++ is
> wonderful^W pragmatic^W vaguely utilitarian, a client that depends on an
> abstract base class doesn't need to compile all the headers that its
> derived class implementation needs.


Yes, I agree with this. You mention the one case here. I will go into
my way of realising interfaces. Usually, I start with an entity (Bob).
Bob provides some services, and it requires some services. Services are
required from other entities. This realises the relationships that Bob
need to have. Some of these relationships are really vague. In some
cases I'm also not sure whether services required from particular
entities may vary at a later stage. Other entities (like STL and BOOST
lib entities) are crystal clear and I know that they wont change.
Therefore no abstraction is required when using these. A platform
peripheral like a mutex is an example of this. It's interface is known
to the extent where it has become mature enough to not change, but it
may have many implementations, which it gathers as new platforms (or
changes to platforms) comes along. In this case, the service provider
existed before the entity required it. If new implementation comes
along, Bob does not want to know about it (him wanting to be
cross-platform).

So, I have ask myself long ago - when shall I use the pimpl idiom, and
when not? I came to this conclusion.

1) When I write a class that provides a concise service but whose
implementation may vary, and this class is realised prior to his
clients requiring his realisation, to protect them from variance in
implementation, pimpl will do.

2) If I am a client (Bob) and I require services and I do not want to
be dependent on my service providers interfaces, as the likelyhood of
their interfaces varying at a later stage are great, then I will make
myself depended on interfaces defined in the same package (or
namespace, or logical organisational unit) that I'm in.

3) Another reason for pimpl - come to think of it! If I require to
execute within my own context (not within the context of the caller),
then I make use of a concrete interface whos member functions are
called synchronously. They in turn use some mechanism to call the pimpl
methods asynchronously.

.... and many more.

>
> You guys have gotten hung up on Pimpl as if it were a high-level design
> pattern, or a good goal. It's just a technique. Clean code with a mature
> design doesn't need it.


Hmmm, who ever said anything about high level design pattern. We
actually said the exact opposite. Do you even read what we write, or
are you to hung up about what you know?

Regards, of the kind sort.

W

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
microsoft.public.certification, microsoft.public.cert.exam.mcsa, microsoft.public.cert.exam.mcad, microsoft.public.cert.exam.mcse, microsoft.public.cert.exam.mcsd loyola MCSE 4 11-15-2006 02:40 AM
microsoft.public.certification, microsoft.public.cert.exam.mcsa, microsoft.public.cert.exam.mcad, microsoft.public.cert.exam.mcse, microsoft.public.cert.exam.mcsd loyola Microsoft Certification 3 11-14-2006 05:18 PM
microsoft.public.certification, microsoft.public.cert.exam.mcsa, microsoft.public.cert.exam.mcad, microsoft.public.cert.exam.mcse, microsoft.public.cert.exam.mcsd loyola MCSD 3 11-14-2006 05:18 PM
microsoft.public.certification, microsoft.public.cert.exam.mcsa, microsoft.public.cert.exam.mcad, microsoft.public.cert.exam.mcse, microsoft.public.cert.exam.mcsd realexxams@yahoo.com Microsoft Certification 0 05-10-2006 02:35 PM
microsoft.public.dotnet.faqs,microsoft.public.dotnet.framework,microsoft.public.dotnet.framework.windowsforms,microsoft.public.dotnet.general,microsoft.public.dotnet.languages.vb Charles A. Lackman ASP .Net 1 12-08-2004 07:08 PM



Advertisments