0

I'm currently working on a program, a scientific simulation, with the following structure (first level - logical grouping, second level - implemented classes, third level - implemented subclasses):

  • Input Data
    • Sample
    • Parameter (abstract base class, declaring virtual functions)
      • ParModel1
      • ParModel2
      • ...
  • Physical Models
    • Model (abstract base class, declaring virtual functions)
      • Model1
      • Model2
      • ...
  • Simulation
    • Simulation

The Model subclasses (e.g. ModelX) define certain algorithms in a virtual Calculation(int x) function, representative for the physical model X to be described. The parameters to be used in this calculation will be provided by a Sample object and a respective ParModelX object. The Simulation class knows how to deal with a Model in general and will eventually perform the calculation for a given x (by calling the public Calculation(int x) function)... in a biiig for-loop.

We approach the actual question... During each iteration, the calculation defined by the ModelX will be performed and thus various parameters of the Sample and ParModelX objects need to be accessed.

Since the Simulation class only triggers a provided public calculation function of Model, it's only Sample and Parameter which both have to communicate with Model.

Should I...

  1. Have the members declared private and provide get-functions? (I read that heavy dependence on getters/setters can be a sign of flawed design. Could too many get function calls be a problem in an ample for loop or is it "bad style" respectively?)
  2. Have the members declared 'public' but const (they won't need to change!) so that 'Model' can access them without a function call? (Doesn't look like good style to me...)
  3. Let the Model constructor extract the parameters from given Sample and Parameter objects and store them in its own members for quick access (this would make the Parameter class redundant!)
  4. friend Sample and Parameter (etc.) with the according Models
  5. other options...?

I'm concerned about the speed (even if it may not be important in my particular calculation, I want to know what would be good programming style!) and the structure of my program. I, for instance, don't want the models to be mixed with the simulation/calculating process. The separation of input data and models seemed good to me, because of the possibility to have many parameter sets for one model...

LCsa
  • 607
  • 9
  • 30
  • _"Poor design, since all members would need getters? Performance issues because of multiple get-calls during one iteration at many iterations?"_ Sorry, but that's nonsense. Who told you so? – πάντα ῥεῖ Jan 02 '15 at 16:26
  • @πάνταῥεῖ I wasn't actually told so, but in a lot of comments to questions and links I read that class design which is based on the usage of get and set functions can be considered a poor one at that (considering encapsulation, etc.). And so far I agree on that, at least to a certain extent. Now, nothing wrong about gets/sets, if they are necessary, though. I just wonder (my question) if they are in my case, or if there may are better options I haven't yet considered. – LCsa Jan 02 '15 at 21:02
  • @πάνταῥεῖ So would you say that I should just write getters for all simulation relevant members (which are *all* members, actually)? It would be nice to have some input from someone with more experience in class design (for this type of problem). – LCsa Jan 03 '15 at 22:55
  • If you really want to have pure [POD](http://stackoverflow.com/questions/146452/what-are-pod-types-in-c) 's all along, you may to forego getter/setter functions. Though consider something like [protobuf](https://developers.google.com/protocol-buffers/docs/reference/cpp/) generated classes, which even (consciously) deny appearing as POD structs. It totally depends on what your actual requirements for passing parameter data around your sytstem are, and what kind of interfaces you have along your building blocks. (That's the reason why I close voted your question as being _"too broad"_ here). – πάντα ῥεῖ Jan 03 '15 at 23:26
  • @πάνταῥεῖ I tried to make my program structure and thus requirements quite clear in my question (to avoid "too broad"). The virtual `Calculation(int x)` function of a `Model` object has to access the members of the given `Sample` and `Parameter` objects (which are part of said `Model` class). Often and quickly. Those objects _can_ perform minor actions (so no real POD classes). I even provided my trains of thoughts to reduce the "too broad" problem, a comment or a recommended decision could maybe help. So far, I just know that one out of four ideas contains a misconception. (...) – LCsa Jan 04 '15 at 00:53
  • (...) "forego getter/setter in case of PODs" --> does this statement speak for options 2 or 3 for instance? Is the question of speed redundant in this case? I, personally, think that this/my question is not too broad to be answered. At least to gain a conceptual feeling of which approach to choose and why or why not. – LCsa Jan 04 '15 at 00:56

1 Answers1

2

All of this depends on a whole lot of circumstances, so please be cautious with the following general considerations.

As long as you don't know that you are facing performance issues, I would definitely favor well-structured design over performance optimization—you'll thank yourself if you ever need to come back to this code, e.g., if you need to extend it somehow. Separating data structures from objects which operate on them certainly sounds like a valuable idea. Introducing constant values, hoping for better performance while sacrificing the ability to use different sets of values in your computation, sounds like a bad idea. Personally, I'm fond of getters and setters because they provide an interface for accessing data while abstracting how the data is represented internally. I wouldn't expect a big performance hit from them, they are even likely to get "optimized away" by the compiler. The friend keyword is an access modifier and (other than some compiler-specific black magic) probably won't have a big impact on performance—I've only ever used it in the context of unit testing.

When thinking about performance bottlenecks in your scenario, my gut feeling tells me to rather watch out for things like passing around big data structures by value and unnecessary re-calculations instead of reusing intermediate results. And if you are truly interested in performance insights, stop guessing, grab one of those profiling tools and start measuring!

Community
  • 1
  • 1
vsa
  • 80
  • 6
  • My aim is to keep all code well-structured and well written. "Well written" shall stand for "efficient, economic and by all rules in the book". From what I read, I concluded that a class which relies on getters/setters entirely could indicate a design problem. Maybe this is not true... (?) As I wrote, the parameters will not change during a simulation, but I definitely agree with you that `const`ing them sacrifices opportunities. (I didn't like the idea from the start...) And the classes will be further developed. (...) – LCsa Jan 04 '15 at 17:32
  • (...) `friend` was more a question of access regulation than of performance, but well... too many friends don't prove thought-out design either. I will take care of using references or pointers where passing by value is not necessary. From what you wrote it should be somewhat of options 1 or 3 in my question, I assume? And it seems that I shouldn't worry about several get-function calls in a for loop may be too "slow"? This is actually why I even thought about making the parameters available by other means than getters. Thank you. – LCsa Jan 04 '15 at 17:41
  • 1
    Beware of [premature optimization](http://programmers.stackexchange.com/questions/80084/is-premature-optimization-really-the-root-of-all-evil) when you consider trading getters/setters for public members. – vsa Jan 04 '15 at 19:29
  • 1
    I think the biggest downside of getters/setters is actually that in most languages you need to write them out—C# is an example of a programming language that endorses the usage of properties by providing language features such as [automatic properties](http://msdn.microsoft.com/en-us/library/bb384054.aspx)). But in terms of maintainability public fields are clearly the much greater evil. – vsa Jan 04 '15 at 19:35