Hi, today I discussed a specific design decision for the core library
of forthcoming products in our company. My colleague started hiding
the use of those libraries (for example boost) used by the core
library using wrapper (can be typedefs, classes, additional
interfaces). He justifies this with the pain that may arise when
interfaces of these base libraries change. Additionally he argues that
this is best practice.

This seems a bit ridiculous to me because :

- Additional testing and documenting will be necessary.
- This interface will always stay incomplete. In case a project needs
a functionality that hasn't been wrapped this wrapping must be done
beforehand.
- It's a bit like the "Mushroom Management" anti-pattern. Keep
developers in the dark, don't let them taste really good libraries.

Anyone heard of such a best practice and is able to explain it ?

Regards,
cr8

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Aug 14, 5:17 pm, c...@arcor.de wrote:
> Hi, today I discussed a specific design decision for the core library
> of forthcoming products in our company. My colleague started hiding
> the use of those libraries (for example boost) used by the core
> library using wrapper (can be typedefs, classes, additional
> interfaces). He justifies this with the pain that may arise when
> interfaces of these base libraries change. Additionally he argues that
> this is best practice.
>
> This seems a bit ridiculous to me because :
>
> - Additional testing and documenting will be necessary.
> - This interface will always stay incomplete. In case a project needs
> a functionality that hasn't been wrapped this wrapping must be done
> beforehand.
> - It's a bit like the "Mushroom Management" anti-pattern. Keep
> developers in the dark, don't let them taste really good libraries.
>
> Anyone heard of such a best practice and is able to explain it ?

Unfortunately, my company also does this heavily. Moreover, they don't
just do it for outside libraries, they also do it for internal
libraries. When I start debugging code, I have to descend through 2-5
different indirection layers because they're afraid a change, internal
or external, will break the code. I posit that maintaining this extra
code associated with the layering outweighs the benefits.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

cr8@arcor.de wrote:

> Hi, today I discussed a specific design decision for the core library
> of forthcoming products in our company. My colleague started hiding
> the use of those libraries (for example boost) used by the core
> library using wrapper (can be typedefs, classes, additional
> interfaces). He justifies this with the pain that may arise when
> interfaces of these base libraries change. Additionally he argues that
> this is best practice.
>
> This seems a bit ridiculous to me because :
>
> - Additional testing and documenting will be necessary.
> - This interface will always stay incomplete. In case a project needs
> a functionality that hasn't been wrapped this wrapping must be done
> beforehand.
> - It's a bit like the "Mushroom Management" anti-pattern. Keep
> developers in the dark, don't let them taste really good libraries.

I would say it depends. Is this library meant for internal delivery within
the company or is it for external customers ? In the latter case
I would agree with your colleague. It's not about forbidding
your customers the taste of good code but to have as much control
over the interface as possible.

Otherwise years later you end up with a lot of fruitless communication
with your costumer that for function foo he/she has to use the
type boost::bar instead of boost::foobar as of version 1.5.x.
A lot of the concept of OO programming boils down to the idea
of hiding the internals of an algorithm. Not because it's so precious or
patented but to keep everything in manageable units.

If it's for internal use only it's more a question of company
culture and good code documentation. Then I would agree
with you that an open infrastructure might be beneficial
because this kind of hiding might end up in a situation
where only one or a few "very bright" egg-heads know about
the internals and if these suddenly drop dead or out others
might have a hard time understanding what these people were actually
coding between all these internal typedeffing and class
encapsulations.


O.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 15 Aug, 01:17, c...@arcor.de wrote:
> Hi, today I discussed a specific design decision for the core library
> of forthcoming products in our company. My colleague started hiding
> the use of those libraries (for example boost) used by the core
> library using wrapper (can be typedefs, classes, additional
> interfaces). He justifies this with the pain that may arise when
> interfaces of these base libraries change. Additionally he argues that
> this is best practice.
>
> This seems a bit ridiculous to me because :
>
> - Additional testing and documenting will be necessary.
> - This interface will always stay incomplete. In case a project needs
> a functionality that hasn't been wrapped this wrapping must be done
> beforehand.
> - It's a bit like the "Mushroom Management" anti-pattern. Keep
> developers in the dark, don't let them taste really good libraries.
>
> Anyone heard of such a best practice and is able to explain it ?

{ Edits: quoted sig and banner removed. Our banner is automatically appended to
every article, including this one. So, no need to quote it! :-) -mod }

My arguments against this are quite simple:

1) People maintaining your code will probably know "Widely accepted
libraries".
2) You can hire people who know "Widely accepted libraries".
3) "Widely accepted libraries" are generally well documented.
4) "Widely accepted libraries" are well tested in practical use.
5) "Widely accepted libraries" are well supported by the development
community on the internet.

against this you have:

1) Nobody knows your warpper library except the guy who wrote it.
2) The documentation is almost certainly inadequate and/or wrong and
the poor maintainer is the guy who will find this out.
3) It's unlikely to be well tested.
4) There will be no support if you have a problem.
5) You've paid a cost that you have no real reason to believe that you
will ever recover - At the very least you should have a rudimentary
cost/benefit analysis to justify this. In the same way that you can
say that code is not reusable until it has been reused you can say
that a library is not wrapped until the underlying interface has
changed drastically and you've shown that this involved minimal cost.
6) You tend to introduce unwanted coupling, usualy through some
"global typedefs header" that make it difficult to reuse single
classes without changes.

The only time I tend to use wrappers is to use thin wrappers to make C
libraries object oriented - primarily to handle construction and
destruction and to do "Resource acquistion is initialization" (e.g. I
usually wrap pthreads for construction and locking).


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 15 août, 02:17, c...@arcor.de wrote:
> Hi, today I discussed a specific design decision for the core library
> of forthcoming products in our company. My colleague started hiding
> the use of those libraries (for example boost) used by the core
> library using wrapper (can be typedefs, classes, additional
> interfaces). He justifies this with the pain that may arise when
> interfaces of these base libraries change.

Boost, and probably other good libraries, don't change interfaces
without good reason to do so.
I actually find that a pain, because there are some bad interfaces
that exist for historical reasons.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Thu, 14 Aug 2008 18:17:34 CST, cr8@arcor.de <cr8@arcor.de> wrote:
> Hi, today I discussed a specific design decision for the core library
> of forthcoming products in our company. My colleague started hiding
> the use of those libraries (for example boost) used by the core

> library using wrapper (can be typedefs, classes, additional
> interfaces). He justifies this with the pain that may arise when
> interfaces of these base libraries change.

I don't know Boost well, but I assumed such high-quality stuff aimed
for backwards compatibility ... not being released until after
extensive review and so on.

If libraries I use change so often that it hurts me, then I'd try to
avoid them altogether.

And is a wrapper really useful as protection against interface
changes? In my limited experience, a change which actually does
something significant forces real changes in the actual client code.

> Additionally he argues that
> this is best practice.
>
> This seems a bit ridiculous to me because :
>
> - Additional testing and documenting will be necessary.
> - This interface will always stay incomplete. In case a project needs
> a functionality that hasn't been wrapped this wrapping must be done
> beforehand.
> - It's a bit like the "Mushroom Management" anti-pattern. Keep
> developers in the dark, don't let them taste really good libraries.
>
> Anyone heard of such a best practice and is able to explain it ?

I recognize the tendency to do that. I have seen C wrappings of the
POSIX file I/O API which just generated a new, cumbersome way of doing
what everybody already *knew* how to do using open(), close(), write()
etc.

That's one argument against wrapping -- you lose the positive effects
of using a well-known API which the developers may already know, which
they might have a *desire* to have in their CV, and which you can
Google for.

Related to that tendency, there's also the tendency in some projects
to create an "alternate universe" where special rules apply: all
functions must return type OurErrorCode; the integral types are
forbidden in favor of OurBool, OurUInt32 etc ... That also forces you
to wrap libraries to make them fit.


Of course, I happily wrap C APIs, for additional type safety, RAII and
so on. And if I need a Foo container with functionality which is a
subset of std::vector<Foo>, I happily create a FooContainer class which
provides that functionality and nothing more. But that is hardly
wrapping, is it?

/Jorgen

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

cr8@arcor.de wrote:
> Hi, today I discussed a specific design decision for the core library
> of forthcoming products in our company. My colleague started hiding
> the use of those libraries (for example boost) used by the core
> library using wrapper (can be typedefs, classes, additional
> interfaces). He justifies this with the pain that may arise when
> interfaces of these base libraries change. Additionally he argues that
> this is best practice.
>
> This seems a bit ridiculous to me because :
>
> - Additional testing and documenting will be necessary.
> - This interface will always stay incomplete. In case a project needs
> a functionality that hasn't been wrapped this wrapping must be done
> beforehand.
> - It's a bit like the "Mushroom Management" anti-pattern. Keep
> developers in the dark, don't let them taste really good libraries.
>
> Anyone heard of such a best practice and is able to explain it ?
>
> Regards,
> cr8
>

Choosing to wrap or not wrap libraries is a decision between instant and
long term gratification. If you choose to imbibe large amounts of
alcohol at a time, do not be surprised when you get a hangover the next
morning. Likewise, you may save a little time in the short term by not
wrapping libraries, but it can cause a real pain farther down the road.

If an entire software product uses a third party library, directly, then
the *ENTIRE* piece of software will have to be updated, if it becomes
necessary to switch from that third party library to an alternative
third party library. By contrast, if the third party library has been
wrapped, then only the code which does the wrapping would need to
change. While it is unlikely that widely accepted libraries would change
in a breaking manner, there are some practical reasons why it might
become necessary to switch from one third party library to another:

1.) Licensing. A newer third party library may offer a cheaper or less
restrictive license than the license associated with the one in use.

2.) Efficiency. A newer third party library may offer greater speed or
may take up less space than the one currently in use.

3.) Compatibility. A newer third party library may support more
platforms than the one currently in use.

To give a practical example, a company might initially begin development
with Qt. However, the Qt license is somewhat expensive, and in order to
keep down the software price, the company may decide to use WxWidgets.
If all the code used Qt directly, this switch could be a real pain. All
the developers would have to devote their efforts to this switch. If,
however, a wrapper were used, then only the developers working on the
wrapper would need to make changes, while the rest of the developers
could continue working on the project, completely unaffected.

(Apologies to the developers at Trolltech for this example).

- Michael Safyan

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Michael Aaron Safyan wrote:
> cr8@arcor.de wrote:
> > Hi, today I discussed a specific design decision for the core library
> > of forthcoming products in our company. My colleague started hiding
> > the use of those libraries (for example boost) used by the core
> > library using wrapper (can be typedefs, classes, additional
> > interfaces). He justifies this with the pain that may arise when
> > interfaces of these base libraries change. Additionally he argues that
> > this is best practice.
> >
> > This seems a bit ridiculous to me because :
[ lots of good reasons snipped ]

Agreed.

> Choosing to wrap or not wrap libraries is a decision between instant and
> long term gratification.

This presumes that the gratification will come and you know when (more
or less).

> If an entire software product uses a third party library, directly, then
> the *ENTIRE* piece of software will have to be updated, if it becomes
> necessary to switch from that third party library to an alternative
> third party library.

The question is, how likely is this to occur. The example of Qt is a
good one IMO. Qt requires a licence when deployed in commercial
applications. I reckon that makes it a good candidate for wrapping.
Other open source libraries such as boost, ACE, etct etc have a more
permissive license. IMO this means that wrapping those libraries is un-
necessary. In those cases it would only be advisable if the project
had a history of changing its public interface. And some open source
projects do that for various reasons.

I find myself on a project at the moment where they have wrapped ACE
and boost! IMO this is needless level of indirection that is merely
adding to the learning curve.

> While it is unlikely that widely accepted libraries would change
> in a breaking manner, there are some practical reasons why it might
> become necessary to switch from one third party library to another:
>
> 1.) Licensing. A newer third party library may offer a cheaper or less
> restrictive license than the license associated with the one in use.

I reckon this is the most important reason.

> 2.) Efficiency. A newer third party library may offer greater speed or
> may take up less space than the one currently in use.

This seems dubious to me. Efficiency ought to be thought about when
choosing/evaluating a library. Assuming the efficiency is ok when you
start then it would only change if you were tracking the evolution of
that library. In which case you would detect when the efficiency
dropped, raise it as an issue and stick with the previous version
until the issue was resolved. Being open source you can always apply
any patches for bugs to your forked copy.

> 3.) Compatibility. A newer third party library may support more
> platforms than the one currently in use.

Again, this is something that should be considered when the library is
being evaluated. And if it is open source then if a new porting
requirement comes along then a port is in theory possible. You could
even contribute the port back to the community!

Regards,

Andrew Marlow

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Aug 19, 1:40 am, Michael Aaron Safyan <michaelsaf...@aim.com>
wrote:
> c...@arcor.de wrote:
> > Hi, today I discussed a specific design decision for the core library
> > of forthcoming products in our company. My colleague started hiding
> > the use of those libraries (for example boost) used by the core
> > library using wrapper (can be typedefs, classes, additional
> > interfaces). He justifies this with the pain that may arise when
> > interfaces of these base libraries change. Additionally he argues that
> > this is best practice.
>
> > This seems a bit ridiculous to me because :
>
> > - Additional testing and documenting will be necessary.
> > - This interface will always stay incomplete. In case a project needs
> > a functionality that hasn't been wrapped this wrapping must be done
> > beforehand.
> > - It's a bit like the "Mushroom Management" anti-pattern. Keep
> > developers in the dark, don't let them taste really good libraries.
>
> > Anyone heard of such a best practice and is able to explain it ?
>
> > Regards,
> > cr8
>
> Choosing to wrap or not wrap libraries is a decision between instant and
> long term gratification. If you choose to imbibe large amounts of
> alcohol at a time, do not be surprised when you get a hangover the next
> morning. Likewise, you may save a little time in the short term by not
> wrapping libraries, but it can cause a real pain farther down the road.
>
> If an entire software product uses a third party library, directly, then
> the *ENTIRE* piece of software will have to be updated, if it becomes
> necessary to switch from that third party library to an alternative
> third party library. By contrast, if the third party library has been
> wrapped, then only the code which does the wrapping would need to
> change. While it is unlikely that widely accepted libraries would change
> in a breaking manner, there are some practical reasons why it might
> become necessary to switch from one third party library to another:
>
> 1.) Licensing. A newer third party library may offer a cheaper or less
> restrictive license than the license associated with the one in use.
>
> 2.) Efficiency. A newer third party library may offer greater speed or
> may take up less space than the one currently in use.
>
> 3.) Compatibility. A newer third party library may support more
> platforms than the one currently in use.
>
> To give a practical example, a company might initially begin development
> with Qt. However, the Qt license is somewhat expensive, and in order to
> keep down the software price, the company may decide to use WxWidgets.
> If all the code used Qt directly, this switch could be a real pain. All
> the developers would have to devote their efforts to this switch. If,
> however, a wrapper were used, then only the developers working on the
> wrapper would need to make changes, while the rest of the developers
> could continue working on the project, completely unaffected.
>
> (Apologies to the developers at Trolltech for this example).

This example only works if the wrapper interface remains unchanged in
the switch between WxWidgets and Qt. My contention is that unless the
wrapper was explicitly designed to abstract away the difference
between WxWidgets and Qt, it will be impossible to move from Qt to
WxWidgets without changing the interface.

Furthermore, if the wrapper /was/ designed to abstract away the
difference between WxWidgets and Qt, then it still wouldn't be
possible to move to (for example) MFC if one decided that a more
"native" approach was required on Windows.

In other words, by using a wrapper, one ends up with the short-time
term pain of writing the wrapper /and/ the long term pain when one
wants to change library!

The right solution to this particular example is to separate business
logic from UI. The business logic can then be reused for Qt,
WxWidgets, Web UI, or even command-line tools.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

cr8@arcor.de wrote:
> Hi, today I discussed a specific design decision for the core library
> of forthcoming products in our company. My colleague started hiding
> the use of those libraries (for example boost) used by the core
> library using wrapper (can be typedefs, classes, additional
> interfaces). He justifies this with the pain that may arise when
> interfaces of these base libraries change. (...)
>

Personally I think that it's a real waste of effort to wrap a *complete*
third party library, no matter how "widely accepted" it is.

However, sometimes a project only uses a certain, small, subset of a
given library and within the project it may make sense to wrap that up,
since the usage of the specific library does not match other project
guidelines. -- On the other hand, I found in these cases the usage of
the library will be in only a very small fraction of code, so then it's
not worth to wrap it, as it's only used at a few places :-)

The real question with all libraries that may be used "all over the
project" - like, say, boost or an xml library is how to manage an plan
beforehand for library upgrades. I think time and energy may be much
better invested in thinking on how one could upgrade module A to lib_x
1.36 while staying with lib_x 1.33.0 for module B.

br,
Martin


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]