Progettazione software: troppi oggetti statici?

5

Informazioni sull'oggetto

Ho esitato per un po 'tra l'uso di oggetti singletons o di quelli semplici statici. Dopo aver letto molte opinioni diverse, ho fatto le mie:

If you don't need to prevent multiple creation of an object, don't use a singleton.

Quindi ho usato principalmente oggetti statici.

Contesto

Il mio programma è un programma scientifico complesso. Deve comunicare con il mondo esterno (usando zmq), produrre alcuni log e il tempo stesso per essere sicuro che tutto sia a posto.

Cosa ho fatto

Logger

Ho gestito i registri creando / distruggendo l'oggetto Logger ogni volta che ne ho bisogno. Funzioni statiche come

Logger::log() << "My Log";

costruisci l'oggetto e al momento della distruzione (fine della funzione di chiamata) viene emesso il log. E va bene!

Zmq

Poiché è necessario ovunque nel codice, la classe che implementa zmq non può essere posseduta da un oggetto. Accedo quindi a un oggetto statico creato sopra la funzione main() .

Timer

Anche in questo caso i miei timer devono essere in grado di cronometrare più funzioni ed essere stampati tutti contemporaneamente per una diagnostica più semplice: stessa soluzione per me, un oggetto TimerList statico contenente tutti i timer usati.

La domanda

Ora che sai quanto ne so del mio progetto: è un cattivo design?

Cosa faresti invece? Singletons? Qualcos'altro?

Ecco il mio main.cpp

bool READONLY;

// Must be started first to be deleted last.
zmq::context_t context(1);
zmq_ext::socket_t logSocket(context, ZMQ_PUB);
namespace TimingModule{
   TimerList tm;
}

//Must be static so that exit() do a proper deletion.
static App app;

namespace Messenger {
    Messenger messenger(context);
}

int main(int argc, char *argv[])
{
   return app.run()
}

Non esiste una risposta esatta perché è più un insieme di consigli e buone pratiche: compilare i commenti penetranti potrebbe essere una buona risposta. Ha aiutato molto. Grazie!

    
posta ochurlaud 10.05.2016 - 15:24
fonte

1 risposta

3

Non direi che stai usando un cattivo design. C'è sempre un costo nella codifica: vincere il premio più degno / più orientato agli oggetti della classe CS non è in realtà ciò che riguarda la codifica. Il codice è uno strumento, proprio come qualsiasi altro e come la maggior parte degli strumenti: si inventa gli usi per gli strumenti necessari.

Trovo più facile usare una classe statica per le cose di tipo "utility" che hai qui e quindi non sono statiche. In sostanza, devi solo ora tenere traccia di quando vengono creati, distrutti e a quale ti stai riferendo invece di ricostruire una classe singleton, che ha un formato molto diverso. Il modo in cui tendo a costruire le mie classi statiche è piuttosto simile a come tratta gli oggetti comunque, a parte alcuni dei libri contabili - quindi è più facilmente scalabile.

In breve: se non hai bisogno di complicare il tuo prodotto e hai risparmiato tempo con la tua soluzione, non c'è alcun problema con ciò che hai fatto. Man mano che diventi più esperto imparerai come maneggiare il tuo codice in modo tale che, se hai bisogno di ridimensionarlo e renderlo inatteso, hai già creato il modello per come funziona 1 in una bolla.

Non esiste una punizione più grande, tuttavia, per aver costruito una soluzione davvero non scalabile e il tuo capo ti dice il giorno dopo di averlo supportato x1000.

    
risposta data 24.05.2016 - 19:19
fonte

Leggi altre domande sui tag