Consitutive class woes

[danielsbrewer]

Hi there I am trying to construct a composite class of a number of componets called Model.
One of the componets is an abstract class called Equations. An example of one of its member classes (Lorenz) copy member function is:

Equations* Lorenz::copy() const
{
return (new Lorenz(*this));
}

The simplified constructor for class Model is:

Model::Model(const Equations & equat)
:myEquation(equat.copy())
{
}

In main I make an Equations object and then an Model object i.e.

Lorenz button();
Model jelly(button);

Now the problem I have is that if I manipulate the data members of Equations from main, the Equations object in the Model object is not changed.

I checked the memory of the two Equations objects and they are different. Is there anyway to pass the actual object without changing its memory address?

Thanks

[Richard.J]

in the Model constructor, you copy the Equation object, so you should not be wondering why you got another object.

Maybe you want to store the reference to the Equation object in your Model class, but than you have to make sure that teh Equation object is valid at least as long as the Model object referencing it is.

[galathaea]

Richard.J has pointed out the source of the problem. You need to figure out which ownership policy you wish to design your object types with, and make your interface reflect these decisions. You currently have a Prototype design pattern, which (for this design) implies that the Model class owns fully created equations, and so you should build the Equation object fully before passing it to the Model object. If you want to construct the Equation object after the Model has taken ownership, you can use a Builder design pattern or in some other way place the construction of the Model into a class whose interface reflects the construction requirements of the Model and its components. It is usually best to, in some way, to control the hierarchy of ownership (the Model's state owns Equation objects and other components, and the Equation's state owns whatever it needs) by making client functions deal with the object state only and not raw objects (ie. if a client function works with Equations, pass it the equation owned by Model instead of a raw Equation built on the free store), leaving construction of the pieces to one centralized object or method that controls the assembly. This prevents the objects from falling into inconsistent state.