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 ElectroMagnetic Fields{
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( );
ElectroMagnetic Fields EMF();

flux.crop_domai n( 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]

Re: OO classes design question

>My question is this. I only wish to construct the Domain once.[color=blue]
>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?[/color]

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::instanc e_ = 0;




class Field
{
Domain &domain_;

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

void f()
{
domain_.do_some thing();
}
};


int main()
{
Field field(Domain::i nstance());

field.f();
}


Jonathan

[Steve Pinard]

Re: OO classes design question

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::functio n syntax.

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

HTH

--
Steve Pinard

"Dr. Spock is the only Star Wars character I know"
- My Mom




-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

[Jonathan Mcdougall]

Re: OO classes design question

On Sat, 26 Jul 2003 12:21:30 -0400, "Steve Pinard"
<sNO_SPAMpinard @zoominternet.n et> wrote:
[color=blue]
>A common criticism of Singletons is that they are not easy to destroy.[/color]

Why?

[color=blue]
> 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::functio n syntax.[/color]

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]

Re: OO classes design question

Jonathan Mcdougall <DELjonathanmcd ougall@yahoo.ca > wrote in message news:<fgb5iv848 c2n3mhg6aon10c7 2c8e1ukhs9@4ax. com>...[color=blue]
> On Sat, 26 Jul 2003 12:21:30 -0400, "Steve Pinard"
> <sNO_SPAMpinard @zoominternet.n et> wrote:
>[color=green]
> >A common criticism of Singletons is that they are not easy to destroy.[/color]
>
> Why?[/color]

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]

Re: OO classes design question

Jonathan Mcdougall wrote:
[color=blue]
> On Sat, 26 Jul 2003 12:21:30 -0400, "Steve Pinard"
> <sNO_SPAMpinard @zoominternet.n et> wrote:
>[color=green]
>>A common criticism of Singletons is that they are not easy to destroy.[/color]
>
> Why?[/color]

Read §10.13 of the FAQ.
[color=blue]
> 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.[/color]

That depends on the situation.

[Jonathan Mcdougall]

Re: OO classes design question

On Sun, 27 Jul 2003 11:24:25 +0200, Rolf Magnus <ramagnus@t-online.de>
wrote:
[color=blue]
>Jonathan Mcdougall wrote:
>[color=green]
>> On Sat, 26 Jul 2003 12:21:30 -0400, "Steve Pinard"
>> <sNO_SPAMpinard @zoominternet.n et> wrote:
>>[color=darkred]
>>>A common criticism of Singletons is that they are not easy to destroy.[/color]
>>
>> Why?[/color]
>
>Read §10.13 of the FAQ.[/color]

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.
[color=blue][color=green]
>> 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.[/color]
>
>That depends on the situation.[/color]

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


Jonathan