Delphi & Dintorni Webinar - Padroneggiare i principi SOLID con Delphi
0 likes154 views
Il webinar sui principi S.O.L.I.D. in Delphi, condotto da Marco Breveglieri, esplora le sfide di scrivere codice di qualità e manutenibile, evidenziando come l'alta coesione e il low coupling contribuiscano a un codice più testabile e leggibile. I cinque principi S.O.L.I.D. sono discussi come soluzioni per migliorare la struttura del codice e facilitare le modifiche. La presentazione incoraggia l'applicazione pratica di questi principi attraverso esempi concreti e mette in rilievo l'importanza di una buona progettazione per la collaborazione tra sviluppatori.
Delphi & Dintorni Webinar - Padroneggiare i principi SOLID con Delphi
- 1. D&D WebinarsD&D Webinars Webinar: I principi SOLID Capire e padroneggiare i principi SOLID in Delphi
- 2. D&D WebinarsD&D Webinars Marco Breveglieri Software and Web Developer, Teacher and Consultant @ABLS Team - Reggio Emilia, ITALY Homepage https://www.breveglieri.it Blog tecnico https://www.compilaquindiva.com Delphi Podcast https://www.delphipodcast.com Twitter @mbreveglieri
- 3. D&D WebinarsD&D Webinars Una premessa: il codice “cattivo”
- 4. D&D WebinarsD&D Webinars Cosa rende il codice “cattivo”? ● Classi che fanno troppe cose ● Metodi troppo lunghi e complessi ● Eccessiva dipendenza da altro codice ● Astrazioni esigenti e non fattorizzate ● Impossibilità di eseguire test automatici ● Gerarchie OOP ingiustificate
- 5. D&D WebinarsD&D Webinars Coupling “La misura in cui il tuo codice dipende da altri moduli, e viceversa”
- 6. D&D WebinarsD&D Webinars High vs Loose Coupling High Coupling ● Moduli difficilmente separabili ● Moduli difficilmente sostituibili ● Implementazioni intrecciate tra loro ● Modifiche a un punto del codice possono produrre effetti devastanti in un altro ● Relazioni tra i moduli stessi meno comprensibili Loose Coupling ● Leggibilità più alta del codice ● Comprensione agevolata ● Riusabile perché connesso da strati più sottili (es. interfacce) ● Manutenibile (perché le modifiche sono isolate) ● Testabile!
- 7. D&D WebinarsD&D Webinars Cohesion “Il grado con cui gli elementi di un modulo possono stare assieme”
- 8. D&D WebinarsD&D Webinars High Cohesion Si raggiunge quando le singole parti del sistema, sebbene diverse e con caratteristiche e funzionalità eterogenee, collaborano tra loro realizzando qualcosa di utile (ad alto valore per il cliente o per lo sviluppatore).
- 11. D&D WebinarsD&D Webinars S.O.L.I.D. è un acronimo SRP Single Responsibility Principle OCP Open/Closed Principle LSP Liskov Substitution Principle ISP Interface Segregation Principle DIP Dependency Inversion Principle
- 12. D&D WebinarsD&D Webinars Quando sono necessari? Quando si percepisce la presenza di “Code & Design Smell”... ● Codice troppo difficile da modificare ● Codice facile da “rompere” al minimo tocco ● Codice non riutilizzabile in altre situazioni simili ma in contesti differenti ● Eccessivo sforzo nel far fare al codice il proprio compito ● Codice inutilmente complicato per il proprio scopo
- 13. D&D WebinarsD&D Webinars Perché ne parliamo? ● Principi più importanti da seguire nella scrittura del codice ● Non sono così complessi come possono apparire a prima vista ● Consentono di apportare modifiche al software con minimi sforzi (in barba ai clienti) ● Rendono in molti casi la programmazione… più divertente ● Sono l’unico strumento che permette di scrivere codice “testabile” ● Aprono la strada a refactoring, buon design del codice e infinite serie di possibilità
- 14. D&D WebinarsD&D Webinars Come applicarlo? Tecnica SDD* *Schwartz Driven Development (usa lo Sforzo!)
- 15. D&D WebinarsD&D Webinars I principi S.O.L.I.D.
- 16. D&D WebinarsD&D Webinars Single Responsibility Principle SRP
- 17. D&D WebinarsD&D Webinars Single Responsibility Principle “Ogni modulo software deve avere una e una sola ragione per essere modificato” 1
- 18. D&D WebinarsD&D Webinars Single Responsibility Principle “Ogni classe deve svolgere uno e un solo compito” 2
- 19. D&D WebinarsD&D Webinars Demo Vediamo un esempio “errato”...
- 20. D&D WebinarsD&D Webinars Demo Vediamo un esempio corretto...
- 21. D&D Webinars Come si presenta il modello
- 22. D&D WebinarsD&D Webinars ● Cercare di individuare i possibili soggetti che possono richiedere modifiche a una classe ● Cercare di individuare i possibili motivi che possono richiedere modifiche a una classe ● Valutare costi e benefici prima di separare due implementazioni ● Tante classi piccole sono meglio di poche classi giganti (anche per l’IDE) ● Sfruttare la Dependency Injection per l’iniezione degli oggetti Recap
- 23. D&D WebinarsD&D Webinars Open/Closed Principle OCP
- 24. D&D WebinarsD&D Webinars Open Closed Principle “Ogni classe deve essere aperta a estensioni ma chiusa al cambiamento”
- 26. D&D WebinarsD&D Webinars Demo Vediamo un esempio “errato”...
- 27. D&D Webinars Applichiamo lo “Strategy Pattern”
- 28. D&D WebinarsD&D Webinars Demo Vediamo un esempio corretto...
- 29. D&D Webinars Come evolve il modello
- 30. D&D WebinarsD&D Webinars ● Utilizzare interfacce o classi astratte per creare “punti di estensione” ● Sostituire i costrutti case...of con oggetti esterni sfruttando ereditarietà ● Non esagerare con l’espansione, ovvero non esternalizzare fino ai minimi dettagli (valutare sempre prima i costi e i benefici) ● Se occorre referenziare una lista di oggetti esterni, utilizzare le classi “Container” con Generics Recap
- 31. D&D WebinarsD&D Webinars Liskov Substitution Principle LSP
- 32. D&D WebinarsD&D Webinars Liskov’s Substitution Principle “Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T” 1
- 33. D&D WebinarsD&D Webinars Liskov’s Substitution Principle “I sottotipi dovrebbero essere sempre sostituibili ai loro tipi di base” 2
- 34. D&D WebinarsD&D Webinars Liskov’s Substitution Principle “Un client dovrebbe consumare qualsiasi implementazione di una interfaccia senza che questo modifichi la correttezza del sistema” 3
- 35. D&D Webinars LSP Violation: l’esempio classico
- 36. D&D WebinarsD&D Webinars Demo Vediamo un esempio “errato”...
- 37. D&D WebinarsD&D Webinars Demo Vediamo un esempio corretto...
- 38. D&D WebinarsD&D Webinars ● Evitare gerarchie di classi logicamente inconsistenti ● Non condizionare la logica al tipo di oggetto passato (es. if AObj is TSquare…) ● Forzare uniformità nei comportamenti ○ Non restituire nil se non previsto nella logica principale ○ Non sollevare eccezioni tranne quelle lecite per la business logic Recap
- 39. D&D WebinarsD&D Webinars Interface Segregation Principle ISP
- 40. D&D WebinarsD&D Webinars Interface Segregation Principle “I client non devono essere forzati a dipendere da metodi che non utilizzano” 1
- 41. D&D Webinars ISP Violation: un esempio
- 42. D&D WebinarsD&D Webinars Demo Vediamo un esempio “errato”...
- 43. D&D WebinarsD&D Webinars Demo Vediamo un esempio corretto...
- 44. D&D Webinars ISP Violation: un esempio
- 45. D&D WebinarsD&D Webinars ● Ricordare che ogni interfaccia (interface) rappresenta un contratto ● Non creare interfacce cosiddette “asfittiche” (copia astratta della classe) ● Non aggiungere metodi non necessari alle interfacce ma disegnarle opportunamente ● Non estendere (se possibile) le interfacce esistenti, ma crearne di nuove Recap
- 46. D&D WebinarsD&D Webinars Dependency Inversion Principle DIP
- 47. D&D WebinarsD&D Webinars Dependency Inversion Principle “Occorre sempre dipendere da una interfaccia e non da una implementazione” 1
- 48. D&D WebinarsD&D Webinars Dependency Inversion Principle A. Moduli di alto livello non devono dipendere da moduli di basso livello, ed entrambi devono dipendere da astrazioni. B. Le astrazioni non devono dipendere dai dettagli. I dettagli devono dipendere dalle astrazioni. 2
- 49. D&D Webinars Consideriamo questo scenario iniziale.
- 50. D&D Webinars Nessun cambiamento funzionale, ma effetto di design ben visibile: il Reader diventa più astratto, più generico, ma usa un tipo di Book molto specifico (PdfBook).
- 51. D&D Webinars Soluzione: introduciamo un’ulteriore astrazione (EBook) applicando il principio ISP.
- 53. D&D WebinarsD&D Webinars ● Applicare il DIP automaticamente consente di abilitare l’uso degli altri principi ● ti forza quasi a usare correttamente il principio Open/Closed; ○ ti permette di separare le responsabilità ○ incentiva l’implementazione corretta dei sottotipi ○ offre l’opportunità di segregare le interfacce Recap
- 55. D&D WebinarsD&D Webinars S.O.L.I.D. non è così difficile... ● E’ sufficiente vedere i problemi esposti da una prospettiva differente nella stesura del codice ● Avremo come risultato codice ben scritto e facilmente manutenibile ● Non dobbiamo preoccuparci se avremo molte classi e interfacce: non c’è un limite ● Classi più piccole e mirate possono essere combinate più facilmente per creare sistemi complessi ● L’approccio semplifica il testing e la collaborazione tra sviluppatori Non è male, no? 😉
- 56. D&D WebinarsD&D Webinars A full demo
- 58. D&D WebinarsD&D Webinars Riferimenti e fonti Unsplash - Beautiful Free Images & Pictures (https://unsplash.com/) Meme Generator (https://imgflip.com/memegenerator) EnvatoTuts+ (https://code.tutsplus.com/series/the-solid-principles--cms-634) Thanks! 😅