Shared Object data

[Cogman]

BTW, thanks for all the help in the OO Design thread. Anywho.

I have a program that decomposes a string, and turns it into a fraction and then reduces the fraction using a vector of primes. Right now, the class has all the functions to decompose the string and then a separate function does the fraction reduction.

Now, part of the separate function job is to grow the prime array as needed. Now, I would really like to have this reducing fraction function as a member function for the class. My problem is that every new object will have a new set of primes and will do the same calculation for more primes over and over again.

Provided that I don't want any global variables. Basically if I know how to get the objects to keep track of themselves I could just allocate the memory off the heap for the first one and pass the pointer back for all the rest.

That, or I could just keep it a separate function from the object. Though I would like to include it because of an upcoming assignment that will need it.

 

[QuixoticOne]

Originally posted by: Cogman
BTW, thanks for all the help in the OO Design thread. Anywho.

I have a program that decomposes a string, and turns it into a fraction and then reduces the fraction using a vector of primes. Right now, the class has all the functions to decompose the string and then a separate function does the fraction reduction.

Now, part of the separate function job is to grow the prime array as needed. Now, I would really like to have this reducing fraction function as a member function for the class. My problem is that every new object will have a new set of primes and will do the same calculation for more primes over and over again.

Provided that I don't want any global variables. Basically if I know how to get the objects to keep track of themselves I could just allocate the memory off the heap for the first one and pass the pointer back for all the rest.

That, or I could just keep it a separate function from the object. Though I would like to include it because of an upcoming assignment that will need it.

I'm not totally understanding what you want to do. A lot of the time there is no "best" solution that keeps the code compact and tightly integrated. That's sort of the point of OOD, keep things compactly integrated within an object, and make that object's implementation relatively disintegrated and opaque to other objects, just expose its interfaces.

If you want to have a persistent / global type of data store object for something like a dictionary, vector, database, et. al. then you could certainly contemplate making it static and making its own object.

In other objects that are created that need to access data from your container object you could give them a reference or interface to the accessor for the container. When the container needs to grow in this case it seems to me that it can do it transparently to any Getter / accessor.
e.g.

this.FactorVector = this.FactorCalculator.GetFactorVector( this.Datum );

and the implementation of FactorContainer would check to see if it knows all of the prime factors smaller than Datum and, if not, it could calculate some more of them, add those to its container / database, and then go on about the factorization and returning the result to its accessor. So the accessing objects never know whether the calculator had to expand its container to satisfy the request, indeed they don't know if there WAS any saved state in the calculator at all, it could have just been brute-force repeating the calculation every time.

Anyway often typically you want to stick to getter, setter, factory, et. al. type of algorithmic methods rather than using data containers that themselves are shared. Though STLesque there's no harm in judiciously using overloading and generic templating to create things like iterators, vectors, et. al. of arbitrary objects if that helps.

Look more into the design patterns as well as into STL and it should be clear what templates there are for data access between objects.

Other than that familiarize yourself with static objects / data types as well as the availability of persistent object / persistent tools like persistent object databases as well as OO interfaces to non-object databases.

It would be simple enough to have a DB stored procedure method add primes into stored a table of them when needed and return a factorization as needed if you're taking a "database centric" approach to this.

 

[Markbnj]

QuixoticOne has given you a good and complete answer, if maybe a little deep given that you're just experimenting with OO.

The only thing I'll add is that you've given your own answer in your description of the problem. You clearly see that the classes with behaviors need to share some other entity that represents the data they are acting on. An OO mindset would encourage asking some questions: what is that entity? Does it have any behaviors of its own? How do the other classes access it and share it?

QuixoticOne's ideas largely address that last question.

 

[tidehigh]

properties and a property interface

 

[exdeath]

You just want all the objects to refer to a single global set of primes? A shared piece of data that all instances of the class can share so there is no duplication of common data or calculations?

See: keyword 'static' for class members.

Make the prime data a static class member, and have the object's constructor/destructor responsible for keeping a count of object instantiations (also a static counter value) to delete the static data only when the last object is deleted. Static typed members are unique and shared amongst all instances of a class; no need to pass the same pointer to new instantiations.

Constructor initializes the static member (your prime list) by allocating memory to it and initializing it if the static counter is 0, and then incrementing the counter.

Instances modify and expand this shared data as needed. The usual rules regarding shared data that can be modified by external influences applies (only use the shared static class member pointer, don't keep your own per instance pointers which may be invalidated, etc)

Destructor decrements the static counter and frees the shared member data when the counter reaches 0.

 

[hans007]

Originally posted by: tidehigh
properties and a property interface

i don tthink there are properties in c++



you should just make that reducing function a static member of the class. and call it as such (its more or less like calling a namespaced function).

it wont really have any relation to the rest of it, but if you just want them packaged together like that