scegliendo tra moduli e classi

Question

Nella mia applicazione devo mantenere alcuni stati globali dell'applicazione e metodi a livello di applicazione globale come gli utenti attualmente connessi, il numero totale di risposte, creare un file di configurazione dell'applicazione ecc. Ci sono due opzioni:

1. Crea un file appstate.py separato con variabili globali con funzioni su di esse. All'inizio sembra a posto ma sembra che mi manchi qualcosa nella chiarezza del mio codice.

2. Crea un AppState di classe con funzioni di classe in un file appstate.py, tutti gli altri moduli sono stati definiti dai loro lavori specifici. Questo sembra a posto. Ma ora devo scrivere una riga più lunga come appstate.AppState.get_user_list (). Inoltre, i metodi non sono molto correlati tra loro. Posso creare classi separate ma sarebbero troppe classi.

EDIT: se uso le classi userò i metodi di classe. Non credo sia necessario creare un'istanza della classe su un oggetto.

Answer 1

Il secondo approccio sembra migliore. Vorrei usare il primo solo per i file di configurazione o qualcosa del genere.

Ad ogni modo, per evitare il problema potresti sempre:

from myapp.appstate import AppState

In questo modo non devi più scrivere la linea lunga.

Answer 2

Sembra il classico enigma :-).

In Python, non c'è niente di sporco o vergognoso nella scelta di usare un modulo se questo è l'approccio migliore. Dopotutto, moduli, funzioni e simili sono, in effetti, cittadini di prima classe nel linguaggio e offrono introspezione e proprietà che molti altri linguaggi di programmazione offrono solo con l'uso di oggetti.

Il modo in cui hai descritto le tue opzioni, sembra un po 'come se non fossi troppo pazzo per un approccio di classe in questo caso.

Non so se hai usato il framework Django, ma in caso contrario, dai un'occhiata alla documentazione su come gestisce le impostazioni. Sono a livello di app, sono definiti in un modulo e sono disponibili a livello globale. Il modo in cui analizza le opzioni ed esponendole a livello globale è piuttosto elegante e potresti trovare un tale approccio che ispira le tue esigenze.

Answer 3

Il secondo approccio è significativamente diverso dal primo solo se lo stato dell'applicazione è archiviato in una istanza di AppState, nel qual caso il reclamo non si applica. Se stai solo archiviando oggetti in una classe e usando metodi statici / di classe, la tua classe non è diversa da un modulo e sarebbe invece pitone averlo effettivamente come modulo.

Answer 4

Perché non andare con un'istanza di quella classe? In questo modo potresti anche essere in grado di avere in seguito 2 diverse sessioni di "quotazioni". in esecuzione, a seconda dell'istanza utilizzata. Potrebbe renderlo più flessibile. Forse aggiungi qualche metodo get_appstate () al modulo in modo che installi una volta la classe. In seguito, se si desiderano più istanze, è possibile modificare questo metodo per accettare un parametro e utilizzare un dizionario, ecc. Per memorizzare tali istanze.

Puoi anche usare i decoratori di proprietà tra l'altro per rendere le cose più leggibili e avere la flessibilità di archiviarle come e dove desideri.

Concordo sul fatto che sarebbe più pitonico usare l'approccio del modulo invece dei metodi di classe.

A proposito, non sono un grande fan di avere cose disponibili a livello globale da alcuni "magici". Preferirei usare una chiamata esplicita per ottenere tali informazioni. Quindi so da dove vengono le cose e come eseguirne il debug quando le cose falliscono.

Answer 5

Considera questo esempio:

configuration
|
+-> graphics
|   |
|   +-> 3D
|   |
|   +-> 2D
|
+-> sound

La vera domanda è: qual è la differenza tra classi e moduli in questa gerarchia, in quanto potrebbe essere rappresentata con entrambi i mezzi?

Le classi rappresentano i tipi. Se si implementa la soluzione con classi anziché moduli, è possibile controllare un oggetto grafico per il tipo corretto, ma scrivere funzioni grafiche generiche.

Con le classi è possibile generare valori parametrizzati. Ciò significa che è possibile inizializzare in modo diverso la classe suoni con un costruttore, ma è difficile inizializzare un modulo con parametri diversi.

Il punto è che sei davvero qualcosa di diverso dal punto di vista della modellazione.

Answer 6

Vorrei seguire il percorso delle classi in quanto organizzerà meglio il tuo codice. Ricorda che per leggibilità puoi farlo:

from appstate import AppSate

Answer 7

Preferirei sicuramente la seconda opzione: avendo già usato la prima, ora sono costretto a refactoring, poiché la mia applicazione si è evoluta e devo supportare più costrutti modulari, quindi ora ho bisogno di gestire più configurazioni simultanee '.

Il secondo approccio è, IMO, più flessibile e a prova di futuro. Per evitare le righe di codice più lunghe, è possibile utilizzare da AppState import AppState invece di import appstate .