Quando si inizia larealizzazione di un nuovo progetto software, spesso è necessarioaffrontare il dilemma se sia più conveniente aggiungere nuovefunzionalità a del codice già esistente e ben testato, oppureriscrivere l'applicazione da zero.

Generalmente si tende ariscrivere da zero gran parte del codice esistente, anche se questocomporta una grande mole di lavoro e la necessità di testarenuovamente la correttezza dei programmi generati.

In realtà sarebbe piùopportuno imparare a scrivere classi e metodi in modo tale che, unavolta terminati e testati, non sia più necessario modificarli e che al contempo consentano di aggiungere nuove funzionalità senzapregiudicare l'affidabilità del resto del sistema. 

Questo obiettivo puòessere raggiunto cercando di strutturare il codice in modo tale darispettare il principio OCP.

Definizione

Il principio open/closeafferma:

le entità software (classi, moduli, funzioni, ecc.) dovrebbero essere aperte alle estensioni e chiuse alle modifiche.

Se a prima vista questo assunto sembra contraddittorio, in realtàsignifica che dovrebbe essere possibile modificare il comportamentodi un'entità software senza alterare il suo codice sorgente. Inparticolare una volta completata l'implementazione di una classe,questa non dovrebbe essere più modificata, eccetto che per eliminareerrori; l'introduzione di nuove caratteristiche o la modifica diquelle esistenti dovrebbe richiedere la creazione di nuove classi.

Il principio single responsability

Uno dei modi piùsemplici per soddisfare il principio OCP, consiste nel progettareclassi che abbiano la responsabilità di svolgere un unico compito.In questo modo, la classe dovrà essere modificata soltanto se sarànecessario modificare quell'unica azione per cui è stata creata.

In termini di OCP (OpenClosed Principle), la suddivisione delle responsabilità del sistemasoftware in classi separate, permette di modificare ogni elemento inmodo indipendente, senza influire sugli altri.

La caratteristicafondamentale di SRP (Single Responsibility Principle) non èsemplicemente la scrittura di metodi e classi di dimensioni piùridotte, ma la realizzazione di classi che implementino un insiemecoeso di funzioni correlate tra di loro.

Un modo semplice persoddisfare SRP (Single Responsibility Principle) consiste nel chiedersi costantemente se ogni metodo e operazione che si introducein una classe sia direttamente correlato con il nome di tale classe;se si rileva che alcuni metodi non sono coerenti con il nome dellaclasse, probabilmente aggiungono nuove responsabilità ed èopportuno considerare se non sia il caso di spostare tali metodi inun'altra classe.

Ereditarietà dell'implementazione e dell'interfaccia

Un altro meccanismo chiaveper soddisfare il principio OCP è l'ereditarietà: le nuovecaratteristiche o le modifche alle funzionalità già esistenti diuna classe, sono implementate creando nuove classi che estendono laclasse originale; è bene evidenziare che non è necessario che lenuove classi abbiamo la medesima interfaccia della classe base.Questo tipo di ereditarietà viene definito ereditarietàdell'implementazione.

Un altro genere diereditarietà, opposta all'ereditarietà dell'implementazione èl'ereditarietà dell'interfaccia, dove le classi derivateereditano da una classe base astratta con funzioni virtuali pure: inquesto caso l'interfaccia è chiusa alle modifiche ed il suocomportamento può essere modificato implementando nuove classiderivate.

Entrambe le tecnicheintendono soddisfare il medesimo principio, seppur con sfumature differenti: l'ereditarietàdell'implementazione riduce la ridondanza del codice nelle classiderivate, spostandolo nella classe base; l'ereditarietàdell'interfaccia consente la gestione di un insieme di oggettidifferenti in modo uniforme.

La figura 1 mostra un esempio di architettura non conforme al principio open-close: sia la classe Client che la classe Server sono classi concrete e nel caso in cui si voglia sostituire la classe Server con un'altra potrebbe essere necessario modificare anche la classe Client.

La figura 2 mostra lemodifiche apportate per rendere l'archiettura conforme al principioOCP: questa volta la classe client utilizza una classe astrattadenominata AbstractServer con funzioni membro virtuali pure,eventuali modifiche o estensioni al server possono essere realizzatederivando nuove classi dalla classe base AbstractServer, senzamodificare il codice della classe Client.

E' bene notare che l'ereditarietà va utilizzata cercando di soddisfare il principio di Liskov.