python: sovraccarico sull'utilizzo di classi anziché di dizionari?

Question

Per prima cosa, vorrei sottolineare che conosco i concetti OOP e capisco le differenze tra dizionari e classi. La mia domanda riguarda il senso del design in questo caso:

Sto progettando una webapp in python e devo rappresentare qualcosa come un oggetto libro. I libri hanno capitoli e capitoli hanno titoli e contenuti. Per semplicità, diciamo che il contenuto è in chiaro.

La mia domanda è, dovrei fare le lezioni di libri e capitoli o dizionari? So che sarebbe più bello usare book.chapter invece di book ['chapter'], e se finirò per avere dei metodi in futuro, potrebbe aver senso metterli nella classe del libro. Tuttavia, mi piacerebbe sapere se c'è un sovraccarico nell'utilizzo di classi invece di memorizzare le informazioni nei dizionari?

Se non desidero istanziare un oggetto libro da un database ogni volta e memorizzarlo come un sottaceto, dovrei essere preoccupato per l'incompatibilità con gli oggetti del libro passato se aggiungo/rimuovi membri dati da una classe. Penso che sarebbe più facile affrontare questo problema nei dizionari. Qualche suggerimento su se/quando ha senso usare i dizionari invece delle classi?

Answer 1

Gli oggetti sono stati originariamente creati per raggruppare i dati con funzionalità. Se vuoi solo memorizzare i dati, usa i dizionari. Se vuoi includere metodi per manipolare i dati, usa gli oggetti.

Answer 2

Qualche considerazione:

1. Se si inizia con un dizionario, è sempre possibile passare ad una classe personalizzata in seguito che implementa il protocollo di mappatura (o sottoclassi dict). Quindi è probabilmente un buon punto di partenza.

2. È possibile definire oggetti Python personalizzati per utilizzare __slots__, che sarà più veloce e più efficiente in termini di memoria se si dispone di un numero elevato di oggetti.

3. Se si utilizza un oggetto Python personalizzato, sarà più facile sostituirlo in futuro con un oggetto scritto in C. (Non l'ho mai provato, ma mi sarei aspettato che la sottoclasse di C fosse un proposta difficile)

Answer 3

Tipo di simile al vostro problema:. Returning an object vs returning a tuple

non c'è altra scelta netta. I dizionari sono veloci, simpatici e puliti. Dopotutto, le istanze di classe sono un dizionario speciale. Se vuoi fornire un modo per aggiungere funzionalità e modificare la tua interfaccia in un secondo momento, una classe sarebbe la scelta migliore, ma la sovrastampa di qualcosa di semplice è sempre una cattiva scelta. Python non è java, in cui tutto deve essere un'istanza di una classe creata correttamente. Questo è un peccato che cado anche io.

Answer 4

Se si va con gli oggetti, non memorizzare i dati raccolti nel database semplicemente per i motivi che hai fornito. Sarebbe molto peggio se ti fossi sottoposto a un cambio di lingua o simile.

FWIW, vorrei iniziare con un dizionario. Se le cose si complicano o sono necessarie nuove funzionalità, trasformale in un oggetto.

Answer 5

Questo è altamente improbabile che sia il collo di bottiglia nella vostra applicazione, quindi preoccuparsi delle prestazioni è probabilmente una perdita di tempo. Tuttavia, se questo è il collo di bottiglia o hai solo un po 'di tempo a disposizione, cerca di usare uno namedtuple.Combina l'immutabilità e l'impronta di memoria ridotta di un tuple con la bella sintassi degli attributi di classe.

Answer 6

In realtà si riassumono abbastanza bene i trade-off. Sembra che molte persone si preoccupino troppo presto delle prestazioni. Piuttosto che ripetere il consiglio standard sull'argomento, ti suggerisco di cercare nel web "Ottimizzazione prematura di Knuth". Il fatto è che per gli oggetti della struttura nota si sarà molto più felici di utilizzare oggetti basati su classi rispetto a dicts.

Ancora una volta, il desiderio di non creare un'istanza di oggetti ogni volta che i loro dati (di istanza) vengono letti nel database rappresenta un'attenzione leggermente malsana per le parti sbagliate della progettazione del programma. La creazione di un'istanza di una delle classi dagli attributi dei dati richiede pochissimo tempo e la convenienza di poter aggiungere comportamenti attraverso i metodi merita la leggera complessità aggiuntiva.

L'utilizzo di un dict con indici costanti per fare riferimento agli elementi di un oggetto dati mi sembra sbagliato. Si sta effettivamente emulando il meccanismo dei namespace di Python e si creano molte costanti di stringa non necessarie (che non necessariamente saranno consolidate dall'interprete). Se sei davvero interessato alla velocità allora perché non usare una lista, con costanti simboliche per i nomi dei campi? Risposta: perché sarebbe errato contorcere il codice in questo modo per un aumento potenzialmente illusorio della velocità di esecuzione che nel 99% di tutti i casi (una figura che ho appena strappato dal mio culo) non verrà notato perché il l'applicazione non è comunque associata alla CPU.

Scrivi il tuo programma nel modo più semplice per sapere come. Se funziona e funziona abbastanza velocemente, passa all'attività successiva.