Pubblicità Progresso: Campagna Anti-IF

Obiettivo di questa campagna è sensibilizzare gli sviluppatori verso l’uso efficace dei principi di base del paradigma Object-Oriented.

Il primo passo per raggiungere questo obiettivo è essere consapevoli delle conseguenze in termini di design dell’uso degli IF (di qui il nome della campagna), e delle strutture di controllo in genere, applicati seguendo il paradigma imperativo anche in un linguaggio Object-Oriented.

Questa maggiore consapevolezza, obiettivo della nostra campagna, darà modo allo sviluppatore di comprendere come, applicando i principi del Design Object-Oriented, sia possibile raggiungere risultati di maggiore efficacia in termini di flessibilità, evolutività, comunicatività e testabilità.

La campagna nasce da una idea di Francesco Cirillo: “Molti team vogliono essere agili, ma non conoscono le basi per ridurre la complessità del loro codice. Saper usare gli oggetti consente di eliminare gli IF di tipo, che rappresentano il più diffuso strumento per compromettere flessibilità ed evolutività del software. Iniziamo da questi!”

Il problema di base è che l’IF di tipo crea dipendenza, accoppiamento tra moduli (metodi, oggetti, componenti, etc.) e aumenta i cammini possibili all’interno del nostro codice (riducendone così la leggibilità ).

L’IF sembra un modo rapido e comodo per realizzare i cambiamenti, ma proprio per quanto appena detto, IF dopo IF, si arriva a software non più modificabile e pieno di duplicazioni.

Un esempio semplice:

// classe Bond
double calculateValue() {
if(_type == BTP) {
return calculateBTPValue();
} else if(_type == BOT) {
return calculateBOTValue();
} else {
return calculateEUBValue();
}
}

Ogni modifica nel tipo delle obbligazioni, ad esempio una nuova obbligazione da valutare, porta a modificare il nostro pezzo di codice. Immaginate cosa può voler dire modificare metodi con IF e SWITCH innestati!

Gli oggetti forniscono uno strumento efficace per far sì che eventuali cambiamenti nei requisiti non si traducano in modifiche del codice:

// classe Bond
double calculateValue() {
_bondProfile.calculate();
}

// classe AbstractBondProfile
abstract double calculate();

// classe BTPBondProfile
double calculate() {
...
}
// classe BOTBondProfile
double calculate() {
...
}
// classe EUBondProfile
double calculate() {
...
}

Dov’è il vantaggio di togliere l’IF? Nel fatto che domani, la richiesta di un nuovo tipo di obbligazione comporterà la semplice creazione di una nuova classe, con la sola logica richiesta per il calcolo del valore di quella nuova obbligazione.

Non sempre la soluzione sta nel creare una classe astratta o una interfaccia, ma, sempre, la soluzione aumenterà la flessibilità, evolutività, comunicatività e testabilità del software.

Per ordinare la maglietta, clicca qua :)

Grazie a deneb per la notizia!

Fonte | MedotiAgili.it