C'è qualche ragione per usare le classi in Python se c'è una sola classe nel programma?

Question

Ho visto alcune persone che scrivono il codice Python con la creazione di una classe e poi un oggetto per chiamare tutti i metodi. C'è qualche vantaggio nell'usare le classi se non utilizziamo l'ereditarietà, l'incapsulamento, ecc.? Un tale codice mi sembra meno pulito con tutti questi argomenti di "sé", che potremmo evitare. Questa pratica è influenzata da altri linguaggi di programmazione come Java o esiste una buona ragione per cui i programmi Python dovrebbero essere strutturati in questo modo?

codice di esempio:

class App: 

# all the methods go here 

a = App()  

Answer 1

Un vantaggio, anche se non sempre applicabile, è che rende più semplice per estendere il programma per la sottoclasse una classe. Ad esempio, posso eseguire la sottoclasse e sovrascrivere il metodo che legge, ad esempio, un file csv per leggere un file xml e quindi creare un'istanza della sottoclasse o della classe originale in base alle informazioni di runtime. Da lì, la logica del programma può procedere normalmente.

Ciò naturalmente solleva la questione se la lettura del file è in realtà una responsabilità della classe o più propriamente appartiene a una classe che ha sottoclassi per la lettura di diversi tipi di dati e presenta un'interfaccia uniforme a quei dati, ma cioè, certo, un'altra domanda.

Personalmente, trovo che il modo più pulito per farlo è di mettere le funzioni che fanno forti ipotesi sui loro parametri sulla classe appropriata come metodi e di mettere funzioni che fanno ipotesi molto deboli sui loro argomenti nel modulo come funzioni.

Answer 2

Mi capita spesso di fare lo stesso io stesso per i gestori parti di un app che, in teoria, potrebbe essere ridotto a semplice, molto sequenziale, la programmazione funzionale.

Il vantaggio principale (per me) è che incapsula bene il ciclo principale o l'esecuzione in esecuzione una sola volta e consente di configurare i dati di esecuzione e permanenza in modo efficiente e pulito su blocchi, riconfigurandolo fondamentalmente come necessario senza dover cambiare il codice stesso. Per non parlare della possibilità di creare sottoclassi di un'esecuzione in una diversa ed estesa.

Inoltre tende ad essere molto più facile per espandere il principale in questo modo, allora è quando si dispone di un solido blocco di 200 linee gettando intorno roba piuttosto criptico ambito.

L'io, dopo aver scritto abbastanza Python, si allontana come un impedimento, e personalmente mi piace come offra immediatamente una distinzione visiva tra ciò che ovviamente voglio perseverare attraverso gli ambiti, e che cos'è un elemento usa e getta che VUOI finire fuori dal campo di azione e essere raccolto non appena un particolare passo è fatto.

Ultimo ma non meno importante, alcune persone oggetto orientare qualsiasi cosa mettere le mani su, o non sarà in grado di leggerlo. Io sono uno di loro :)

Answer 3

1. So di un uso per questo.

Anche se questo può essere ottenuto con altri mezzi. Assicura che entrambi i moduli - module_B e module_C utilizzino la stessa istanza di App e non istanziano oggetti separati.

In module_A.py

class App: 
    .... 

a = App() 

In module_B.py

from module_A import a 

In module_C.py

from module_A import a 

Ovviamente, è possibile creare oggetti separati, ma quello non era l'intenzione dei moduli precedenti.

E se avete fatto quanto segue in module_D.py

from module_A import App 
a = App() 

2. [Pedantic]

Si potrebbe evitare l'uso di classi e decomporre la soluzione utilizzando solo moduli e funzioni. Ma non sembrerà brutto in un grande programma. Non vorresti usare il paradigma orientato agli oggetti nel tuo programma. Tutte le lingue offrono un certo modo per sfruttare OO. A tutti noi piacciono alcune cose o l'altra e alcuni ci respingono. Esplicito è meglio che implicito è di solito il modo Python. Anche se questa non è una buona ragione per la sua inclusione.

Answer 4

C'è qualche vantaggio nell'utilizzo delle classi se non facciamo uso di ereditarietà, incapsulamento ecc.?

Sì.

questa pratica un'influenza da altri linguaggi di programmazione come Java

No.

Ci

alcuna buona ragione per cui i programmi Python dovrebbero essere strutturati in questo modo?

Sì.

Tuttavia. Dalla tua domanda, hai chiaramente deciso che "Tale codice mi sembra meno pulito con tutti questi argomenti 'auto'".

Non ha molto senso spiegare i vantaggi di una dichiarazione di classe se sei già sicuro che sia "meno pulito".

Considerate questo.

1. Uno script non è mai statico.
2. Un design senza classe dovrà essere modificato.
3. A un certo punto, le modifiche porteranno a una seconda classe.

Bottom-line.

È possibile lavorare senza una lezione per brevi momenti. Fino a quando non apporti modifiche. Quindi ti pentirai di non avere la parola class e tutti quegli argomenti auto "sporchi".

Alla fine li aggiungerai.

Perché aspettare?

Answer 5

Tendo ad usare le classi quando penso che sia probabile che avrò bisogno di più istanze di qualcosa, o se penso che ereditare da esso sarà utile. Se sto solo cercando un modo per raggruppare le funzioni e le impostazioni correlate che influiscono sul loro comportamento, beh, un modulo può funzionare altrettanto bene, con meno sintassi.A volte userò entrambi gli approcci nello stesso modulo.

Inoltre, sebbene sia possibile scrivere decoratori e gestori di contesto come classi, personalmente tendo a trovarli più chiari se scritti come funzioni, quindi è così che generalmente li scrivo.

Python è un linguaggio di programmazione multi-paradigma. Usa qualsiasi approccio tu ritenga esprima il tuo intento in modo più chiaro. Non hai mai necessario per utilizzare OO.

Un approccio che mi piace usare è pensare a come vorrei che le varie funzionalità mi fossero fornite se qualcun altro stava per scrivere un modulo per risolvere un problema come il mio in modo generico. Fondamentalmente, cerco di progettare prima le interfacce tra i miei moduli e renderli il più possibile semplici e facili da usare. A questo punto, inizia a rendermi chiaro quale approccio dovrei usare per ogni bit di funzionalità.

Ma io sono solo un ragazzo e la programmazione non è il mio lavoro principale.