Codice procedurale vs codice OOP

Ho terminato un progetto in PHP di oltre 13000 righe in stile procedurale [perché ne ho molta familiarità, anche se conosco OOP], e il progetto sta funzionando perfettamente.

Ma dovrei convertirlo in OOP? [ perché il mondo è impegnato con OOP ]

Il mio codice non ha bisogno di nessuna delle funzionalità di OOP [incapsulamento, ereditarietà in sostanza ...]!

Quindi cosa dovrei fare?

E che tipo di aiuto otterrò se lo converto in OOP?

Il mio codice non ha bisogno di nessuna delle funzionalità di OOP

Hai risposto alla tua domanda: se in questo caso non hai bisogno di OOP e il tuo progetto funziona, non convertirlo.

Tuttavia, dovresti cercare di utilizzare OOP per il tuo prossimo progetto, ma solo se è appropriato.

Non c'è nulla di intrinsecamente sbagliato nella programmazione procedurale, purché sia ​​utilizzato nel posto appropriato.

No e non solo perché non hai bisogno di OOP.

Se il tuo programma è già finito e funziona in modo soddisfacente, nel 90% dei casi è una perdita di tempo riscrivere il codice finito per qualsiasi motivo.

OOP non è tutto potente, ci sono molti posti in cui OOP non dovrebbe essere usato, quindi non limitarti a usarlo perché OOP è la tendenza.

La mia opinione generale sui paradigmi (e perché nessuno dei tre paradigmi principali è il modo giusto o il modo sbagliato di programmare):

La programmazione procedurale è buona quando si ha un problema semplice ad alto livello (anche se può essere complesso a basso livello) e si desidera scrivere un codice lineare altrettanto semplice. È probabilmente più facile da scrivere e capire di OO e funzionale se il problema non ha bisogno di un forte disaccoppiamento da nessuna parte. Esempi: codice numerico, la maggior parte dei piccoli script, la maggior parte dei piccoli problemi secondari dopo aver suddiviso le cose usando OO o funzionale.

Il codice orientato agli oggetti è utile quando è necessario disaccoppiare fortemente le preoccupazioni poiché è possibile che siano presenti più implementazioni di alcune preoccupazioni. Esempio: la maggior parte dei software per grandi aziende. Ad esempio, potresti voler separare fortemente la logica di business dalla logica di presentazione perché probabilmente dovranno cambiare in modo indipendente.

La programmazione in stile funzionale è buona quando è necessaria una forte separazione dei meccanismi dalla politica. Avere una funzione meccanismo che accetta una funzione politica è un modello piacevole. (Ho imparato a riguardo guardando il modulo std.algorithm del linguaggio di programmazione D.) Estrarre lo stato mutabile al confine tra politica e codice meccanismo generalmente rende l'API più facile da ragionare. Se uno stato mutabile viene utilizzato privatamente in entrambi, questo è un dettaglio di implementazione. L'altro punto di forza della programmazione funzionale è la concorrenza, per ovvie ragioni.

Il codice non "ha mai bisogno di OOP". Sono i programmatori, nella misura in cui sono in grado di pensare in modi diversi, che immaginano che questo o quel particolare problema "necessiti" di $ PARADIGM o che sia meglio risolto in quel modo.

Spesso i programmatori che conoscono un solo paradigma pensano che il loro paradigma sia il più grande. Taglia unica, e tutti dobbiamo dormire nel letto di Procrustes, se questo o quello è attualmente di moda.

Dovresti convertire il tuo progetto in OOP solo se c'è una chiara indicazione della necessità di OOP. I possibili scenari in cui ciò può accadere sono (tra gli altri):

• ridimensionamento del progetto
• aggiungendo più sviluppatori al team

e anche in questi scenari potrebbe non essere ancora necessario convertire il tuo progetto in OOP.

Entrambi possono essere buoni, entrambi possono essere cattivi. Ma il retrofit dell'uno per assomigliare all'altro non è mai una buona idea.

Se ripensi al motivo per cui OO è stato inventato, vedrai che non hai bisogno di OOP, ma a volte ti semplifica la vita.

Ai tempi della codifica C, un programma molto grande poteva diventare piuttosto disordinato e difficile da continuare a lavorare. Quindi hanno inventato i modi per dividerlo in blocchi modulari. OOP adotta questo approccio e lo rende ancora più modulare, mettendo i dati con quei pezzi di logica del programma in modo che siano ancora più separati dal resto del codice.

Ciò ti consente di scrivere programmi sempre più grandi, sicuro che hai invece trasformato il tuo enorme elefante di un'attività in un centinaio di compiti delle dimensioni di un mouse. Il vantaggio aggiuntivo è che puoi prendere alcuni di questi "topi" e riutilizzarli in altri programmi!

Certo, il mondo reale non è proprio così, e il riutilizzo degli oggetti non è mai stato preso nel modo in cui era inteso, ma non significa che sia un paradigma inutile.

Ciò che è inutile è un'eccessiva dipendenza da entrambi gli stili di codifica. Chiunque esegua OO con un migliaio di classi minuscole e insignificanti non lo sta facendo nel modo giusto: sta creando un incubo per la manutenzione per se stesso (o per qualcun altro). Chiunque scriva un'applicazione procedurale che è solo 3 funzioni sta anche rendendo la vita difficile. Il modo migliore è il mezzo medio, oggetti di grandi dimensioni (a volte chiamati componenti che è dove dovevamo andare una volta) che possono fornire una discreta quantità di codice autonomo e dati che è molto più probabile che vengano riutilizzati in isolamento dal resto della tua app.

Il mio consiglio per la prossima volta: prova a scrivere il tuo solito codice procedurale, ma crea un singolo oggetto della tua struttura dati principale. Guarda come ti accorgi che lavorare con esso è più semplice che passare i dati da una funzione all'altra.

Il mio codice non ha bisogno di nessuna delle funzionalità di OOP [incapsulamento, ereditarietà in sostanza ...]!

Come fai a saperlo?

Devi mantenere questo progetto? Sono previste nuove funzionalità? Ci saranno altre persone che si svilupperanno con te? Ti sei ripetuto? Il codice è difficile da comprendere?

Se la risposta è "sì", allora forse dovresti iniziare a pensare di impostare uno scheletro OOP e andare in questo modo.