Databases
StackOverflow2013
Postsdbo
POsetters and getters with heavily nested composition
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POsetters and getters with heavily nested composition
    primarykey
    data
    text
    <p>I study the dynamics of multibody systems and am trying to apply OO techniques to my work in modelling various mechanical systems. One thing I am encountering in my work is that I it makes sense to create several building block classes that are used as private member variables in higher level classes that represent more complicated systems. </p> <p>What I'm struggling with is that a common task is in numerical analysis is parameter analysis -- essentially looking at how the behavior of a system changes as you vary it's parameters. With the hierarchical nesting imposed by composition, what is the best way to allow for fine grain control of the parameters in the private member variables that comprise a more complicated object? Returning a reference I know is frowned but the only other alternative I see is to either reconstruct the high level objects repeatedly or to provide a lot of wrapper setters/accessors which set/get the private member data (and perhaps have some logic to ensure data integrity).</p> <p>Here is a typical example:</p> <pre><code>template &lt;typename T&gt; class fooA { public: /* setters, getters, etc... */ private: T w,x,y,z; }; template &lt;typename T&gt; class fooB { public: /* setters, getters, etc... and maybe ways to set/get private members of type class A */ private: T d, e, f, g, h; fooA&lt;T&gt; i, j, k; }; </code></pre> <p>What would be the best (or preferred) way to adjust the w, x, y, z, data of the private i, j, k members of the fooB class? Write setters/getters in the fooB class, or return a reference, or something else? A common use case in my application is to want to do a parameter on the w, x, y, z quantities of the i member of a fooB instance.</p> <p>EDIT: The object I am modelling is a bicycle, which I describe with a total of 31 parameters. 30 of those parameters have a front and rear analog, so I chose to make a class to represent those 15 parameters, then have the bicycle class have two of these as private member variables. 11 of those 15 parameters can be grouped into a set of parameters which can makes sense to into its own class, so again, I group those into a class and make it a private member of the class with 15 parameters. And within that class, 6 of those 11 parameters can further be lumped into their own class. So, I have essentially four levels of nesting. So, if a client of the highest level bicycle class wants to adjust one of the parameters in the lowest level (which is a typical use case in my application), they can:</p> <ul> <li>construct a whole new object, passing the new parameter in the constructor</li> <li>I can provide setters / getters at some level of granularity, perhaps all the way down to the lowest level. If I provide setters at the smallest level of granularity, my high level class becomes a bit of mess, and as has been mentioned by many posts, this is probably not a good design. But I'm not sure how to allow the access otherwise.</li> </ul> <p>Perhaps I should flatten the hierarchy and make all of the various classes I mentioned into member variables of the top level bicycle class, rather than nesting them so much? This would result in more member variables of the bicycle class, but less nesting, and would make the writing of the setter/getter for the bike class more straightforward. Thoughts? </p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. UShazelnusse
    1. UShazelnusse
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. COWhy is returning a reference a problem? As long as you know what you're doing, this should not be a problem. You could make operator= of fooA private if you do not need it, to ensure assignment to a getter is impossible.
      singulars
      1. POsetters and getters with heavily nested composition
      1. USRuud
    2. CO@RuudvA, Returning a reference to say, the i member of a fooB instance, is a problem when i, j, k, d, e, f, g, h, need to be validated anytime one of them changes. By this I mean that even if i, j, k are consistent on their own, there may be additional constraints in the class fooA that need to be satisfied -- so i, j, k can't be set to arbitrary (yet consistent in an isolated case) things.
      singulars
      1. POsetters and getters with heavily nested composition
      1. UShazelnusse
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload