🚀 go-pugleaf

Not to start a flame fest, I hope, but the best reference on this kind of
thing is probably:

Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
Design Patterns: Elements of Reusable Object-Oriented Software.
Addison-Wesley, 1997. ISBN 0-201-63361-2

However, if you look at some of the applicable patterns such as Adapter and
Bridge, you may find less justification for your position than you might
think. "Wrapping" the C functions doesn't really achieve much for you in
practice without the accompanying redesign/reimplementation using OO design
techniques. Just packaging the functions into an interface (Adapter) has
the main purpose of providing an interface needed by something else (stress
"needed" here--unless your code is already written to require the
interface, it isn't really needed, as you can just call the C functions
directly in the implementation). If the C functions are a solid, reusable
implementation, then the Bridge pattern may apply: "Decouple an abstraction
from its implementation so that the two can vary independently." The key
here is to abstract the C functions into objects so that you can change the
C functions later without changing the interface. This probably also goes
beyond just "wrapping" as you need to generalize a sufficiently robust
abstraction that will survive reimplementation and can be reused in many
different domains.

Hope this helps!
  --Bob Muller

Jeffrey K Regan wrote:

> Can anybody help??
>
> I am in the rather interesting position of having to explain the value
> of object oriented programming to a large corporate architecture team.
> Specifically, I need to explain to them the value of wrapping
> collections of C functions into C++ classes.
>
> Can anybody help me with references that I can use to supplement my own
> explanations? I still cannot believe I am reduced to explaining this
> kind of fundamental thing to a corporate system architecture team. Go
> figure!