Quando usiamo la programmazione orientata agli oggetti? [chiuso]

Python è un linguaggio multi-paradigma che significa che è possibile scegliere il paradigma più appropriato per l'attività. Alcuni linguaggi come Java sono OO a singolo paradigma, il che significa che avrai mal di testa se proverai a usare qualsiasi altro paradigma. I poster che dicono "usa sempre OO" probabilmente provengono da uno sfondo in un tale linguaggio. Ma fortunatamente hai una scelta!

Ho notato che il tuo programma è un'applicazione CLI che legge alcuni input (file csv e config) e produce alcuni output (file xml), ma non è interattivo e quindi non ha una GUI o API stateful. Tale programma è espresso naturalmente come una funzione dall'input all'output, che delegano ad altre funzioni per le attività secondarie.

OO d'altra parte riguarda l'incapsulamento dello stato mutabile ed è quindi più appropriato per le applicazioni interattive, le GUI e le API che espongono lo stato mutabile. Non è un caso che OO sia stato sviluppato parallelamente alla prima GUI.

OO ha un altro vantaggio in quanto il polimorfismo consente un'architettura più liberamente accoppiata, in cui diverse implementazioni della stessa interfaccia possono essere facilmente sostituite. Combinato con l'iniezione delle dipendenze, questo può consentire il caricamento basato sulla configurazione delle dipendenze e altre cose interessanti. Ciò è tuttavia appropriato per applicazioni molto grandi. Per un programma delle dimensioni di quello che descrivi, sarebbe di gran lunga troppo costoso senza alcun beneficio apparente.

A parte le funzioni che in realtà leggono e scrivono i file, la maggior parte della tua logica può essere scritta come una funzione senza effetti collaterali che prende un po 'di input e restituisce qualche altro output. Questo è estremamente facile da testare, molto più semplice di testare le unità OO in cui è necessario prendere in giro le dipendenze e altro.

In conclusione: suggerisco un sacco di funzioni suddivise in moduli per l'organizzazione, ma senza oggetti.

Considera un pulsante su una GUI. Ha lo stato (dimensioni, colore, posizione, etichetta, ecc.). Le cose possono accadere (è cliccato, ha bisogno di essere ridisegnato, ecc.). In tali situazioni, modellarlo come un oggetto ha un senso. Come oggetto, può contenere il suo stato, un insieme di azioni che possono essere eseguite su di esso (metodi) e può notificare ad altre parti dell'applicazione che le cose sono accadute sparando eventi.

OOP è uno strumento eccezionale per la gestione di GUI e altre situazioni in cui le parti del sistema hanno uno stato volatile.

Altre situazioni, come quella che descrivi, in cui i dati vengono letti da un'origine, elaborati e scritti in una destinazione sono gestiti bene da un approccio diverso: la programmazione dichiarativa (o funzionale). Il codice dichiarativo per l'elaborazione dei dati tende ad essere più facile da leggere e più breve rispetto alle soluzioni OOP.

Proprio come un martello e una sega sono entrambi strumenti potenti se usati correttamente, lo sono anche le tecniche di programmazione dichiarativa orientate agli oggetti. Probabilmente potresti martellare un chiodo in un pezzo di legno con la maniglia di una sega. Allo stesso modo, puoi spezzare un pezzo di legno a metà con un martello. Allo stesso modo, è possibile creare una GUI con funzioni e dati di processo con oggetti. Tuttavia, quando gli strumenti sono usati correttamente, i risultati sono più semplici e puliti.

La regola generale che uso è che se ho un sacco di stato, o ho bisogno di interazione con l'utente, io uso gli oggetti; altrimenti uso le funzioni (ordine puro e superiore, ove possibile).

La programmazione orientata agli oggetti aggiunge quattro nuovi strumenti al tuo arsenale:

1. Incapsulamento
2. Astrazione
3. Ereditarietà
4. polimorfismo

Utilizzerai OOP nella tua applicazione quando è diventato abbastanza grande e abbastanza complesso da trarre vantaggio da questi strumenti.

Questa domanda mi sembra un po 'confusa. Se lo stai scrivendo in Python, stai sicuramente andando a usa oggetti. Quando apri un file, restituisce un oggetto. Quando produci un risultato, restituisce un oggetto iteratore. Ogni funzione che crei è un oggetto. Interrogare il valore di OO nelle applicazioni Python sembra strano a dir poco.

Sulla base dei commenti qui, sì, Python supporta i paradigmi funzionali ma è principalmente basato sugli oggetti. Il linguaggio stesso e le librerie incorporate sono orientate agli oggetti. Sì, supporta lambda (come Java e qualsiasi altro numero di lingue definite tipicamente come OO) ma è intenzionalmente semplicistico rispetto a un vero linguaggio funzionale.

Forse queste distinzioni intorno al design di OO e al design funzionale stanno diventando obsolete. Se creo, prendo una funzione polimorfica su un oggetto progettato da OO * e passo un puntatore a quella funzione su un oggetto come parametro per la funzione con stile funzionale *, è OO o è funzionale? Penso che sia entrambi e anche un approccio davvero efficace alla risoluzione dei problemi.

Penso che la vera domanda sia 'quando dovresti iniziare a progettare le tue classi rispetto alla creazione di un modulo con funzioni?' Penso che la risposta giusta sia questa: quando aiuta a semplificare la soluzione. Darei la stessa risposta di base per qualsiasi linguaggio orientato agli oggetti.

* la ridondanza è intenzionale: non voglio essere accusato qui di presupporre che gli oggetti siano OO o che le funzioni siano funzionali.

Una delle cose più importanti della programmazione orientata agli oggetti è che invece di ragionare sul flusso del programma si inizia a ragionare sullo stato.

Molte volte vedo l'oggetto, vedo i metodi ma quello che vedo anche è che il pensiero alla base del codice è il flusso anziché lo stato.

E una volta ragionato sullo stato è facile creare un buon codice OOP perché non appena il codice diventa troppo complesso, si nota che non è più possibile ragionare sul proprio stato e sapere che è necessario refactoring.

Considera il tuo esempio: Vuoi analizzare un file CSV. Da dove viene: un file su disco. Lo carichi e lo metti in memoria e lo analizza. Ora arriva il tuo cliente: hey Voglio anche analizzare i file dal web. Quindi sei felice perché hai fatto una bella interfaccia per caricare il tuo file e devi solo creare il codice che lo preleva dal web e il resto del tuo programma rimane esattamente lo stesso.

E la cosa bella è: puoi provare per quello.

In parole povere:

• Puoi utilizzare OOP o non-OOP in qualsiasi tipo di progetto desideri.
• OOP non è la panacea, ma aiuta a gestire la complessità.
• Va oltre la modularità, riguarda la compartimentazione. Pensa ai diversi compartimenti che una nave ha per mantenere la galleggiabilità se lo scafo è danneggiato.
• OOP è un modo per gestire le dipendenze in modo che i bug possano essere più facili da rintracciare poiché esiste solo un insieme definito di modi in cui i diversi componenti di un programma possono comunicare quale altro.
• In un programma ci sono molte cose che funzionano: variabili, costanti, metodi, file, parametri, funzioni, moduli, ecc. Possono interagire tra loro in modi che a volte possono essere imprevedibili. OOP è un insieme di principi che riducono il numero di modi in cui le cose possono interagire tra loro. Non sei obbligato a usare OOP per farlo, ma aiuta.

Detto questo, ci sono altri fattori da tenere in considerazione:

• I tuoi programmatori sono esperti in OOP / OOD?
• I tuoi programmatori sono abili in un linguaggio OOP?
• Pensi che il software diventerà sempre più complesso nel tempo?
• Hai in programma di ridimensionare o riutilizzare il codice in futuro?
• Pensi che il tuo "design" possa diventare una risorsa? Sarai in grado di sfruttarlo per crescere o come base per progetti futuri?

Non fraintendermi: puoi ottenere tutto ciò senza usare OOP, ma con OOP sarà più facile.

Ma ...

Se la tua squadra non è competente in OOP / OOD e non ha esperienza in quell'area, vai con le risorse che hai.

So, my question would be: how do you guys, know/decide when to use OOP in an application?

Usalo sempre. Una volta che sei abituato a usarlo, lo userai per tutto. È un ottimo modo per garantire una buona astrazione tra le funzionalità e il loro utilizzo, il che rappresenta un vantaggio significativo per la manutenzione. Lo usiamo, ad esempio, per

• piccoli oggetti della struttura dati perché sono così spesso polimorfici, ad esempio e la struttura dei dati intermedia dopo l'analisi spesso ha più entità piccole, che hanno un comportamento comune e sono anche specializzate. Questi sono un ottimo caso d'uso per una classe base comune o un'interfaccia, con implementazioni specializzate e amp; comportamenti, cioè una gerarchia di classi (polimorfismo).

• logging, ad esempio, perché semplifica la sostituzione di un altro logger

• grandi parti della struttura del programma, perché evochi più di una simultanea, e forse approfitta di processori multi CPU. Ad esempio, un server Web può banalmente utilizzare più gestori di richieste simultanee, a causa di oggetti.

Rende più semplice il refactoring e il riutilizzo, come ho detto, incoraggia una buona astrazione, che semplifica la manutenzione. OOP dovrebbe essere abbracciato e utilizzato tutto il tempo. Una buona programmazione OOP evita metodi statici e / o dati statici e utilizza oggetti per tutto.

La programmazione orientata agli oggetti fornisce strumenti per creare framework. Questi strumenti sono incapsulamento, astrazione, ereditarietà e polimorfismo. Queste idee ti aiuteranno a dividere il tuo programma in due sezioni.

How to - Questa è la parte del frame del lavoro, dove crei una sorta di astrazione, decidi come funzionano i tuoi blocchi in generale e come interagisce con altri blocchi.

Che cosa fare - Questa parte è dove i blocchi eseguono il lavoro vero e proprio. Qui la classe è derivata dalle classi base create nella sezione "Come fare".

Uno può trarre grandi benefici da OOPS

1. se puoi riutilizzare un framework esistente e devi solo implementare dettagli specifici nella sezione "cosa fare".
2. La funzionalità che viene implementata per il progetto corrente è di tipo generico / comunemente utilizzato e altri progetti / progetti futuri possono trarre beneficio dal framework creato durante lo sviluppo del progetto corrente.
3. Abbattere progetti enormi in schemi comunemente noti per risolvere un grosso problema.
4. Utilizza OOPS anche per progetti di dimensioni ridotte per abituarti ad usarlo ed essere pronto quando arrivano 1 - 3 tipi di problemi