un sistema fatto di oggetti che comunicano tra loro tramite messaggi<\/em><\/p>\n<\/blockquote>\n\n\n\n Prendiamo poi in considerazione anche le euristiche su cui si basa la Programmazione ad Oggetti, ancora pi\u00f9 sottovalutate della definizione stessa:<\/p>\n\n\n\n Nonostante la relativa semplicit\u00e0 di questi concetti, ci sono tanti fraintendimenti che si sono diffusi nelal community – vediamone alcuni esempi:<\/p>\n\n\n\n Ci sono ovviamente altri fraintendimenti, ma con questi esempi spero di aver reso chiaro che la maggior parte di queste situazioni sembra derivare dal dimenticarsi che gli oggetti non devnon condividere dati ma comportamenti.<\/p>\n\n\n\n Nel Software \u00e8 molto difficile essere d\u2019accordo su quale sia il design migliore, perch\u00e8 non esiste il design perfetto – \u00e8 molto pi\u00f9 semplice, invece, essere d\u2019accordo su cosa significhi codice \u201cscritto male\u201d.<\/p>\n\n\n\n In particolare, tra i principi di Clean Code esiste il concetto di Code Smells che ci aiuta a dare delle definizioni ai tipici pattern problematici che possiamo incontrare nel codice.<\/p>\n\n\n\n I Code Smells sono uno dei concetti pi\u00f9 importanti in Programmazione ad Oggetti: una volta che hai imparato a riconoscerli, il tuo feedback loop interno mentre scrivi codice migliorer\u00e0 drasticamente. Come ho scritto prima, non esiste il design perfetto: c\u2019e sempre un compromesso da qualche parte, e conoscere i Code Smell ci permette di accettare consciamente un compromesso invece di subirlo senza renderci conto della sua presenza.<\/p>\n\n\n\n Trovo rilevante anche riflettere sul fatto che non vengano chiamati errori, ma Gli smells di design sono quelli pi\u00f9 ad alto livello e sono sintomi di un problema grave – danno per\u00f2 poche informazioni riguardo alla causa. Se riconosciamo qualcuno di questi smell, dobbiamo mettere in discussione l\u2019architettura ed il design del nostro sistema.<\/p>\n\n\n\n I design smell sono<\/p>\n\n\n\n I code smells sono sintomi molto pi\u00f9 a basso livello, pi\u00f9 facili e meno costosi da correggere, perch\u00e8 danno feedback sul design locale del codice.<\/p>\n\n\n\n Possiamo riconoscere 5 categorie di code smells:<\/p>\n\n\n\n Ricapitolando, vogliamo imparare a riconoscere i Code Smell per poterli evitare, rimuovere o in alcuni casi accettare come trade-off consapevole.<\/p>\n\n\n\n Ma come facciamo ad evitare di incappare in questi Code Smell?<\/p>\n\n\n\n C\u2019\u00e8 in realt\u00e0 una pratica tanto semplice quanto poco conosciuta che possiamo utilizzare per assicurarci che le fondamenta dei principi di OOP vengano rispettate in modo naturale nel nostro codice: l\u2019 Object Calisthenics.<\/p>\n\n\n\n L\u2019Object Calisthenics \u00e8 una pratica introdotta da Jeff Bay nella ThoughtWorks Anthology, e consiste in un set di 10 regole da rispettare quando scrivi il tuo codice – regole che hanno lo scopo di dare un confine alle nostre decisioni di design: non ti dicono cosa fare, ma pi\u00f9 che altro cosa non fare.<\/p>\n\n\n\n Il nome prende ispirazione dalla pratica sportiva del Calisthenics, il cui nome nasce da due parole greche: “kal\u00f2s”, che significa bello, e “sth\u00e8nos”, che significa forte – perch\u00e8 il corpo di chi pratica questo sport diventer\u00e0 \u201cbello e forte\u201d. Le caratteristiche di questo sport sono quelle di poter essere praticato con nessun attrezzo (o quasi) e che gli esercizi possono essere adattati a qualunque livello atletico. Il parallelismo con le regole di Object Calisthenics \u00e8 evidente e spiega perch\u00e8 abbiano derivato il nome: grazie a queste regole, il nostro codice diventer\u00e0 \u201cbello e forte\u201d, ovvero \u201cfacile da leggere e cambiare\u201d, ed anche queste regole non richiedono uno specifico contesto o buy in da parte del team: possiamo semplicemente iniziare ad utilizzarle nel nostro lavoro individuale quotidiano.<\/p>\n\n\n\n Credo fortemente che l\u2019Object Calisthenics sia troppo sottovalutato, e sia anzi il miglior modo di iniziare ad imparare la Programmazione ad Oggetti mettendo delle basi chiare e solide. Queste regole nascono con l\u2019obiettivo di prevenire i Code Smell e sono strettamente correlate ai principi SOLID, fornendo quindi un primo step verso la scrittura di un design facile da capire, mantenere ed estendere.<\/p>\n\n\n\n 1)<\/strong> Un solo livello di indentazione<\/p>\n\n\n\n Mantieni un solo livello di indentazione nel codice, evitando di innestare tanti costrutti uno dentro l\u2019altro: questo favorisce sia la leggibilit\u00e0 che la creazione di metodi che facciano una sola cosa.<\/p>\n\n\n\n Wrong Example<\/strong><\/em> \u274c<\/p>\n\n\n Correct Example<\/strong><\/em> \u2705<\/p>\n\n\n Evitare gli \u201celse\u201d rende pi\u00f9 leggibile il codice perch\u00e8 possiamo avere una strada principale che si conclude alla fine del metodo, e nel mezzo gestire i casi particolari con delle guardie.<\/p>\n\n\n\n Wrong Example<\/strong><\/em> \u274c<\/p>\n\n\n Correct Example<\/strong><\/em> (with guard)<\/strong><\/em> \u2705<\/p>\n\n\n Nei metodi pubblici non dovremmo mai avere primitive come parametri, ma sempre oggetti.<\/p>\n\n\n\n Wrong Example<\/strong><\/em> \u274c<\/p>\n\n\n Correct Example<\/strong><\/em> \u2705<\/p>\n\n\n 4)<\/strong> First-class collections<\/strong><\/p>\n\n\n\n Uguale alle 3, ma per gli array: nei metodi pubblici non dovremmo mai avere array nativi come parametri, ma sempre oggetti.<\/p>\n\n\n\n Wrong Example<\/strong><\/em> \u274c<\/p>\n\n\n Correct Example<\/strong><\/em> \u2705<\/p>\n\n\n![\"Esempi](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/03\/image1-1.png\")
<\/figure>\n\n\n\n\n
\n
![\"Esempi](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/03\/image2-1024x401.png\")
<\/figure>\n\n\n\n\n
\n
$classA\u2192classB\u2192classC\u2192doSomething()<\/code>)<\/li>\n\n\n\n$classA\u2192classB\u2192doSomething()<\/code>)<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n\n\n\n![\"Esempi](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/03\/image3-1024x402.png\")
<\/figure>\n\n\n\n\n
Come riconoscere un codice problematico<\/h2>\n\n\n\n
smell<\/code> – odori, puzze. Il motivo per questo nome \u00e8 che questi pattern non sono di per s\u00e8 un problema, sono i sintomi di un problema – vengono infatti divisi in due categorie riferite al tipo di problema che stanno evidenziando: smell di design e smell di codice.<\/p>\n\n\n\nDesign smells<\/h3>\n\n\n\n
\n
Code smells<\/h3>\n\n\n\n
\n
Come evitare di fare questi errori<\/h2>\n\n\n\n
Le 10 regole di Object Calisthenics<\/h3>\n\n\n\n
class<\/span> WrongExample<\/span> <\/span>{\n public<\/span> function<\/span> doSomething<\/span>(int $a)<\/span> <\/span>{\n if<\/span> ($a > 0<\/span>) {\n if<\/span> ($a < 10<\/span>) {\n return<\/span> true<\/span>;\n }\n }\n return<\/span> false<\/span>;\n }\n}\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\nclass<\/span> CorrectExample<\/span> <\/span>{\n public<\/span> function<\/span> isBetween1And10<\/span>(int $a)<\/span> <\/span>{\n if<\/span> ($a > 0<\/span>) {\n return<\/span> $this<\/span>-> checkIfLowerThan10($a);\n }\n return<\/span> false<\/span>;\n }\n\n public<\/span> function<\/span> checkIfLowerThan10<\/span>(int $a)<\/span> <\/span>{\n if<\/span> ($a < 10<\/span>) {\n return<\/span> true<\/span>;\n }\n return<\/span> false<\/span>;\n }\n}\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n2)<\/strong> Non usare gli \u201celse\u201d<\/h3>\n\n\n\n
class<\/span> WrongExample<\/span> <\/span>{\n public<\/span> function<\/span> doSomething<\/span>(int $a)<\/span> <\/span>{\n if<\/span> ($a < 0<\/span>) {\n \/\/ do something<\/span>\n } else<\/span> {\n \/\/ handle special case<\/span>\n }\n }\n}\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\nclass<\/span> CorrectExample<\/span> <\/span>{\n public<\/span> function<\/span> doSomething<\/span>(int $a)<\/span> <\/span>{\n if<\/span> ($a > 0<\/span>) {\n \/\/ guard to handle special case<\/span>\n return<\/span>;\n }\n \/\/ do something<\/span>\n }\n}\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n3)<\/strong> Wrap all primitives and string<\/strong><\/h3>\n\n\n\n
class<\/span> WrongShop<\/span> <\/span>{\n public<\/span> function<\/span> buy<\/span>(int $money, string $productId)<\/span> <\/span>{\n \/\/ do something<\/span>\n }\n}\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\nclass<\/span> CorrectShop<\/span> <\/span>{\n public<\/span> function<\/span> buy<\/span>(Money $money, Product $product)<\/span> <\/span>{\n \/\/ do something<\/span>\n }\n}\n\nclass<\/span> Money<\/span> <\/span>{\n public<\/span> function<\/span> convert<\/span>(Currency $from, Currency $to)<\/span> <\/span>{ \/** ... *\/<\/span> }\n public<\/span> function<\/span> __toString<\/span>()<\/span> <\/span>{ \/** ... for example a specific format like \"$ 1.000,00\" *\/<\/span> }\n}\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\nclass<\/span> WrongLeague<\/span> <\/span>{\n public<\/span> function<\/span> newParticipants<\/span>(array $newParticipantsList)<\/span> <\/span>{\n \/\/ do something<\/span>\n }\n}\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\nclass<\/span> CorrectLeague<\/span> <\/span>{\n public<\/span> function<\/span> newParticipants<\/span>(Participants $newParticipants)<\/span> <\/span>{\n \/\/ do something<\/span>\n }\n}\n\n\/\/ Participants class allow us to create a list of participants validating data and offer behavior of order and go throught all the list<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n5)<\/strong>