La programmazione a oggetti è morta?
La maggior parte di voi lettori starà pensando che ho preso una botta in testa e sto chiaramente delirando. Come è possibile che non consigli la programmazione a oggetti, le richieste di lavoro sono lì, tutte le grosse aziende utilizzano questo paradigma: banche, ospedali e quasi tutta la PA.
Java e .NET per citare i due player più importanti sono stabili, testati è possibile utilizzare molti design pattern (Abstract factory, Singleton, Dependency injection, per citarne alcuni) per ottenere la migliore progettazione possibile, ci sono framework ottimi come Spring e tante altre librerie pronte all'uso che funzionano bene e sono in produzione da anni.
Le scuole e le università hanno preparato un sacco di programmatori orientati a questo approccio, che sanno già come prendere un problema reale e astrarlo in ogni piccolo dettaglio, in ogni singolo attributo o metodo, in astrazioni delle astrazioni.
“Ma siamo sicuri questo sia il metodo giusto per risolvere i problemi?”
Guardando nel mio piccolo, quando strutturo un progetto, voglio che funzioni bene, che non abbia bug, che vada veloce, che in caso di modifiche possa farle velocemente, quindi avere un codice chiaro ma in particolare che risolva il problema reale che mi viene posto.
Al panettiere smart che deve tenere traccia della farina usata con una bilancia connessa per stimare il costo del pane e fare un previsionale accurato, non gli interessa minimamente il come, ma solo il risultato concreto che porta nella sua attività.
L'obiettivo è risolvere problemi, non astrarre, non schematizzare, non sovra ingegnerizzare.
Quindi perchè utilizzare classi e oggetti?
Perché trasformare il codice in un mostro di migliaia di righe di codice, complicato da capire, che nella maggior parte dei casi più il progetto si amplia, più le cose iniziano a rompersi ed è difficile implementare cose nuove.
La programmazione a oggetti ha fallito nella sua missione, rende complicato risolvere un problema, nasconde le soluzioni (molti la chiamano astrazione o corretta progettazione): per me questo è intollerabile.
Capisco le aziende che hanno personale a basso costo e "trovabile" ogni dove ma siete sicuri di fare un giusto investimento? Siete veramente sicuri di voler continuare a sviluppare software con codice di bassa qualità, difficile da mantenere, difficile da testare, con grosse implicazioni progettuali quando c'è un cambio di funzionalità?
Io non credo che questo sia il futuro e come non lo credo io, non lo credono neanche le più grandi aziende al mondo (Facebook, Twitter, Amazon, Paypal) che già da anni utilizzano un paradigma differente, più legato alla natura stessa dell'informatica.
Scriverò un secondo articolo in cui parlo della programmazione funzionale, del perchè i clienti sono contenti e del perchè dormo poco.
Mi piacerebbe molto avere dei feedback sulla mia opinione, specialmente da qualcuno che quotidianamente utilizza questo paradigma.
Alla prossima!
La maggior parte di voi lettori starà pensando che ho preso una botta in testa e sto chiaramente delirando. Come è possibile che non consigli la programmazione a oggetti, le richieste di lavoro sono lì, tutte le grosse aziende utilizzano questo paradigma: banche, ospedali e quasi tutta la PA.
Java e .NET per citare i due player più importanti sono stabili, testati è possibile utilizzare molti design pattern (Abstract factory, Singleton, Dependency injection, per citarne alcuni) per ottenere la migliore progettazione possibile, ci sono framework ottimi come Spring e tante altre librerie pronte all'uso che funzionano bene e sono in produzione da anni.
Le scuole e le università hanno preparato un sacco di programmatori orientati a questo approccio, che sanno già come prendere un problema reale e astrarlo in ogni piccolo dettaglio, in ogni singolo attributo o metodo, in astrazioni delle astrazioni.
“Ma siamo sicuri questo sia il metodo giusto per risolvere i problemi?”
Guardando nel mio piccolo, quando strutturo un progetto, voglio che funzioni bene, che non abbia bug, che vada veloce, che in caso di modifiche possa farle velocemente, quindi avere un codice chiaro ma in particolare che risolva il problema reale che mi viene posto.
Al panettiere smart che deve tenere traccia della farina usata con una bilancia connessa per stimare il costo del pane e fare un previsionale accurato, non gli interessa minimamente il come, ma solo il risultato concreto che porta nella sua attività.
L'obiettivo è risolvere problemi, non astrarre, non schematizzare, non sovra ingegnerizzare.
Quindi perchè utilizzare classi e oggetti?
Perché trasformare il codice in un mostro di migliaia di righe di codice, complicato da capire, che nella maggior parte dei casi più il progetto si amplia, più le cose iniziano a rompersi ed è difficile implementare cose nuove.
La programmazione a oggetti ha fallito nella sua missione, rende complicato risolvere un problema, nasconde le soluzioni (molti la chiamano astrazione o corretta progettazione): per me questo è intollerabile.
Capisco le aziende che hanno personale a basso costo e "trovabile" ogni dove ma siete sicuri di fare un giusto investimento? Siete veramente sicuri di voler continuare a sviluppare software con codice di bassa qualità, difficile da mantenere, difficile da testare, con grosse implicazioni progettuali quando c'è un cambio di funzionalità?
Io non credo che questo sia il futuro e come non lo credo io, non lo credono neanche le più grandi aziende al mondo (Facebook, Twitter, Amazon, Paypal) che già da anni utilizzano un paradigma differente, più legato alla natura stessa dell'informatica.
Scriverò un secondo articolo in cui parlo della programmazione funzionale, del perchè i clienti sono contenti e del perchè dormo poco.
Mi piacerebbe molto avere dei feedback sulla mia opinione, specialmente da qualcuno che quotidianamente utilizza questo paradigma.
Alla prossima!
Dalle nostre news…
Analisi di un selfie: una storia di Instagram e vanità.
Leggi di più
Quando il packaging aiuta a vendere.
Leggi di più
