Quando utilizziamo effettivamente la programmazione orientata agli oggetti? [chiuso]

Sto scrivendo un programma in Python, che sostanzialmente manipola le stringhe, e mi chiedevo se avrei dovuto farlo usando i principi OOP o meno. Il cliente ha dirmi che non si preoccupa per il codice, lui vuole solo la cosa fatta .

So che il codice orientato agli oggetti non è per definizione più pulito, e al contrario il codice non OO non è per definizione scadente. La domanda che sto ponendo potrebbe essere più o meno basata sull'opinione, ma potrebbero esserci alcune regole di cui non sono a conoscenza.

Altre informazioni su cosa fare:

• analizzare un .csvfile ed elaborare i dati in base a un file di configurazione (le colonne possono essere diverse, ad esempio nel numero di colonne o nei dati in loro possesso)
• utilizzare i dati elaborati sopra per creare nuovi dati formattati personalizzati (o più file basati su alcuni dei valori sopra)
• usa gli ultimi dati formattati per creare un file XML.
• dividere il file XML in più XMLs in base al loro contenuto
• l'applicazione dovrebbe essere basata sulla CLI
• ci sono ovviamente altre cose come: la registrazione di alcuni eventi, l'analisi degli argomenti della CLI e così via.

Ora, questa non è affatto un'applicazione grande / difficile, ed è anche quasi finita, ma durante l'intero processo di sviluppo continuavo a chiedermi se questo dovesse essere fatto usando OOP o no.

Quindi, la mia domanda sarebbe: come fate, sapete / decidete quando usare OOP in un'applicazione?

Python è un linguaggio multi-paradigma che significa che puoi scegliere il paradigma più appropriato per l'attività. Alcuni linguaggi come Java sono OO a singolo paradigma, il che significa che otterrai mal di testa se provi a utilizzare qualsiasi altro paradigma. I manifesti che dicono "usa sempre OO" probabilmente provengono da un background in una tale lingua. Ma per fortuna hai una scelta!

Prendo atto che il tuo programma è un'app 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 con stato. Tale programma è naturalmente espresso in funzione da input a output, che delegano ad altre funzioni per attività secondarie.

OO d'altra parte riguarda l'incapsulamento dello stato mutabile ed è quindi più appropriato per applicazioni interattive, GUI e API che espongono lo stato mutabile. Non è un caso che OO sia stato sviluppato parallelamente alle prime 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. In combinazione con l'iniezione delle dipendenze, ciò può consentire il caricamento di dipendenze e altre cose interessanti basate sulla configurazione. Questo è principalmente appropriato per applicazioni molto grandi. Per un programma delle dimensioni di ciò che descrivi, sarebbe eccessivamente eccessivo senza alcun vantaggio apparente.

Oltre alle funzioni che leggono e scrivono i file, la maggior parte della logica può essere scritta come funzioni libere da effetti collaterali che accettano input e restituiscono altri output. Questo è estremamente facile da testare, molto più semplice rispetto al test di unità OO in cui è necessario deridere dipendenze e quant'altro.

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

Considera un pulsante in una GUI. Ha stato (è dimensione, colore, posizione, etichetta ecc.). Le cose possono succedere (si fa clic, è necessario ridisegnare ecc.). In tali situazioni, modellarlo come un oggetto ha 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 successe con l'attivazione di eventi.

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

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

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

La regola generale che uso è che se ho molto stato o ho bisogno dell'interazione dell'utente, uso gli oggetti; altrimenti utilizzo 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. Eredità
4. Polimorfismo

Utilizzerai OOP nella tua applicazione quando è diventata abbastanza grande e abbastanza complessa da beneficiare di questi strumenti.

Questa domanda mi sembra un po 'confusa. Se lo scrivi in ​​Python, utilizzerai sicuramente degli oggetti. Quando si apre un file, restituisce un oggetto. Quando si ottiene risultato, restituisce un oggetto iteratore. Ogni funzione che crei è un oggetto. Mettere in discussione il valore di OO nelle applicazioni Python sembra a dir poco strano.

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

Forse queste distinzioni tra design OO e design funzionale stanno diventando obsolete. Se creo accetta una funzione polimorfica su un oggetto progettato OO * e passo un puntatore a quella funzione su un oggetto come parametro per una funzione in stile funzionale *, è OO o è funzionale? Penso che sia sia un approccio davvero efficace per risolvere i problemi.

Penso che la vera domanda sia "quando dovresti iniziare a progettare le tue classi piuttosto che creare un modulo con funzioni?" Penso che la risposta giusta sia: 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 presumere 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, inizi a ragionare sullo stato.

Molte volte vedo l'oggetto, vedo i metodi, ma vedo anche che il pensiero guida dietro il codice è flusso anziché stato.

E una volta che ragionate sullo stato, è facile costruire un buon codice OOP perché non appena il codice diventa troppo complesso, notate che non potete più ragionare sul vostro stato e sapete che dovete rifattorizzare.

Considera il tuo esempio: vuoi analizzare un file CSV. Da dove viene: un file su disco. Lo carichi, lo metti in memoria e lo analizzi. Ora arriva il tuo cliente: ehi, voglio anche analizzare i file dal web. Quindi sei felice perché hai creato una bella interfaccia per caricare il tuo file e devi solo rendere il codice che lo recupera dal web e il resto del tuo programma rimane esattamente lo stesso.

E la cosa bella è: puoi provarlo.

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 di una nave per mantenere la galleggiabilità se lo scafo è danneggiato.
• OOP è un modo di gestire le dipendenze, quindi i bug possono essere più facili da rintracciare poiché esiste solo un insieme definito di modi in cui i diversi componenti di un programma possono comunicare quali altri.
• In un programma ci sono molte cose che funzionano: variabili, costanti, metodi, file, parametri, funzioni, moduli, ecc. Possono interagire tra loro in modi a volte 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à complesso nel tempo?
• Intendi ridimensionare o riutilizzare il codice in futuro?
• Pensi che il tuo "design" possa diventare una risorsa? cioè sarai in grado di sfruttarlo per crescere o come base per progetti futuri?

Non fraintendetemi: potete ottenere tutto ciò senza usare OOP ma con OOP sarà più facile.

Ma...

Se il tuo team non è esperto in OOP / OOD e non ha esperienza in quell'area, vai con le risorse che hai.

Quindi, la mia domanda sarebbe: come fate, sapete / decidete quando usare OOP in un'applicazione?

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

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

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

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

Facilita il refactoring e il riutilizzo, come ho già detto, incoraggia una buona astrazione, che facilita la manutenzione. OOP dovrebbe essere abbracciato e usato tutto il tempo. Una buona programmazione OOP evita metodi statici e / o dati statici e usa oggetti per tutto.

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

Come: questa è la parte del frame del tuo codice, in cui crei una sorta di astrazione, decidi come funzionano i tuoi blocchi in generale e come interagiscono con altri blocchi.

Cosa fare - Questa parte è dove i blocchi eseguono il lavoro vero e proprio. Qui le classi sono derivate dalle classi di base create nella sezione "Come fare".

Si può trarre grandi vantaggi 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 usato e altri progetti / progetti futuri possono trarre vantaggio dal framework creato durante lo sviluppo del progetto corrente.
3. Suddividere progetti enormi in schemi comunemente conosciuti per risolvere un grosso problema.
4. Usa OOPS anche per piccoli progetti per prendere l'abitudine di usarlo ed essere pronto quando si presentano 1-3 tipi di problemi