Re: How to design an object to get references to other needed objects?
itaj sherman wrote:
My question concerns some kind of an idiom that is very common in code
I've worked with. Maybe I misuse the word idiom here, I'm not sure. In
code I have seen 3 different designs for such cases. It is quite a
simple problem, but yet, I was never fully content with any of these
3. I tried to think of a way to do it somewhat better. Differences
between these 4 designs (4 together with mine), affect the API of the
module being designed (therefore affect the user's code). Also they
affect the performance and the memory usage. Maybe not by much, but
sometimes I need to cover cases that require high performance.
First, there is no silver bullet. There are likely many solutions that
depend on many factors. Sometimes (but less often than you think)
performance trumps. Sometimes, safety and robustness trump. Most of the
time it is a weighting between all constraints.
First I'll describe the module requirements, then the guidelines for
the 4 designs, then I'll explain the differences I find between them
with respect to user code, performance and memory usage. After these I
added a test program with the code for these 4 designs and user code.
If the text here seems to long, you may just skip directly to the
code. It is written not for a real world case, but just has the
necessary to demonstrate the problem. If you read design2 in namespace
ModuleWithMemberReferences and UserCodeWithMemberReferences you'll
understand what the module needs to do, and how my example user wants
to use it. Then you can read design4 in namespace
ModuleWithTemplateParameter and UserCodeWithTemplateParameter to see
how I made it more efficient.
<metacomment>Unless you're writing an introduction to a book or the
abstract of a paper, don't write about what you're going to write about.
We'll figure it out as we read :-) </metacomment>
I would like your opinions about these. Do you think my design is
useful at all? Can it be improved?
The module requirements:
Let's say I'm designing a module that has one class A, the API
contains 2 member functions A::f1, A::f2 and 2 global functions g1,
g2, that manipulate objects of A.
basically:
//pseudo code
namespace TheModule
{
class A
{
public: A();
//member functions
public: void f1();
public: void f2();
};
void g1( A& a );
void g2( A& a );
};
Moreover, operations on an object of A need some configuration. During
the lifetime of an object of class A, it needs to use two other
objects, "configuration objects", that would be given by the user of
this module, and will configure certain behaviors of the object of
class A. In here I call them configuration object of type X, and
configuration object of type Y.
So, because the class A needs to somehow refer to these objects, it
has to be a template class, parametrized by the user.
This statement is not necessarily true. You might also use dynamic
polymorphic objects. This may be preferred if binary-size is more
important than runtime-speed. It may also be necessary if the
configurations must be interchangeable at runtime.
So I change the design to:
//pseudo code
namespace TheModule
{
template< typename MyX, typename MyY >
class A
{
public: A();
//member functions
public: void f1();
public: void f2();
};
template< typename MyX, typename MyY >
void g1( A< MyX, MyY >& a );
template< typename MyX, typename MyY >
void g2( A< MyX, MyY >& a );
};
This design is still incomplete. The problem is that f1,f2,g1,g2 also
need to access an instance of MyX and an instance of MyY. Note, as I
said, that the user of this module is supposed to supply these
objects, and they stay fixed for a certain instance of A for its
lifetime.
The constraint is that I must let the user be able to decide when to
create the instances of MyX and MyY, how many to create, and which of
them will be "attached" to a specific instance of A.
For example: A could represent a node of some tree-like data-
structure, like an XML document. It needs to have a reference to its
direct parent node (that would be MyX), and to an object that
represents the whole document (that would be MyY).
Another example: A is some data-structure. During a lifetime of an
object of type A, it needs to use an object that does the memory
allocation (that would be MyX). This has only 1 configuration object.
I choose to talk about a class that needs 2 configuration objects, to
better demonstrate the effect that it has on the code in the different
designs. For the same reason I choose to have 2 function members and 2
global functions.
In this abstract design, the module expects MyX to have a member
function as such:
public: std::string someXFunctionality();
And expects MyY object to have:
public: std::string someYFunctionality();
But in real situations these complex API and functionality may be
needed.
My question here is how to desine the API of this module to do that.
That is, to enable the user to "attach" instances of MyX and MyY to an
instance of A.
The common OO approach to this problem is to have A have a connection to
(reference or pointer) the MyX and MyY objects. If you know that those
objects are available at the time of the A class initialization, then
make them constructor arguments. If not, then make setter methods for them.
This is what this idiom is about - in what way the user passes these
configuration objects to the module.
Here are the 3 designs I've seen that people use (you can see the full
code of each in the program at the end of my post):
design1: Using parameters. All the functions A::f1, A::f2, g1, g2 and
A::A will receive two more parameters ( ..., MyX& x, MyY& y ), and use
them.
This is not OO. It may be valid design for functional programming, but
even then it is dangerous. If A needs x and y to be the same objects
across calls, then you've added burden to the client of your code, along
with greater potential for bugs.
design2: Using reference members. A::A() will receive references to
its configuration objects as: A::A( MyX& x, MyY& y ), and the A
instance will keep these references in reference data members for use
by all other functions of the module.
This is actually the preferred approach.
design3: Using virtual functions. Add two pure virtual member
functions to A, the user will inherit A and override them to return
references to the instances of MyX and MyY. The constructor of A will
still have to receive them as parameters, because it can't use the
virtual functions.
This doesn't really make sense as an approach. Especially since "the
constructor of A will still have to receive them as parameters." Not to
mention it adds a lot of unnecessary coupling between the client and
your code.
such as:
template< typename MyX, typename MyY >
class A
{
public: A( MyX& x, MyY& y );
public: virtual MyX& vGetMyX() = 0;
public: virtual MyY& vGetMyY() = 0;
...
};
Note that the virtual functions are not used to implement
polymorphism, but just as the means to enable the user to configure
the behavior of the class.
This is still polymorphism, but an arguably poor use of it.
and my suggestion:
design4: Add another template parameter to template class A. such as:
template< typename MyX, typename MyY, typename ObjectParametrization
class A
{
...
};
ObjectParametrization will be a traits class that is expected to have
two static member functions that retrieve the instances of MyX and
MyY. The user will have to define such a parameterization class and
implement these functions correctly to retrieve the MyX and MyY
instances he assigned for this instance of A.
such as:
class CertainUserObjectParametrization
{
typedef A< CertainX, CertainY, CertainUserObjectParametrization >
A;
public: static CertainX& GetMyX( A& r );
public: static CertainY& GetMyY( A& r );
};
In fact this design actually decouples the usage of the MyX and MyY
instances which is in the code of this module's function, from the way
this code gets the pointers to these objects.
I think this is an overly complicated approach. It might be useful for
some situation, but I doubt it is any more useful than a constructor or
a pair of setter methods.
Hope my suggestions help.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>