Ho terminato un progetto in PHP di 13000+ linee in Stile procedurale [perché sono molto familiare, anche se conosco OOP] e il progetto funziona perfettamente.
Ma dovrei convertirlo in OOP? [ perché il mondo è occupato con OOP ]
Il mio codice non ha bisogno di nessuna delle funzionalità di OOP [incapsulamento, ereditarietà fondamentalmente ...]!
Quindi cosa dovrei fare?
E che tipo di aiuto otterrò se lo convertirò in OOP?
My code doesn't need any of the feature of OOP
Hai risposto alla tua domanda - se non hai bisogno di OOP in questo caso e il tuo progetto funziona, non convertirlo.
Tuttavia, dovresti considerare l'uso di OOP per il tuo progetto next , ma solo se appropriato.
Non c'è nulla di intrinsecamente sbagliato nella programmazione procedurale, a patto che venga utilizzata nel posto appropriato.
No e non solo perché non hai bisogno di OOP.
Se il tuo programma è già terminato e funziona in modo soddisfacente, oltre il 90% delle volte è un tempo sprecato per riscrivere il codice finito per qualsiasi motivo.
OOP non è tutto potente ci sono molti posti in cui OOP non dovrebbe essere usato, quindi non usarlo solo perché OOP è la tendenza.
La mia visione generale dei paradigmi (e perché nessuno dei tre paradigmi principali è la strada giusta o il modo sbagliato di programmare):
La programmazione procedurale è utile quando si ha un problema semplice a un livello elevato (sebbene possa essere complesso a un livello basso) e si desideri scrivere un codice lineare e semplice. È discutibilmente più facile da scrivere e capire di OO e funzionale se il problema non ha bisogno di un strong disaccoppiamento da nessuna parte. Esempi: codice numerico, la maggior parte dei piccoli script, la maggior parte dei sottoproblemi una volta che hai rotto le cose usando OO o funzionale.
Il codice orientato agli oggetti è utile quando è necessario separare strongmente le preoccupazioni perché potresti avere più di un'implementazione di alcune preoccupazioni. Esempio: software aziendale di grandi dimensioni. Ad esempio, potresti voler separare strongmente la logica aziendale dalla logica di presentazione perché probabilmente dovranno cambiare in modo indipendente.
La programmazione in stile funzionale è utile quando è necessaria una strong separazione del meccanismo dalla politica. Avere una funzione meccanismo che accetta una funzione politica è un buon modello. (L'ho imparato osservando il modulo std.algorithm del linguaggio di programmazione D. Estrazione dello stato mutabile al limite tra la politica e il codice del meccanismo in genere rende l'API più facile da ragionare. Se lo stato mutabile è utilizzato privatamente in entrambi, questo è un dettaglio di implementazione. L'altra forza della programmazione funzionale è la concorrenza, per ragioni evidenti.
Codice mai "ha 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 "abbia bisogno" di $ PARADIGM o sia meglio risolto in questo modo.
Spesso accade che i programmatori che conoscono solo un paradigma pensano che il loro paradigma sia il più grande. Taglia unica, e tutti noi dobbiamo dormire nel letto di Procrustes, se questo o quello è attualmente di moda.
Devi convertire il tuo progetto in OOP solo se c'è una chiara indicazione del bisogno di OOP. I possibili scenari in cui ciò può accadere sono (tra gli altri):
e anche in questi scenari potrebbe non essere ancora necessario convertire il progetto in OOP.
Entrambi possono essere buoni, entrambi possono essere cattivi. Ma riadattare 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 affatto, ma a volte ti rende la vita molto più facile.
Ai tempi della codifica C, un programma molto grande poteva diventare piuttosto complicato e difficile da lavorare. Quindi hanno inventato modi per dividerlo in blocchi modulari. OOP adotta questo approccio e lo rende ancora più modulare, mettendo i dati con quei blocchi di logica del programma in modo che siano ancora più separati dal resto del codice.
Questo ti permette di scrivere programmi sempre più grandi, sicuro di aver cambiato il tuo enorme elefante di un compito in cento compiti come topi. Il bonus aggiuntivo è che puoi prendere alcuni di questi "mouse" e riutilizzarli in altri programmi!
Naturalmente, il mondo reale non è proprio così, e il riutilizzo degli oggetti non è mai stato preso come previsto, ma non significa che sia un paradigma inutile.
Ciò che è inutile è un'eccessiva fiducia in entrambi gli stili di codifica. Chiunque faccia OO con un migliaio di classi minuscole e insignificanti, non lo sta facendo nel modo giusto - sta creando un incubo di manutenzione per se stessi (o qualcun altro). Chiunque stia scrivendo un'applicazione procedurale con solo 3 funzioni sta rendendo la vita difficile. Il modo migliore è la base, gli oggetti di grandi dimensioni (a volte chiamati componenti, ovvero il luogo in cui cercavamo di passare una volta) in grado di fornire una buona quantità di codice e dati autonomi 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 normale codice procedurale, ma crea un singolo oggetto della tua struttura dati principale. Guarda come trovi che lavorare con esso è più semplice che passare dati da una funzione all'altra.
My code doesn't need any of the feature of OOP [encapsulation, inheritance basically...]!
Come lo sai?
Hai bisogno di mantenere questo progetto? Ci sono nuove funzionalità pianificate? 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 creare uno scheletro OOP e andare in questo modo.
Leggi altre domande sui tag programming-languages programming-practices