E' comprensibile secondo me, quando si sviluppano applicazioni piccole o comunque con un grado di complessità molto basso, non percepire il reale aiuto che da la programmazione orientata agli oggetti.
E' non è una questione di mera organizzazione. Si arriva ad un punto che il programma si scrive solo, la testabilità aumenta e aumenta la qualità, l'estendibilità è rapida; individuare, replicare e risolvere un bug diventa metodologico.
Un altro fattore che può non far comprendere le potenzialità della OOP, è conoscere i meri principi senza farli stare assieme.
Un pò come gli scacchi magari sai ogni pezzo come si muove, ma non vuol dire poi giocare sul serio.
Il tal caso suggerisco di approfondire tematiche relative all'architettura del software, design pattern e SOLID principles.
E ovviamente sperimentare poi su un software enorme cosa vuol dire lavorare su codice preesistente ben architettato, isolabile, testabile, estendibile, solido.
E di contro provare a lavorare su codice enorme preesistente, scritto da cani, ripetizioni ovunque, cablature, deingegnerizzato.
Questo non vuol dire che tutti i codici non OOP sono scritti da cani, si può fare buon codice anche con la programmazione strutturata, ma a quel punto quando vedi la OOP vuol dire solo avere il linguaggio che ti offre intrinsicamente alcune cose che sennò dovevi inventarti a mano per simulare quei comportamenti.
E quindi non puoi che apprezzarla.
Quindi le mie ipotesi sono per la tua opizione:
- software troppo piccoli
- carenza di principi "globali" sull'uso dei singoli principi della OOP
- abitudine a non usare proprio codice organizzato, perchè se il codice fosse per lo meno organizzato strutturalmente la OOP sarebbe un'evoluzione allettante.
|