È una cattiva idea creare una classe che avrà solo un'istanza?

Una singola istanza per una classe ha senso se l'oggetto rappresenta una singola risorsa, ad esempio una connessione ethernet o il task manager del sistema operativo, per esempio.

Le funzioni vengono inserite in una classe solo se agiscono sulle variabili delle istanze di quella classe, altrimenti il maintainer sarà confuso riguardo l'intenzione di quella classe.

Di solito, esiste una buona ragione per cui la tua app ha variabili globali. Cerca di trovare il loro scopo comune e progetta una classe attorno a questo scopo. Non solo renderà il progetto chiaro, ma anche la tua mente.

Non c'è alcun problema con la scrittura di una classe che termina di essere istanziata una sola volta.

Se mettere insieme alcune variabili e funzioni all'interno di una classe ha senso, ha un valore semantico o rende il codice più semplice da leggere e manipolare, quindi così sia, i manutentori saranno grati.

Ciò che può essere molto sbagliato, tuttavia, è far rispettare l'unicità dall'interno.

Molte persone tendono a sparare il modello singleton non appena pensano che avranno bisogno di una sola istanza di qualcosa. Vedi ad esempio come non hai descritto il tuo contesto in profondità, ma la maggior parte delle risposte ti suggerisce già di usare un singleton. E quindi il design potrebbe essere fottuto perché se hai bisogno di un'altra istanza ad un certo punto per qualsiasi motivo, la classe ti impedirà di farlo senza modificare molto codice.

Quindi, in conclusione, un'istanza va bene, ma assicurati di sapere se:

1. tu hai solo bisogno di una istanza o
2. tu non puoi avere più di una istanza (un caso molto, molto raro nella mia esperienza).

Is it bad coding practice/design to make a class which will only be instantiated once?

No, anche se solo una volta istanziato, hai bisogno di una classe per questo. Ma non supponete che sempre abbia bisogno di una sola istanza, ora e in futuro.

Supponiamo che tu faccia un gioco e tu abbia una classe di giocatore:

class Player {
    ...
}

Istanzerai una classe di giocatori nel tuo gioco e userai sempre lo stesso oggetto. Niente di male.

Tuttavia, non farne un Singleton! Oggi progetta il tuo gioco e pensi "Beh, sarà sempre essere un gioco per giocatore singolo. Userò un Singleton per il mio giocatore". Ma nella versione 2, potresti voler implementare il multiplayer e poi ti troverai nei guai. Dovrai riscrivere e adattare un sacco di codice, perché il tuo design non supporta la creazione di istanze di più giocatori.

Lo stesso è con le cache. O logger. O interfacce di rete. Oggi pensi che ne avrai solo bisogno, sempre, di sicuro. Ma in una versione futura è necessario aggiungere un secondo. Sii consapevole di questa situazione.

Esistono classi singleton e questo è un modello di progettazione comune.

Ci sono anche classi che non vengono mai istanziate. Se si dispone di funzioni che NON funzionano su uno stato persistente (ad es. Prendono l'input e lo trasformano), di solito è possibile utilizzare un metodo statico. In alcuni linguaggi (come Java) questi metodi statici sarebbero dichiarati in una classe, ma la classe stessa non verrà mai istanziata.

Lo schema singleton è comune. Ti consente di imporre un'unica istanza di classe.

Ma per alcuni è troppo comune, quindi diventa un anti-modello. La ragione di ciò è perché è praticamente uguale allo stato globale. E qualsiasi stato globale è difficile da deridere e testare e difficile da eseguire il debug. Ma allo stesso tempo, dover passare esplicitamente questa istanza in tutto il codice può causare un notevole aumento del codice. Ma questo ti farà pensare all'architettura corretta. Se un gruppo di classi usa questo singleton, potresti essere in qualche modo collegato e creare per loro un antenato comune, che incapsulerà questa istanza per loro.

È male presumere che qualcosa sia universalmente cattivo. Nel tuo caso, forse sarebbe una buona idea, ma dato che stai usando un linguaggio che non è OO al centro, è più appropriato probabilmente usare solo metodi e variabili liberi e metterli in una libreria comune che includi nel tuo altro lavoro.

Stai facendo due domande in una.

1. No, non c'è niente di male avere una classe che avrà solo un'istanza.
2. Il raggruppamento di variabili e metodi in una classe senza una vera ragione è una cattiva progettazione.