Appunti riassuntivi Programmazione (parte 3, design OO e eccezioni)

=>>

RIASSUNTO CAPITOLO 4 PROGRAMMAZIONE LIBRO

Design OO

- 4.1: principi di design OO

Nella programmazione OO, sono sta9 iden9fica9 cinque principi di design

par9colarmente rilevan9 per la proge>azione delle classi iden9fica9 con l’acronimo

SOLID che sono:

1. SRP (Single Responsibility Principle): Una classe deve avere un solo mo9vo per

cambiare.

2. OCP (Open/Closed Principle): Deve essere possibile estendere il

comportamento di una classe senza doverla modificare.

3. LSP (Liskov Subs9tu9on Principle): Le classi derivate devono essere sos9tuibili

alla loro classe base.

4. ISP (Interface Segrega9on Principle): Disegnare interfacce a granularità fine

che siano specifiche per un cliente.

5. DIP (Dependency Inversion Principle): Dipendere dalle astrazioni non dalle

implementazioni concrete.

- 4.2: Principio di Aperto/Chiuso

Tale principio tra>a il problema della creazione di design che siano stabili nel tempo

tenendo conto che i requisi9 del sistema possono cambiare nel tempo.

Un modulo è de>o chiuso se è disponibile all’uso da parte di altri moduli e, quindi,

risul9 ben definito e stabile.

Un modulo è de>o aperto se è ancora disponibile all’estensione ed è possibile

aggiungere campi ad una stru>ura da9 che li con9ene o nuovi elemen9 al set di

funzioni che fornisce.

Fondamentalmente l’idea è quella di consen9re cambiamen9 al sistema senza

modificare il codice esistente; infaY, una buona tecnica per seguire l’OCP è quello

dell’incapsulamento per quanto riguarda la chiusura.

Questo perché se una classe riesce a nascondere i de>agli implementa9vi che non

saranno visibili nell’interfaccia fornita agli uten9 possiamo cambiare la classe senza

che questo si no9 al di fuori della classe stessa e, di conseguenza, gli uten9 non

devono riscrivere il codice.

Per quanto riguarda l’apertura si possono usare altre due tecniche: l’ereditarietà e la

composizione. In ques9 casi per effe>uare l’estensione di una classe base si può fare

l’override dei metodi, oppure comporre la classe derivata con un’altra classe

derivata, per fornire nuove funzionalità.

- 4.3: Principio di Singola Responsabilità

Tale principio afferma che ogni ogge>o in un sistema deve avere una sola

responsabilità e che tuY i servizi offer9 da un ogge>o devono avere come scopo

principale portare avan9 la responsabilità, dove per responsabilità si intende il

mo9vo per cambiare il codice di una classe.

Di conseguenza, possiamo dire che per rispe>are l’SRP una classe deve avere

un’unica ragione per cambiare.

Il seguente conce>o è legato al conce>o di coesione, che indica quanto metodi e

a>ribu9 siano collega9 fra loro e, contemporaneamente, allo scopo della classe.

InfaY, si tende a dire che una classe ha bassa o alta coesione, ed è bene proge>are

classi con alta coesione visto che queste classi tendono ad essere più riusabili e

mantenibili.

Spesso il conce>o di coesione è usato in contemporanea con il conce>o di

accoppiamento, che indica quanto moduli o classi dipendano l’un l’altro.

Di solito l’alta coesione è associata all’accoppiamento lasco, ovvero quando una

modifica ad una componente di una classe non influenzi la modifica ad un’altra

componente.

La par9colarità dell’SRP e dell’OCP è che sono stre>amente collega9 fra loro; tant’è

vero che seguire l’OCP vuol dire scrivere una classe talmente bene e con un

incapsulamento talmente efficiente che non è necessario ritornarci sopra per

aggiungere nuove funzionalità.

Tu>avia, questo è un obieYvo estremamente difficile da raggiungere ma grazie

all’SRP ci possiamo avvicinare.

- 4.4: principio di sos9tuzione di Liskov

Come già de>o in precedenza, l’LSP ci dice che, considerata una gerarchia di classi

formata da so>o-9pi e super-9pi, se S è un so>o-9po di T allora gli oggeY di 9po T

possono essere rimpiazza9 da oggeY di so>o-9po S senza alterare nessuna

proprietà desiderabile del programma.

Il problema da considerare per l’implementazione dell’LSP riguarda il

comportamento delle classi. Affinché il principio di Liskov venga rispe>ato, tu>e le

classi derivate devono conformarsi al comportamento che il codice client si aspe>a

dalla classe base che usa.

- 4.4.1: Regole per l’implementazione di LSP

Per implementare corre>amente una LSP deve succedere che valgano le seguen9

proprietà:

1. Precondizione: La condizione deve essere vera prima dell’esecuzione di un

metodo.

2. Postcondizione: La condizione deve essere vera dopo l’esecuzione di un

metodo.

3. Invariante: La condizione che deve essere vera sia prima che dopo l’esecuzione

di un metodo.

Da queste condizioni si possono definire le regole che aiutano ad implementare

corre>amente il principio di sos9tuzione di Liskov:

1. Le precondizioni non possono essere rafforzate nel so>o-9po; ovvero