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

Object Calisthenics: l'essenza OOP al servizio del TDD

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

Daniele Scillia - Senior Backend Developer @Mymenu

Dan the dev

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

Complessità

Comunicazione

Clean code

Object Calisthenics

Legge di Demetra

Keep It Stupid Simple

eXtreme Programming

Test-Driven Development

Tell, don't ask

Don't Repeat Yourself

Refactoring

Object-Oriented Programming

Object Calisthenics: l'essenza OOP al servizio del TDD

Di cosa parleremo

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

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

Object-oriented Programming

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

Complicato!

OOP

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

• I test sono documentazione vivente

Scrivi il test prima dell'implementazione.

Test-Driven Development

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

Spaventoso!

TDD

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

02

03

01

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...

Ci serve un aiuto nel mezzo

TDD

OOP

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

02

03

01

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à.

Esiste Object Calisthenics

TDD

Object Calisthenics

OOP

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

Cali che?

Object Calisthenics

Esistono casi particolari

Buon senso con la 8 e la 9

Obbligatori -> metodi pubblici

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

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.

Object Calisthenics

6. Un solo punto per ogni riga di codice7. Non usare abbreviazioni8. Mantieni tutte le entità piccole9. Massimo due variabili d'istanza10. 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

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à.

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).

Capiamo meglio le regole, con esempi

Le regole in dettaglio

Elementi più piccoli favoriscono il riutilizzo

Aiuta a rispettare il Single Responsibility Principle

1. Un solo livello di indentazione

Do

Don't

Favorisce la leggibilità: le guardie sono i casi particolari

Favorisce il polimorfismo per gestire i condizionali

2. Non usare la keyword else

Do

Don't

Favorisce la leggibilità e la semantica

Evita il code smell di Primitive Obsession

3. Astrai primitive e stringhe

Do

Don't

Favorisce la leggibilità e la semantica

4. Astrai gli array e le liste

I comportamenti della lista hanno una "casa"

Do

Don't

OOP -> network di entità che collaborano tramite messaggi

5. No getters/setters/property pubbliche

Euristica dell'OOP: Tell, don't ask

Do

Don't

Euristica dell'OOP: Legge di Demetra

Euristica dell'OOP: Tell, don't ask

6. Un punto per riga

Do

Don't

Le abbreviazioni causano facilmente fraintendimenti

7. Non usare abbreviazioni

Se un nome è ripetuto spesso, allarme duplicazione

Do

Don't

Aiuta a rispettare il Single-Responsibility Principle

8. Mantieni tutte le entità piccole

Favorisce la leggibilità e la semantica

Do

Don't

Molte dipendenze = poca coesione

9. Massimo due variabili d'istanza

Differenziare gli Orchestrators dagli Actuators

Do

Don't

OOP -> network di entità che collaborano tramite messaggi

10. Tutte le classi hanno uno stato (interno)

Euristica dell'OOP: Tell, don't ask

Do

Don't

OOP & TDD

Torniamo ai problemi

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

Complicato!

OOP

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

La vera natura dell'Object Oriented Programming

Class A

Class B

Class D

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

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

Avere una definizione condivisa di clean code

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

Rispettare le euristiche dell' OOP

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

Spaventoso!

TDD

Cosa fare nello step di Refactoring

Come gestire i mock e quando utilizzarli

Rispettare le tre regole del TDD

Qual è il prossimo test da scrivere

A quale livello scrivere il primo test

Testare sempre e solo il comportamento atteso

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

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

Le difficoltà del TDD

Cosa fare nello step di Refactoring

Come gestire i mock e quando utilizzarli

Rispettare le tre regole del TDD

Qual è il prossimo test da scrivere

A quale livello scrivere il primo test

Testare sempre e solo il comportamento atteso

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

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

Le difficoltà del TDD

Cosa fare nello step di Refactoring

Duplicazione

Object Calisthenics

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

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

Dobbiamo darci un obiettivo chiaro!

Vediamo un esempio delle regole applicate col TDD

Live coding

Almeno un pò...

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

Risolto!

OOP

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

Risolto!

TDD

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

Le regole di Object Calisthenics

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

TDD e step di refactoring

scambio di messaggi, non di dati interni

Recap

La vera natura dell'OOP

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

Domande?

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

Thanks!