Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Delphi & Dintorni Webinar - Padroneggiare i principi SOLID con Delphi

Molti sviluppatori continuano a porsi ancora oggi domande esistenziali, ad esempio "Come posso scrivere codice mantenibile?" oppure "Come posso rendere il codice testabile?". Purtroppo non ci sono keyword, né talismani che possano donare la qualità di essere "buono" al nostro codice senza sforzo, tuttavia è sufficiente rispettare pochi e sani principi di progettazione, detti principi SOLID. In questo webinar vedremo come soddisfare tali principi e scrivere "buon codice" con Delphi, rendendolo stabile, mantenibile, estensibile, comprensibile e scalabile, aprendo nel contempo la porta ad altri scenari visti talvolta con diffidenza, come il Testing, che diverranno così semplici e addirittura automatici.

  • Be the first to comment

  • Be the first to like this

Delphi & Dintorni Webinar - Padroneggiare i principi SOLID con Delphi

  1. 1. D&D WebinarsD&D Webinars Webinar: I principi SOLID Capire e padroneggiare i principi SOLID in Delphi
  2. 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. 3. D&D WebinarsD&D Webinars Una premessa: il codice “cattivo”
  4. 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. 5. D&D WebinarsD&D Webinars Coupling “La misura in cui il tuo codice dipende da altri moduli, e viceversa”
  6. 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. 7. D&D WebinarsD&D Webinars Cohesion “Il grado con cui gli elementi di un modulo possono stare assieme”
  8. 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).
  9. 9. D&D WebinarsD&D Webinars ...altrimenti...
  10. 10. D&D WebinarsD&D Webinars Introduzione
  11. 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. 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. 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. 14. D&D WebinarsD&D Webinars Come applicarlo? Tecnica SDD* *Schwartz Driven Development (usa lo Sforzo!)
  15. 15. D&D WebinarsD&D Webinars I principi S.O.L.I.D.
  16. 16. D&D WebinarsD&D Webinars Single Responsibility Principle SRP
  17. 17. D&D WebinarsD&D Webinars Single Responsibility Principle “Ogni modulo software deve avere una e una sola ragione per essere modificato” 1
  18. 18. D&D WebinarsD&D Webinars Single Responsibility Principle “Ogni classe deve svolgere uno e un solo compito” 2
  19. 19. D&D WebinarsD&D Webinars Demo Vediamo un esempio “errato”...
  20. 20. D&D WebinarsD&D Webinars Demo Vediamo un esempio corretto...
  21. 21. D&D Webinars Come si presenta il modello
  22. 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. 23. D&D WebinarsD&D Webinars Open/Closed Principle OCP
  24. 24. D&D WebinarsD&D Webinars Open Closed Principle “Ogni classe deve essere aperta a estensioni ma chiusa al cambiamento”
  25. 25. D&D Webinars Lo scenario
  26. 26. D&D WebinarsD&D Webinars Demo Vediamo un esempio “errato”...
  27. 27. D&D Webinars Applichiamo lo “Strategy Pattern”
  28. 28. D&D WebinarsD&D Webinars Demo Vediamo un esempio corretto...
  29. 29. D&D Webinars Come evolve il modello
  30. 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. 31. D&D WebinarsD&D Webinars Liskov Substitution Principle LSP
  32. 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. 33. D&D WebinarsD&D Webinars Liskov’s Substitution Principle “I sottotipi dovrebbero essere sempre sostituibili ai loro tipi di base” 2
  34. 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. 35. D&D Webinars LSP Violation: l’esempio classico
  36. 36. D&D WebinarsD&D Webinars Demo Vediamo un esempio “errato”...
  37. 37. D&D WebinarsD&D Webinars Demo Vediamo un esempio corretto...
  38. 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. 39. D&D WebinarsD&D Webinars Interface Segregation Principle ISP
  40. 40. D&D WebinarsD&D Webinars Interface Segregation Principle “I client non devono essere forzati a dipendere da metodi che non utilizzano” 1
  41. 41. D&D Webinars ISP Violation: un esempio
  42. 42. D&D WebinarsD&D Webinars Demo Vediamo un esempio “errato”...
  43. 43. D&D WebinarsD&D Webinars Demo Vediamo un esempio corretto...
  44. 44. D&D Webinars ISP Violation: un esempio
  45. 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. 46. D&D WebinarsD&D Webinars Dependency Inversion Principle DIP
  47. 47. D&D WebinarsD&D Webinars Dependency Inversion Principle “Occorre sempre dipendere da una interfaccia e non da una implementazione” 1
  48. 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. 49. D&D Webinars Consideriamo questo scenario iniziale.
  50. 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. 51. D&D Webinars Soluzione: introduciamo un’ulteriore astrazione (EBook) applicando il principio ISP.
  52. 52. D&D WebinarsD&D Webinars Demo
  53. 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
  54. 54. D&D WebinarsD&D Webinars Conclusioni
  55. 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. 56. D&D WebinarsD&D Webinars A full demo
  57. 57. D&D WebinarsD&D Webinars Domande? Questions?
  58. 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! 😅

×