OO classes design question

[Sean Dettrick]

Hi,
I have a class which I want everything to have access to, and
which I only want to construct once.
I have a hierarchy of classes:

class ScalarField{
vector<double> f;
// constructors etc
}

class VectorField{
ScalarField x; // x component
ScalarField y; // y component
ScalarField z; // z component
// constructors etc
}

class ElectroMagneticFields{
VectorField E;
VectorField B;
// constructors etc
}

Each of the Scalar, Vector, and Electromagnetic field quantities is
defined on the same simulation domain. This domain is also described
by a class. It has various methods defined for it, giving boundaries,
domain tiling methods, and a whole bunch of MPI code for parallelism
via domain decomposition:

class Domain{
junk associated with parallelism,
definitions of subdomain boundaries, etc
int crop_domain(); //example function
}

I wish to be able to apply the same domain-related
functions to each type of Field class, e.g.

ScalarField flux();
VectorField fluid_velocity();
ElectroMagneticFields EMF();

flux.crop_domain( Nx,Ny,Nz );
fluid_velocity.crop_domain( Nx,Ny,Nz );
EMF.crop_domain( Nx,Ny,Nz );

My question is this. I only wish to construct the Domain once.
I wish to have every instance of the above fields have access to
the domain class. What's the best way to do it? Private inheritance?
Making an instance of Domain a member of every Field class?
Putting a pointer to Domain in every Field class?

I do not wish to construct 30 odd instances of Domain when they
will all be the same.

Any advice would be appreciated!

Thanks,
Sean

 

[Jonathan Mcdougall]

My question is this. I only wish to construct the Domain once.

I wish to have every instance of the above fields have access to
the domain class. What's the best way to do it? Private inheritance?
Making an instance of Domain a member of every Field class?
Putting a pointer to Domain in every Field class?

Your Domain class could be a Singleton (do a google on that for more
informations) if you really want to forbid different instances.

Tour fields could have a private reference on that single instance.
Inheritance is not a good idea since you will have as many Domains as
Field object, same thing for aggregation. Putting a pointer is the
same thing as having a reference, it's just more trouble.

class Domain
{
static Domain *instance_;

// make it a singleton
Domain();
Domain(const Domain&);
Domain& operator=(const Domain&);
~Domain();

public:
static Domain &instance()
{
if ( ! instance_ )
instance_ = new Domain;

return *instance_;
}
void do_something()
{
}
};

Domain* Domain::instance_ = 0;




class Field
{
Domain &domain_;

public:
Field(Domain &domain) : domain_(domain)
{
}

void f()
{
domain_.do_something();
}
};


int main()
{
Field field(Domain::instance());

field.f();
}


Jonathan

 

[Steve Pinard]

A common criticism of Singletons is that they are not easy to destroy. This
can be a problem if you're using a tool that detects memory leaks.

An alternative to the Singleton pattern is the MonoState pattern. A
MonoState is a class whose members (data and functions) are all static.
Nothing is dynamically allocated. From your Field classes, you would refer
to the Domain functions using Domain::function syntax.

Also, you might try the comp.object newsgroup, since this post relates more
to object-oriented design than any particular C++ implementation.

HTH

 

[Jonathan Mcdougall]

A common criticism of Singletons is that they are not easy to destroy.
Why?


This
can be a problem if you're using a tool that detects memory leaks.

An alternative to the Singleton pattern is the MonoState pattern. A
MonoState is a class whose members (data and functions) are all static.
Nothing is dynamically allocated. From your Field classes, you would refer
to the Domain functions using Domain::function syntax.

This is worst : there is no point of initialization or destruction.
The user is responsible for calling an init() and a destroy()
function.

The thing with the Singleton pattern is that the initialization is
made in the instance() member and that there are quite easy ways of
making the destruction automatic.


Jonathan

 

[Sean Dettrick]

Why?

Yes I am interested in that question too.

Thanks to both of you for the advice, it is greatly appreciated.
I found Singletons in the Meyers book, effective c++, where they
get a good wrap. I will try it out.

Cheers,
Sean

 

[Rolf Magnus]

Why?

Read §10.13 of the FAQ.

The thing with the Singleton pattern is that the initialization is
made in the instance() member and that there are quite easy ways of
making the destruction automatic.

That depends on the situation.

 

[Jonathan Mcdougall]

Read §10.13 of the FAQ.

There are known ways of destroying a singleton, but I agree solving an
interdependence problem between singletons is not easy. But I don't
think this applies to the op's problem.

That depends on the situation.

Of course, but I am talking about *this* situation. Singletons
working correctly in all situations are pretty rare.


Jonathan