OO classes design question

Discussion in 'C++' started by Sean Dettrick, Jul 26, 2003.

  1. 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!

    Sean Dettrick, Jul 26, 2003
    1. Advertisements

  2. My question is this. I only wish to construct the Domain once.
    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(const Domain&);
    Domain& operator=(const Domain&);

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

    return *instance_;
    void do_something()

    Domain* Domain::instance_ = 0;

    class Field
    Domain &domain_;

    Field(Domain &domain) : domain_(domain)

    void f()

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


    Jonathan Mcdougall, Jul 26, 2003
    1. Advertisements

  3. Sean Dettrick

    Steve Pinard Guest

    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.

    Steve Pinard, Jul 26, 2003
  4. This is worst : there is no point of initialization or destruction.
    The user is responsible for calling an init() and a destroy()

    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 Mcdougall, Jul 26, 2003
  5. 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.

    Sean Dettrick, Jul 27, 2003
  6. Sean Dettrick

    Rolf Magnus Guest

    Read §10.13 of the FAQ.
    That depends on the situation.
    Rolf Magnus, Jul 27, 2003
  7. 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.
    Of course, but I am talking about *this* situation. Singletons
    working correctly in all situations are pretty rare.

    Jonathan Mcdougall, Jul 28, 2003
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.