OOP 101: Introduzione all’Object-Oriented Programming

Object-oriented programming: cosa significa e quali sono i pilastri essenziali

Scopriamo i capisaldi della programmazione a oggetti, la sua storia, vantaggi, svantaggi, e le nozioni base più utili per comprenderla

OOP, ovvero object-oriented programming (programmazione orientata agli oggetti) è un paradigma di programmazione incentrato sul concetto di oggetto e il modo con cui tali oggetti interagiscono tra loro.

Gli oggetti costituiscono entità modulari, definite, riutilizzabili e astratte, messe in comunicazione tra loro per la realizzazione di applicativi di diversa complessità.

Nell’OOP (talvolta per semplicità chiamata anche programmazione a oggetti), gli oggetti possono contenere dati o codice.

I dati sono gestiti mediante campi (attributi, proprietà) e il codice mediante procedure (tipicamente chiamati metodi).

Soddisfatta la necessità di una definizione formale, possiamo fornire anche una definizione più diretta e intuitiva.

OOP può essere quindi illustrato come un modello che vede la definizione di oggetti, e delle istruzioni che permettono a tali oggetti di interagire tra loro per l’ottenimento di un risultato desiderabile, preservando determinate specifiche quali riusabilità, modularità e segregazione delle attività.

La programmazione orientata agli oggetti  è uno dei quattro paradigmi fondamentali della programmazione, di cui forniamo per ciascuno una definizione estremamente sintetica:

1. Programmazione funzionale (i programmi sono visti come funzioni, seguendo un approccio logico simile a quello usato per la risoluzione di problemi matematici).
2. Programmazione imperativa (i programmi sono rappresentati come una serie di istruzioni che cambiano lo stato dei processi).
3. Programmazione logica (i programmi sono disegnati tenendo conto delle relazioni procedure, modelli e informazioni).
4. Programmazione orientata agli oggetti.

OOP spiegata con D&D

Un esempio attinto dal mondo reale potrebbe essere un gioco di ruolo come Dungeons & Dragons: D&D prevede degli oggetti (personaggi, creature), ciascuno con proprietà (attacco, difesa), attributi (valori di vita, carisma, forza), e stabilisce le regole con le quali ciascuno di loro possa interagire con gli altri. Inoltre, il regolamento di D&D non prevede di coprire un’infinita gamma di mostri, ma si preoccupa di stabilire le regole basi per ciascuno di essi, lasciando poi che sia il giocatore a crearli di volta in volta attingendo a regole di alto livello definite nella documentazione. Addirittura, D&D ha fatto proprio il concetto di “classe” per esprimere la classificazione del personaggio.

La struttura di OOP

OOP si basa su strutture definite a priori e che compongono l’ecosistema su cui si basa il paradigma di programmazione a oggetti.

Tali strutture sono Classi, Oggetti, Metodi, Attributi.

Classi

Le classi sono elementi fondanti di OOP e definiscono specifiche tipologie di dato.

La creazione è a cura dell’utente, seguendo le specifiche proprie del linguaggio di programmazione in uso, che non ne inficiano comunque proprietà e aspetti formali e teorici. La classe funge da modello per oggetti, attributi e metodo. Le classi possono essere private, pubbliche, o protette (sebbene non tutti i linguaggi di programmazione OOP implementino questa tassonomia).

Oggetti

Gli oggetti sono istanze di classi con dati specificatamente definiti. Tornando al nostro gioco di ruolo, potremmo dire che una classe è una scheda personaggio vuota, e che un oggetto è una scheda personaggio debitamente compilata con nome, caratteristiche, e sì, attributi.

Metodi

I metodi sono funzioni definite all’interno di una classe che definiscono il comportamento di un oggetto. Procedure specifiche che operano sugli attributi dell’oggetto.

Ad esempio in una classe potremmo avere il metodo “salva” per salvare il dato sul database. Anche i metodi sono elementi fondanti del paradigma OOP, operanti a livello più atomico rispetto alle classi

Attributi

Gli attributi possono essere visti caratteristiche specifiche di una classe, atte a rappresentarne le funzionalità specifiche.

Gli attributi sono espressi tipicamente mediante variabili nelle quali viene salvato il dato.

Come abbiamo visto nell’esempio del gioco di ruolo, attributi potrebbero essere elementi di dato come nome del personaggio, la sua forza, i suoi punti vita.

Terminologia di OOP

Il paradigma OOP prevede l’utilizzo di una terminologia specifica, che permette di fugare ogni dubbio e definire un layer base di comunicazione privo di incomprensioni.

Gli oggetti vengono istanziati partendo da una classe mediante un costruttore.

Un’istanza è un singolo oggetto di una specifica classe.

Una interfaccia è una struttura che definisce quali debbano essere le proprietà minime di un oggetto derivante dall’interfaccia stessa.

Il tempo che intercorre tra la creazione e la distruzione di un oggetto è chiamato lifetime dell’oggetto.

Storia dell’Object-Oriented Programming

Il paradigma

Il paradigma della programmazione a oggetti nasce al MIT attorno agli anni ’60, in contemporanea con lo sviluppo delle prime applicazioni di intelligenza artificiale. Già nel 1960 sono riscontrabili citazioni di “oggetti” e “istanze”, per esempio nella documentazione del software Sketchpad.

Altre applicazioni rilevanti per lo sviluppo dell’OOP sono state indubbiamente il linguaggio di programmazione Simula, e, successivamente, Smalltalk.

Il termine

Il termine “Object-Oriented”, orientato agli oggetti, è stato coniato da Alan Kay, si stima attorno al 1967, quando Alan era ancora studente.

Alan Kay, PhD (17 Maggio 1940) è un informatico statunitense che per oltre dieci anni ha lavorato e contribuito alle scoperte del celeberrimo XEROX PARC (Palo Alto Research Center), fonte di numerose tecnologie tutt’ora di uso corrente.

Durante la sua carriera, Alan Kay ha creato il linguaggio di programmazione Smalltalk, ha ideato il concept di computer portatile, ha ideato le moderne GUI (Graphical User Interfaces), e ha contribuito a creare la tecnologia Ethernet e il protocollo di comunicazione client-server.

Alan Kay è stato consulente per diverse aziende, tra le quali The Walt Disney Co. e  Hewlett-Packard. Grazie al suo contributo all’informatica, è stato insignito del prestigioso Premio Turing (l’equivalente del Premio Nobel per il mondo dell’informatica).

Alan Kay in diverse occasioni è tornato sulla sua definizione di “Object-Oriented Programming”, sostenendo di aver coniato un termine per un paradigma informatico che certamente lui stesso stava utilizzando, ma senza necessariamente esserne stato l’inventore.

“I made up the term ‘object-oriented’, and I can tell you I didn’t have C++ in mind.” ~ Alan Kay, OOPSLA ‘97

Alan afferma di aver dato un nome a qualcosa che già esisteva. Acutamente, Erik Engheim, studiando proprio la genesi di OOP, conia questa interessante analogia:

“Ha detto di non aver inventato l’OOP, ma di averlo semplicemente scoperto. Nella sua mente l’OOP era qualcosa che stava già accadendo in diversi settori. Si è limitato a dargli un nome e a descriverlo.

Immagino sia come creare una tassonomia degli animali. I mammiferi, i rettili e gli uccelli sono già presenti. Ma c’è comunque un valore nel fatto che qualcuno arrivi a organizzare gli animali in questi gruppi e ad apporre etichette a questi gruppi.”

Alan inventò il termine per esprimere il concetto di permettere la comunicazione tra computer mediante “oggetti” piuttosto che “data structures” o “procedures”.

La creazione di Smalltalk

Smalltalk è un linguaggio di programmazione puramente orientato agli oggetti, creato  per uso didattico, in particolare per l’apprendimento costruttivo su modelli mentali. Smalltalk nasce allo Xerox PARC da un team di scienziati tra cui spicca, oltre il già citato Alan Kay, anche Dan Ingalls, Adele Goldberg, Ted Kaehler, Diana Merry e Scott Wallace.

Sebbene Smalltalk si sia ispirato a Lisp e Simula, e sebbene Simula avesse già in esso diversi paradigmi tipici dell’OOP, è proprio ritenere che il primato del primo linguaggio davvero orientato agli oggetti spetti a Smalltalk. Nel linguaggio Smalltalk, tutto è rappresentato come un oggetto (classi, interi, blocchi) ed è definito un linguaggio “core OOP”, ossia puramente orientato agli oggetti.

Linguaggi di programmazione orientati agli oggetti

Oggi OOP è un paradigma di programmazione consolidato, e sono molti i linguaggi di programmazione costruiti attorno a questo paradigma.

Citando solo i più famosi, pur con diverse sfumature, possiamo ricordare: Ada, C++, C#, Dart, Fortran, Lisp, Java, Kotlin, MATLAB, Perl, PHP, Python, R, Ruby, Scala, Visual Basic.NET.

Alcuni di essi sono linguaggi strettamente orientati agli oggetti (definiti “pure OOP”). Tra questi citiamo Ruby, Scala, Smalltalk.

Altri sono linguaggi disegnati prettamente per OOP, ma con elementi procedurali. Questi sono i linguaggi di programmazione a oggi più diffusi e utilizzati, come C++, C#, Java, Python.

Altri linguaggi, al contrario, pur non nascendo come prettamente OOP, lo sono diventati per estensione. Ad esempio PHP, Perl, Visual Basic.

Infine abbiamo linguaggi come JavaScript che sono definiti “heavily OOP” ma che in via strettamente formale non rientrerebbero nella definizione canonica di linguaggi OOP.

Alcuni linguaggi di programmazione attingono al paradigma OOP per alcuni dei loro idiomi, ma, non implementandone strettamente le funzionalità, non sono correntemente definiti linguaggi orientati agli oggetti. Un esempio ne è RUST.

Infine è bene ricordare che in senso stretto il mero utilizzo di un linguaggio non determina automaticamente la rispondenza con uno specifico paradigma di programmazione, o che un linguaggio sia limitato alla generazione di codici rispondenti solo ad un paradigma di programmazione (a parte specifici e conclamati casi).

I principi di OOP

Oltre alle componenti di OOP (classi, oggetti, metodi e attributi), OOP si basa su quattro principi base, che sono noti propriamente come i principi base di OOP.

Essi sono Abstraction, Encapsulation, Inheritance e Polymorphism (pur fornendo la traduzione, riteniamo sia sensato proporli in inglese, per una rispondenza uno a uno con documentazione e testi tecnici).

Design Pattern

Per comprendere i principi di OOP, dobbiamo prima però introdurre il concetto di design pattern (traducibile come tracciati di progettazione). I design pattern nascono proprio nel contesto della programmazione a oggetti.

I design pattern sono soluzioni riutilizzabili a problemi particolarmente frequenti o tipici nel contesto della programmazione di soluzioni software. Sono nati come best practice applicate più volte a problemi simili incontrati in contesti diversi. Possiamo definirli come la soluzione ottimale ad un problema noto.

I design pattern sono diventati popolari dopo essere stati raccolti, nel libro Gang Of Four del 1994, che sfrutta proprio esempi in C++ e Smalltalk. I design pattern sono molto popolari in linguaggi come Python, Java, C#, C++ e possono essere applicati in tutti i linguaggi orientati agli oggetti.
Viceversa, un’implementazione funzionante ma formalmente errata, viene definita un anti-pattern.

OOP non è da intendere come un mero esercizio di applicazione di regole formali. É un paradigma di design che richiede di intervenire sull’architettura del software e applicarlo atomicamente a ogni elemento del programma che si sta progettando.

I 4 principi fondamentali di OOP

Abstraction (astrazione)

Il concetto di astrazione è forse il più fondante, dal punto di vista ideologico, di OOP.

Il concetto di astrazione lascia intendere che l’utilizzatore (di un oggetto, classe, metodo, ma anche per estensione, applicativo software) non debba essere a conoscenza di ogni minimo dettagli implementativo e funzionale per interagire con tale elemento. Un “general understanding”, una comprensione generale deve essere sufficiente.

Nell’OOP, l’astrazione è tipicamente implementata definendo una classe o un’interfaccia astratta che fornisce un insieme di metodi o attributi senza specificarne l’implementazione. L’implementazione di questi metodi e attributi è lasciata alle classi derivate o alle classi di implementazione, che devono fornire la propria implementazione.

Ad esempio, si consideri una classe astratta “Forma” che definisce un metodo “area”. La classe “Forma” non specifica l’implementazione di “area”, ma lascia che siano le classi derivate, come “Rettangolo”, “Cerchio” e “Triangolo”, a fornire la propria implementazione di “area” in base alle loro caratteristiche specifiche.

Per analogia, potremmo dire che per utilizzare l’oggetto lavatrice non occorra conoscerne i principi elettronici e fisici, ma sia sufficiente una conoscenza di base dell’oggetto “elettrodomestico” per farlo funzionare.

Gli oggetti fondanti il nostro programma dovranno essere astratti in modo da essere autoesplicativi, semplici da usare, semplici da comprendere.

“Strive to abstract objects in a way that makes them intention-revealing, simple to use, and simple to understand.”

Scendendo ad un livello di dettaglio ulteriore, l’astrazione può essere declinata su dati e processi.

• Data abstraction: gli oggetti non sono direttamente visibili all’utente finale; l’interazione con essi può avvenire solo attraverso specifici metodi.
• Process abstraction: i dettagli del funzionamento di un oggetto non sono necessari per utilizzare l’oggetto stesso. Sarà sufficiente conoscere i metodi e le funzioni che permettono di interagire con esso.

Grazie all’astrazione, il programmatore può focalizzarsi sul “cosa” piuttosto che sul “come”, trovando soluzioni generali applicabili in tutte le situazioni riconducibili alla casistica in oggetto.

Encapsulation (incapsulamento)

L’incapsulamento riferisce alla pratica di generare una gerarchia tra oggetti, classi, metodi e funzioni, limitando l’accesso diretto alle componenti dell’oggetto e facendo sì che possano essere utilizzati solo attraverso metodi e proprietà pubbliche. Ciò consente un migliore controllo sulle modalità di utilizzo e di modifica di un oggetto e aiuta a prevenire modifiche o errori involontari che potrebbero derivare dalla manipolazione diretta dei suoi dati interni.

L’implementazione dell’incapsulamento nell’OOP comporta tipicamente la definizione di una classe con attributi privati e metodi pubblici. Gli attributi privati sono accessibili solo all’interno della classe stessa, mentre i metodi pubblici forniscono un modo controllato per altri oggetti di interagire con la classe e accedere o modificare il suo stato.

Ad esempio, si consideri una classe che rappresenta un conto bancario. Il saldo del conto è un attributo privato che non deve essere modificato direttamente da altri oggetti. Invece, la classe dovrebbe fornire metodi pubblici come “deposito” e “prelievo”, che consentono ad altri oggetti di interagire con il conto in modo controllato, assicurando che il saldo venga aggiornato correttamente e che vengano eseguiti i controlli o le convalide necessarie sull’intero ciclo di vita del dato.

Da un punto di vista strettamente formale, l’incapsulamento è anche presentato talvolta come il concetto di aggregare (appunto, incapsulare) dati e metodi di che insistono su specifici attributi in un unica unità (unit), come ad esempio una classe.

La distinzione tra le due definizioni, che, comunque, convergono allo stesso risultato, è prettamente dettata da scelte di alto livello.

L’incapsulamento è un principio importante dell’OOP che aiuta a promuovere la modularità, la manutenibilità e la riutilizzabilità del codice, incapsulando i dettagli di implementazione di un oggetto e fornendo un’interfaccia pubblica ben definita per gli altri oggetti che possono interagire con esso.

Inheritance (ereditarietà)

L’ereditarietà riferisce alla capacità di una classe di ereditare le proprietà e i metodi di un’altra classe esistente.  La classe derivata, nota anche come sottoclasse o classe figlia, può accedere agli attributi e ai metodi della sua classe madre attraverso l’ereditarietà e può anche sovrascriverli o estenderli, se necessario.

Ad esempio, si consideri una gerarchia di classi che rappresentano diversi tipi di veicoli. Una super classe “Veicolo” potrebbe avere attributi e metodi come “velocità”, “accelerazione” e “consumi”. Una sottoclasse “Auto” potrebbe ereditare queste proprietà dalla classe “Veicolo”, aggiungendo anche attributi e metodi propri, come “numero_porte” e “cambio_marcia”. Un’ulteriore sottoclasse “Motocicletta” potrebbe invece estendere la classe con attributi come “tipologia_fondo” o “cilindrata”.

L’ereditarietà è un principio importante dell’OOP che consente il riutilizzo del codice e promuove la modularità, facilitando la creazione e la manutenzione di sistemi software complessi e di grandi dimensioni. Definendo proprietà e comportamenti comuni in una classe madre e consentendo alle sottoclassi di ereditarli ed estenderli, l’OOP può contribuire a ridurre la duplicazione del codice e ad aumentare l’efficienza e l’efficacia del processo di sviluppo del software.

Tuttavia, l’abuso dell’ereditarietà può portare alla creazione di codice scarsamente mantenibile, o addirittura pericoloso (Pignatelli, Neethack, solo a titolo di esempio). Questo in quanto l’abuso dell’ereditarietà può portare a errori di design del codice o a mancanza di flessibilità (metodi non applicabili alle classi figlio, o overflow di ereditarietà che si trasmette tra diverse classi).

Polymorphism (polimorfismo)

Il polimorfismo riferisce alla capacità di oggetti di classi diverse di essere utilizzati in modo intercambiabile, anche se hanno tipi di dati o comportamenti diversi.

Il poliformismo consente un codice più flessibile e dinamico, permettendo agli oggetti di comportarsi in modo diverso a seconda del loro contesto. Ciò significa che gli oggetti possono essere trattati come la loro classe madre o interfaccia nativa e il loro comportamento può essere determinato in fase di esecuzione in base al tipo effettivo dell’oggetto.

Nell’OOP, il polimorfismo può essere ottenuto attraverso l’overriding e l’overloading dei metodi. L’overriding dei metodi consente a una sottoclasse di fornire la propria implementazione di un metodo ereditato dalla classe madre, mentre l’overloading dei metodi permette a più metodi con lo stesso nome ma con parametri diversi di coesistere all’interno di una classe o di una sua sottoclasse.

Ad esempio, si consideri una classe madre “Animale” con un metodo “make_sound”. Una sottoclasse “Cane” potrebbe sovrascrivere il metodo “make_sound” per abbaiare, mentre una sottoclasse “Gatto” potrebbe sovrascriverlo per miagolare. Inoltre, una classe “Zoo” potrebbe definire un metodo “feed” overloaded che accetta diversi tipi di animali e si comporta in modo diverso a seconda del tipo effettivo di animale da nutrire.

Il polimorfismo è un principio importante dell’OOP che consente di ottenere codice più dinamico, flessibile e riutilizzabile. Consentendo agli oggetti di comportarsi in modo diverso a seconda del loro contesto, il polimorfismo facilita la creazione e la manutenzione di sistemi software complessi e di grandi dimensioni e promuove l’interoperabilità e il riutilizzo del codice.

S.O.L.I.D. OOP

SOLID è un acronimo riferito a cinque ulteriori macro-principi afferibili alla programmazione orientata agli oggetti.

Tali principi furono teorizzati da Robert C. Martin (meglio conosciuto come Uncle Bob) negli anni 2000 (qui il link alla sorgente originale).

Notiamo che l’acronimo SOLID non fu ideato da Uncle Bob (che ne teorizzò i principi). L’acronimo fu coniato successivamente da Michael Feathers e da allora tramandato essenzialmente in tal modo.

Sebbene una trattazione esaustiva di SOLID richiederebbe un articolo a sé stante (e non sono pochi i libri che trattano specificatamente tale argomento), vogliamo fornirne una panoramica estremamente sintetica:

S – Single Responsibility Principle: afferma che ogni classe dovrebbe avere una ed una sola responsabilità, interamente incapsulata al suo interno.

O – Open/Close Principle: un’entità software dovrebbe essere aperta alle estensioni, ma chiusa alle modifiche.

L – Liskov Substitution Principle: gli oggetti dovrebbero poter essere sostituiti con dei loro sottotipi, senza alterare il comportamento del programma che li utilizza.

I – Interface Segregation Principle: sono preferibili più interfacce specifiche, rispetto a una singola generica.

D – Dependency Inversion Principle: una classe dovrebbe dipendere dalle astrazioni, non da classi concrete.

I principali vantaggi di OOP

Sebbene non sia volontà esprimere una preferenza per OOP in senso assoluto rispetto ad altri paradigmi di programmazione, l’utilizzo di OOP porta con sé indubbi e conclamati vantaggi.

I più rilevanti sono:

Riutilizzabilità del codice

L’OOP promuove la riutilizzabilità del codice, consentendo la creazione di oggetti che possono essere riutilizzati in diverse parti del programma o in diverse soluzioni software. Questo riduce la quantità di codice che deve essere scritto, testato e manutenuto e può anche migliorare l’efficienza e le prestazioni degli applicativi.

Sicurezza

Grazi ai principi di astrazione e incapsulamento, in OOP l’esposizione del dato nativo e dei metodi per modificarlo è limitato (se non, preferibilmente, evitato del tutto). Questo consente di creare applicativi “secured by design” dove la contraffazione del dato non può avvenire per vie accidentali.

Design dell’applicativo

OOP forza il programmatore a scomporre il processo (o il problema da affrontare) in parti indipendenti e isolate, risolvendole una alla volta. Dove possibile, si potranno adottare design e soluzioni note (design  pattern).

Questo evita di affrontare problemi di grandi dimensioni in modo inefficiente, inefficace, o ricorrendo a soluzioni non standard (anti-pattern).

Modularità e manutenibilità

L’OOP promuove la modularità e l’incapsulamento, rendendo il codice più facile da manutenere, modificare e testare. Ogni oggetto può essere trattato come un modulo separato con interfacce ben definite, il che rende più facile isolare e correggere i bug o aggiungere nuove funzionalità senza influenzare il resto del programma.

Astrazione e polimorfismo

L’OOP consente l’uso dell’astrazione e del polimorfismo, che possono rendere il codice più flessibile e adattabile a requisiti mutevoli. Nascondendo i dettagli dell’implementazione e consentendo agli oggetti di comportarsi in modo diverso in contesti diversi, l’OOP rende più facile estendere e modificare il programma senza dover modificare il codice esistente.

Scalabilità

L’OOP può essere utilizzato per costruire sistemi grandi e complessi, più facili da scalare e da mantenere. Suddividendo il sistema in oggetti più piccoli e modulari, il codice può essere facilmente distribuito e parallelizzato, consentendo migliori prestazioni e scalabilità.

Migliore organizzazione del codice

L’OOP consente di creare codice ben organizzato e di facile comprensione, che può essere mantenuto e riutilizzato più facilmente. Raggruppando funzioni e dati correlati in oggetti, l’OOP facilita la comprensione e la navigazione nel codice e può anche ridurre il potenziale di errori e bug.

Nel complesso, l’OOP offre diversi vantaggi tecnici che lo rendono una scelta popolare per la costruzione di sistemi software complessi e su larga scala. Promuovendo la riusabilità del codice, la modularità, l’astrazione e la scalabilità, l’OOP può aiutare gli sviluppatori a costruire un software migliore, più facile da mantenere ed estendere nel tempo.

Le sfide di OOP

D’altra parte, l’adozione di OOP non è una scelta win-win. Essa andrà ponderata in base alle competenze tecniche del team di sviluppo, della tipologia di problematica da affrontare, dell’approccio utilizzato in senso lato tra diversi progetti (così da ottimizzare la riusabilità di codice tra applicativi diversi ma con funzioni similari).

Le principali sfide che occorre affrontare nel design di OOP sono:

Complessità

L’OOP può introdurre ulteriore complessità nel codice, soprattutto quando il programma da sviluppare è di dimensioni ridotte e semplice. L’uso di oggetti, classi ed ereditarietà può rendere il codice più difficile da capire e da mantenere e può richiedere tempo e sforzi aggiuntivi per l’apprendimento.

Sovrastruttura

L’OOP può aggiungere sovrastruttura al codice, in particolare quando gli oggetti vengono creati e distrutti frequentemente. La memoria aggiuntiva e il tempo di elaborazione necessario per gestire gli oggetti possono ridurre le prestazioni del programma, soprattutto in ambienti con risorse limitate.

Curva di apprendimento

L’OOP può avere una curva di apprendimento ripida, soprattutto per i programmatori che sono alle prime armi con questo paradigma. I principi dell’incapsulamento, dell’ereditarietà e del polimorfismo possono essere difficili da capire e da implementare correttamente, e possono richiedere tempo e sforzi significativi per essere appresi.

Inflessibilità

L’OOP può essere poco flessibile in alcune situazioni, in particolare quando il programma da sviluppare ha requisiti dinamici o deve essere modificato frequentemente. In alcuni casi, la struttura e la gerarchia degli oggetti e delle classi possono rendere difficile modificare il programma senza interrompere le funzionalità esistenti. Con l’aumentare della complessità degli applicativi, le dipendenze tra oggetti e classi possono rendere ostico modificare agilmente il software.

Tempo di sviluppo

L’OOP può richiedere più tempo e sforzi per lo sviluppo rispetto ad altri paradigmi di programmazione. La creazione di oggetti, classi e interfacce può richiedere molto tempo, soprattutto quando si progettano sistemi complessi.

Adozione dei principi in modo corretto

OOP è un paradigma che impatta pesantemente il design di applicativi e le soluzioni architetturali utilizzate, in quanto richiede la scomposizione del processo in oggetti, classi, metodi, attributi. Tipicamente i problemi di business non si presentano in tale forma, occorre quindi un lavoro di astrazione da parte del programmatore per ricondurre la tematica di sviluppo all’interno del paradigma OOP. Il processo di design non è triviale e la corretta applicazione dei principi di OOP può fare la differenza nel creare le corrette sinergie e goderne dei vantaggi dati dall’adozione della programmazione orientata agli oggetti.

OOP: letture consigliate

Vuoi approfondire l’adozione di OOP?

Ti suggeriamo di partire da queste letture:

• Learning Object-Oriented Programming (Gaston Hillar).
• Design Patterns (Erich Gamma et al.).
• Practical Object-Oriented Programming: an Agile primer using Ruby (Sandi Metz).
• Object Design Style Guide (Matthias Noback).
• The Object-Oriented Thought Process (Matt Weisfeld).
• Clean code (Robert C. Martin).

Preferisci confrontarti con altre persone? Contattaci per condividere le tue esigenze!