Per memorizzare i dati o no?

Question

Per memorizzare i dati o no?

#1 da (4 voti)
#2 da (1 voti)
#3 da (0 voti)

2

Vorrei chiederti una cosa semplice. Ho classe A che fa qualcosa (per esempio conta qualcosa). C'è anche una classe B che gestisce alcuni parametri per questa classe (la classe A è membro della classe B). La Classe B chiama un metodo di classe A che fa qualcosa e scrive valore nel database.

La classe A utilizza parametri ottenuti dalla classe B. La classe A ha pochi metodi per rendere il codice pulito (credo sia giusto). Ma ... Va bene salvare i parametri come membri privati ?? Non è necessario. Non devo ricordarli dopo aver scritto al Database. Ma se non ho dati privati devo gestirli su ogni metodo privato come parametri (durante l'elaborazione). Penso che sia giusto salvare questi parametri come membri di questa classe. Ho ragione? O forse dovrei evitare questo quando non è necessario (quando non devo ricordarli)?

Quando non ho membri privati il mio publicMethod (chiamato dalla classe B) è simile a questo:

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);
}

e nei metodi privati chiamo altri metodi privati e devo gestire i parametri .... Penso che non sia bello ... Ho ragione? Quando ho membri privati sembra:

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

Credo sia meglio. Ma non sono professionale e non ne sono sicuro ...

(Scrivo in C ++)

object-oriented coding-style c++

posta pawell55555 27.01.2014 - 22:01

fonte

3 risposte

1

Puoi effettivamente raggruppare i parametri in un oggetto separato e gestirli come un'unica entità. In questo modo molte domande sono molto più facili da rispondere.

Come, quali sono questi parametri? È qualche configurazione? Quindi dovrei semplicemente configurare l'oggetto una volta. O sono alcuni parametri di una query? Quindi dovrei rendere esplicito l'oggetto query, configurarlo con parametri e lasciare che la mia nuova Query elabori tutte le informazioni relative a Query. Et cetera.

Perché se i tuoi parametri vanno sempre insieme, molto probabilmente c'è qualche astrazione / entità che ti manca e che è rappresentata dal raggruppamento di questi parametri. E il suo comportamento si diffonde sottile tra gli oggetti usando questo raggruppamento di parametri.

risposta data 28.01.2014 - 09:42

fonte

0

È poco chiaro quale sia esattamente la domanda, ma se si mantengono riferimenti a variabili che non sono necessarie nell'ambito dell'applicazione, si verificherà sicuramente una perdita di memoria e alla fine esaurirà la memoria.

Considera un modello stateless come Ruby on Rails in cui la sessione è persistente nel db. Qui ogni 'stato' viene prontamente scartato / eliminato dalla spazzatura (a seconda della piattaforma per il modello stateless) e quindi qualsiasi successiva richiesta per la sessione utente viene recuperata nuovamente dal DB. Anche se questo ha dei costi di overhead (prestazioni), offre soluzioni più scalabili perché le applicazioni web non hanno bisogno di condividere la memoria attraverso un cluster.

Spero che in qualche modo risponda alla domanda.

risposta data 27.01.2014 - 22:06

fonte

Leggi altre domande sui tag object-oriented coding-style c++

Differenza tra le due enumerazioni Come integrare un secondo programmatore in un avvio [duplicato]

score 4 · Accepted Answer

Se avessi un oggetto che costruisci, chiama un metodo su di esso e lo distruggi di nuovo, allora non hai bisogno di un oggetto e quindi non dovresti averlo.

Naturalmente per logica complessa ha senso memorizzare lo stato in un oggetto. Ma può, e quindi dovrebbe, essere un dettaglio di implementazione della funzione pubblica. Quindi lo farei:

intestazione:
```
void publicFunction(int param1, int param2, int param3, int param4);
```
(la maggior parte delle funzioni dovrebbe restituire qualcosa, ma se scrive il risultato in db, restituire void in caso di successo e lanciare l'errore va bene)

fonte:

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();
     // ...
}

In questo modo la logica è strutturata internamente, incapsulata nello stato, ecc., ma in aggiunta l'intera operazione è incapsulata e nascosta.

La stessa tecnica si applica anche alle funzioni che hanno buone ragioni per essere funzioni membro. Se hanno uno stato che esiste solo fino alla fine, dovrebbe essere archiviato nello stack in un oggetto interno ausiliario, non nel invocante.

Nota a margine, se scrive nel database, probabilmente dovrebbe ottenere la connessione al database come uno degli argomenti.