0

I am trying to write a simulation that has multiple (20+) variables, which the user should be able to control without modifying the source code. Currently I'm stuck between two design choices: Should I use one big class or multiple smaller class? Should I use a map/dict, or a class?

Example,

class Car:
  class Engine:
    horsepower = 700;
    max_acceleration = 1.5;
    max_speed = 220;
    ...
    func calc_speed(); # 50+ lines. Calls multiple Engine functions.
  class Brake:
    ...
    func reduce_speed(); # 50+ lines. Uses some results from Engine.
  class FuelTank:
    ...
  
  func run();

The issue with using multiple classes:

  • Brake needs to know the result of Engine calculations, and perhaps even some variables.
  • The user needs to be able to update the variables before, and during, the simulation. The code to do so will be all over the place, checking each individual class.

The issue with only one class:

  • Car needs to store some 20+ variables, and all of the functions from all of the subclasses. The number might increase once I expanded the scope of the simulation.

Now, there is another underlying issue with plain variables stored in classes:

  • Each user update, defined before runtime as timestamps, will require invoking some (20+) getters/setters, or I have to use reflection. It is ok in python, but gets uglier with more classes, and languages without reflection (e.g., C++).

I am trying replace plain variables with a dictionary:

  • I do not expect the dictionary to grow at runtime. It does not feel right to have one dictionary store multiple unrelated variables. The only sensible name I can come up with is dict_engine, dict_brake, etc.
  • I might need to store user functions. Again, ok with python, but map<string, int+std::function>?

Thank you.

3
  • @J_H you have enough rep to be able to edit it directly
    – Alexander
    Commented Sep 30, 2023 at 21:16
  • @J_H Wrote too many switch statements, it is done now.
    – z.x.99
    Commented Sep 30, 2023 at 21:34
  • Just write code and refactor it later. A lot of the kinds of structure that makes sense doesn't become apparent until you've become intimate with the problem space- and that requires just writing code. Don't overthink it. Your first guess is probably wrong anyway.
    – Beefster
    Commented Oct 3, 2023 at 19:21

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.