To store data or not?

Question

I'd like to ask you about one simple thing. I have class A that do something (for example counts something ). There is also one class B that handle some parameters to this class (class A is member of class B). Class B calls one method of class A that does something and writes value to database.

Class A uses parameters that got from Class B. Class A has few methods to made clean code (it's good I think). But... Is it ok to save parameters as private members?? It's not necessary. I don't have to remember them after writing to Database. But if I don't have private data I have to handle it to every private method as parameters (during processing). I think that it's ok to save this parameters as members of this class. Am I right? Or maybe I should avoid this when it's not necessary (when I don't have to remember them)?

When I don't have private members my publicMethod (called from class B) is looked something like that:

void publicMethod(int param1, int param2, int param3, int param4)
{
    privateMethod1(param1, param2, param3, param4);
    privateMethod2(param1, param2, param3, param4);
    privateMethod3(param1, param2, param3, param4);
}

and in private methods I call other private method and I have to handle parameters.... I think it doesn't look good... Am I right? When I have private members it looks like:

void method(int param1, int param2, int param3, int param4)
{
    privateMethod1();
    privateMethod2();
    privateMethod3();
}

It's better I guess. But I'm not professional and I'm not sure...

(I write in C++)

Answer 1

If you'd have an object that you would construct, call one method on it and destroy it again, than you don't need an object and therefore shouldn't have it.

Of course for complex logic it makes sense to store the state in an object. But it can, and therefore should, be an implementation detail of the public function. So I'd do:

• header:

  void publicFunction(int param1, int param2, int param3, int param4);
  

  (most functions should return something, but if it writes the result to db, returning void on success and throwing on error is fine)

• source:

  namespace {
      class privateImplementation {
          friend void publicFunction(int, int, int, int);
          int param1;
          int param2;
          int param3;
          int param4;
          int state;
          // ...
          void privateMethod1();
          void privateMethod2();
          // ...
      };
  };
  
  void publicFunction(int param1, int param2, int param3, int param4)
  {
       privateImplementation impl{param1, param2, param3, param4, 0};
       impl.privateMethod1();
       impl.privateMethod2();
       // ...
  }
  

This way the logic is internally structured, state encapsulated etc, but additionally the whole operation is encapsulated and hidden away.

The same technique applies also to functions that have good reasons to be member functions. If they have state that only exists until their end, it should be stored on the stack in an auxiliary internal object, not in the invocant.

On a side note, if it writes to database, it probably should be getting the database connection as one of the arguments.

Answer 2

You can actually group parameters into a separate object and manage them as a single entity. This way a lot of questions are much easier to answer.

Like, what are these parameters? Is it some configuration? Then I should just configure the object once. Or is it some parameters of a query? Then I should make query object explicit, configure it with parameters, and let my new Query process all the Query-related stuff itself. Et cetera.

Because if your parameters always go together, most probably there is some abstraction/entity that you are missing, and which is represented by the grouping of this parameters. And its behaviour is spread thin between objects using this grouping of parameters.

Answer 3

It's a little unclear exactly what the question is, but if you hold references to variables you don't need in the scope of the application, you will certainly encounter a memory leak and eventually run out of memory.

Consider a stateless model such as Ruby on Rails where the session is persisted in the db. Here any 'state' is readily discarded/garbage collected (depending on the platform for the stateless model) and then any subsequent request for the user session is retrieved again from the DB. While this has some overhead (performance) costs, it does offer more scalable solutions because the web applications don't need to share memory across a cluster.

I hope that somewhat answers the question.