Object Calisthenics: l'essenza OOP al servizio del TDD

Object Calisthenics: l'essenza OOP al servizio del TDD

Le regole dell' Object Calisthenics sono tanto di valore quanto poco conosciute: racchiudono l'essenza della Programmazione ad Oggetti e sono un eccellente punto di partenza e obiettivo minimo per lo step di refactoring del TDD

Dan the dev

Daniele Scillia - Senior Backend Developer @Mymenu

• XP advocate
• PUGMI Organizer
• Sito personale: danthedev.carrd.co
• Github: @danthedev
• Twitter: @danielescillia
• LinkedIn: daniele-scillia
• Youtube: Dan the dev
• Podcast: Dan the dev

Di cosa parleremo

Object Calisthenics: l'essenza OOP al servizio del TDD

Test-Driven Development

Object-Oriented Programming

Object Calisthenics

Clean code

Refactoring

eXtreme Programming

Don't Repeat Yourself

Keep It Stupid Simple

Comunicazione

Tell, don't ask

Legge di Demetra

Complessità

Dan the dev - danthedev.carrd.co - Twitter: @danielescillia

Object-oriented Programming

Software composto da entità (gli oggetti) che parlano tra loro tramite messaggi (i metodi).

• Incapsulamento, ereditarietà, polimorfismo
• Coesione e accoppiamento
• Principi SOLID

OOP

Complicato!

Dan the dev - danthedev.carrd.co - Twitter: @danielescillia

Test-Driven Development

Scrivi il test prima dell'implementazione.

• Ciclo RED-GREEN-REFACTOR
• Baby steps and unit tests
• Ogni riga di codice implementata nasce da un test

• I test sono documentazione vivente

TDD

Spaventoso!

Dan the dev - danthedev.carrd.co - Twitter: @danielescillia

Ci serve un aiuto nel mezzo

Se solo ci fosse qualcosa tra questi due elementi molto complessi che ci possa aiutare a comprendere meglio cosa sono e come possono aiutarci a scrivere codice pulito e funzionante...

03

01

02

TDD

OOP

Dan the dev - danthedev.carrd.co - Twitter: @danielescillia

Esiste Object Calisthenics

Le regole di Object Calisthenics sono un elemento che possono essere di grande aiuto per muovere i primi passi e capire a pieno questi due tool aiutandoci a mantenere la semplicità.

03

01

02

Object Calisthenics

TDD

OOP

Dan the dev - danthedev.carrd.co - Twitter: @danielescillia

Object Calisthenics

Cali che?

Dan the dev - danthedev.carrd.co - Twitter: @danielescillia

Object Calisthenics

L'Object Calisthenics consiste in un set di regole che possiamo utilizzare per assicurarci di rispettare i fondamentali del paradigma di Object Oriented Programming; sono state descritte da Jeff Bay nel libro "The ThoughtWorks Anthology" del 2008.

6. Un solo punto per ogni riga di codice7. Non usare abbreviazioni8. Mantieni tutte le entità piccole 9. Massimo due variabili d'istanza 10. Tutte le classi hanno uno stato

1. Un solo livello di indentazione
2. Non usare la keyword "else"
3. Astrai primitive e stringhe
4. Astrai gli array e le liste
5. No getters/setters/property pubbliche

Obbligatori -> metodi pubblici

Buon senso con la 8 e la 9

Esistono casi particolari

Dan the dev - danthedev.carrd.co - Twitter: @danielescillia

Il termine Calisthenics deriva dalle parole greche καλός (kalòs) che significa bello, e σθένος (sthénos), che significa forza. Grazie alle regole di Object Calisthenics, il nostro codice guadagnerà leggibilità (più bello) e solidità (più forte).

Le caratteristiche distintive della pratica sportiva del Calisthenics sono principalmente due: la possibilità di essere praticata con l'ausilio di pochissima/nessuna attrezzatura e l'essere adattabile progressivamente a qualsiasi livello atletico. Allo stesso modo le regole di Object Calisthenics possono essere applicate senza che siano necessariamente sostenute da un codice strutturato nella sua totalità ed anche in autonomia da parte di un membro del team, rivelandosi utili sia in un codice problematico che in un codice di buona qualità.

Le regole in dettaglio

Capiamo meglio le regole, con esempi

1. Un solo livello di indentazione

Do

Don't

Elementi più piccoli favoriscono il riutilizzo

Aiuta a rispettare il Single Responsibility Principle

2. Non usare la keyword else

Don't

Do

Favorisce la leggibilità: le guardie sono i casi particolari

Favorisce il polimorfismo per gestire i condizionali

3. Astrai primitive e stringhe

Don't

Do

Favorisce la leggibilità e la semantica

Evita il code smell di Primitive Obsession

4. Astrai gli array e le liste

Don't

Do

Favorisce la leggibilità e la semantica

I comportamenti della lista hanno una "casa"

5. No getters/setters/property pubbliche

Don't

Do

OOP -> network di entità che collaborano tramite messaggi

Euristica dell'OOP: Tell, don't ask

6. Un punto per riga

Don't

Do

Euristica dell'OOP: Legge di Demetra

Euristica dell'OOP: Tell, don't ask

7. Non usare abbreviazioni

Don't

Do

Le abbreviazioni causano facilmente fraintendimenti

Se un nome è ripetuto spesso, allarme duplicazione

8. Mantieni tutte le entità piccole

Don't

Do

Aiuta a rispettare il Single-Responsibility Principle

Favorisce la leggibilità e la semantica

9. Massimo due variabili d'istanza

Don't

Do

Molte dipendenze = poca coesione

Differenziare gli Orchestrators dagli Actuators

10. Tutte le classi hanno uno stato (interno)

Don't

Do

OOP -> network di entità che collaborano tramite messaggi

Euristica dell'OOP: Tell, don't ask

Torniamo ai problemi

OOP & TDD

OOP

Complicato!

Dan the dev - danthedev.carrd.co - Twitter: @danielescillia

Le regole di Object Calisthenics ci possono aiutare ad ottenere alcuni obiettivi:

Class B

Rispettare le euristiche dell' OOP

Class A

• Tell, don't ask
• Legge di Demetra (aka: don't talk with strangers)

Avere una definizione condivisa di clean code

E' molto più facile trovare agreement su brutto codice che su buon codice, le regole possono essere una base

Class D

La vera natura dell'Object Oriented Programming

Il software è composto da oggetti che parlano tra loro tramite messaggi (i metodi), senza esporre il loro stato interno.

TDD

Spaventoso!

Dan the dev - danthedev.carrd.co - Twitter: @danielescillia

Le difficoltà del TDD

Il TDD spesso viene indicato come difficile, i motivi indicati sono molteplici

A quale livello scrivere il primo test

Qual è il prossimo test da scrivere

Testare sempre e solo il comportamento atteso

Cosa fare nello step di Refactoring

Rispettare le tre regole del TDD

Come gestire i mock e quando utilizzarli

Dan the dev - danthedev.carrd.co - Twitter: @danielescillia

Le difficoltà del TDD

Il TDD spesso viene indicato come difficile, i motivi indicati sono molteplici

A quale livello scrivere il primo test

Qual è il prossimo test da scrivere

Testare sempre e solo il comportamento atteso

Cosa fare nello step di Refactoring

Rispettare le tre regole del TDD

Come gestire i mock e quando utilizzarli

Dan the dev - danthedev.carrd.co - Twitter: @danielescillia

Dobbiamo darci un obiettivo chiaro!

Spesso nello step di Refactoring c'e indecisione su come rifattorizzare, le regole ci danno un obiettivo chiaro.

Duplicazione

Cosa fare nello step di Refactoring

Object Calisthenics

Dan the dev - danthedev.carrd.co - Twitter: @danielescillia

Live coding

Vediamo un esempio delle regole applicate col TDD

OOP

Risolto!

Almeno un pò...

Dan the dev - danthedev.carrd.co - Twitter: @danielescillia

TDD

Risolto!

Dan the dev - danthedev.carrd.co - Twitter: @danielescillia

Recap

La vera natura dell'OOP

scambio di messaggi, non di dati interni

TDD e step di refactoring

lo step di refactoring è fondamentale, senza refactoring il TDD dimezza il suo valore

Le regole di Object Calisthenics

le regole possono aiutarci a raggiungere i primi due punti in modo semplice

Domande?

Dan the dev - danthedev.carrd.co - Twitter: @danielescillia

Thanks!

Dan the dev - danthedev.carrd.co - Twitter: @danielescillia