Enterprise design: i principi - parte 3

Una breve descrizione dei principi di design che sono alla base dei pattern.

KISS (Keep It Simple Stupid): evitare qualunque complicazione non necessaria. Scrivere codice in maniera semplice.

DRY (Don't Repeat Yourself): evitare di ripetere parti di codice in posizioni diverse. Se si ha la necessita' di copiare una funzionalita' probabilmente e' possibile passare attraverso forme di astrazione.

Tell don't Ask: questo principio e' legato con il concetto di incapsulamento. E' meglio dire agli oggetti cosa devono fare piuttosto che chiedere il loro stato e poi decidere l'azione da compiere. Questo permette di mantenere il concetto di responsabilita' e diminuire la dipendenza tra oggetti.

YAGNI ( You Ain't Gonna Need It): non metterlo se non e' necessario. Il concetto e' piuttosto ovvio, non scrivere codice che non e' necessario. La tendenza ad aggiungere funzioni non richieste solo perche' si pensa che potrebbero in futuro essere utili rischia solo di aggiungere linee da scrivere e poi da controllare. La metodologia TDD aiuta ad evitare ogni tentazione.

SoC ( Separation of Concerns): e' il processo di separazione di una parte di software in singole funzioni che incapsulano singoli comportamenti e dati che possono essere usati da altre classi.

Il prossimo gruppo di principi vengono raggruppati sotto la sigla SOLID

S Single Responsability Principle (SRP): questo principio e' strettamente legato al concetto della Separation of Concerns. Ogni oggetto deve avere un singolo motivo per cambiare e un singolo ambito di responsabilita'. Costruire grandi classi monolitiche rende il software meno leggibile e piu' difficile da mantenere.

O Open Closed Principle (OCP): una classe deve essere aperta per l'estendibilita' e chiusa per le modifiche. In altri termini nuovi comportamenti vanno aggiunti estendendo la classe senza modificare i comportamenti interni. Questa buona abitudine permette di evitare di rompere il funzionamento di classi esistenti e altre classi che da queste dipendono.

L Liskov Substitution Principle (LSP): questo principio suggerisce di creare classi derivate che possano sostituire la classe genitore sempre e senza modifiche. Quindi le classi derivate non modificano il comportamento della classe genitore nel rispetto del principio OCP.

I Interface Segregation Principle (ISP): il principio consiglia di implementare nei client solo quelle interfacce che vengono usate. Ovvero invece di progettare una grossa interfaccia pensare di dividerla per gruppi di client per le sole funzione che realmente vengono poi usate. Si cerca cosi' di evitare forti accoppiamenti non necessari.

D Dependency Inversion Principle (DIP): e' necessario dipendere da classi astratte piuttosto che da classi concrete. Questo principio sottolinea la convenienza di usare interfacce piuttosto che implementazioni. Si ottiene maggiore flessibilita' e minori accoppiamenti.

La prossima puntata sara' dedicata alla descrizione del pattern MVC e al MVP.