Fredric Ragnar fredric.ragnar@hgo.se Telefon 0498-299948 Andreas Hedrén andreas.hedren@hgo.se

1. Föreläsning 7, Kapitel 7 Designa klasserKursbok: “Objects First with Java- A Practical Introduction using BlueJ”, David J. Barnes & Michael Kölling Fredric Ragnar fredric.ragnar@hgo.se Telefon 0498-299948 Andreas Hedrén andreas.hedren@hgo.se Telefon 0498-299954

2. Centrala delar • Ansvarsdriven design • Koppling (coupling) • Avgränsat ansvar (cohesion) • Refactoring

3. Mjukvara förändras • Mjukvara är sällan någonting som skrivs en gång och sedan är oförändrad • Mjukvara byggs ut, korrigeras, underhålls, görs om och förändras • Arbetet utförs av olika personer över tid (ofta årtionden)

4. Förändras eller dö • Det finns två alternativ för mjukvara: • Antingen genomgår den kontinuerlig förändring • Eller så dör den • Mjukvara som inte kan underhållas kommer att kastas

5. Kvalitativ kod Två viktiga delar för kvalitativ kod: • Koppling (coupling) • Avgränsat ansvar (cohesion)

6. Koppling (coupling) • Koppling syftar på länkar mellan olika delar av ett program • Om två klasser är starkt beroende av flera detaljer hos varandra finns det en stark koppling mellan klasserna • Vi eftersträvar svag koppling mellan klasser

7. Svag koppling Svag koppling gör det möjligt att: • Förstå en klass utan att behöva läsa andra klasser • Förändra en klass utan att det påverkar andra klasser • Därför ökar möjligheten att enkelt underhålla och återanvända koden

8. Avgränsat ansvar (cohesion) • Begreppet syftar på antalet och spridningen av olika funktionalitet som en enskild enhet är ansvarig för • Avgränsat ansvar är något som ska eftersträvas för både klasser och metoder • Vi eftersträvar att varje klass och metod har ett specifikt, väl avgränsat ansvar

9. Väl avgränsat ansvar Väl avgränsat ansvar gör det möjligt att enkelt: • Förstå vad klassen eller metoden gör • Ge tydliga och informativa namn • Återanvända klasser och metoder

10. Väl avgränsat ansvar Metoder • En metod ska ansvara för en och endast en väl avgränsad uppgift Klasser • Klasser ska representera en väl definierad och avgränsad enhet

11. Duplicering av kod Duplicering av kod, dvs att samma eller snarlik kod finns på flera platser: • Är en indikator på att designen är felaktig • Gör det svårare att underhålla koden • Kan medföra att fel introduceras vid underhåll

12. Ansvarsdriven design • Fråga: Vart ska vi lägga till en ny metod (vilken klass)? • Varje klass ska vara ansvarig för att ändra sin egen data • Klassen som äger data ska också ansvara för att bearbeta den • Ansvarsdriven design medför svag koppling

13. Gör förändringar lokala • Ett mål med att minska koppling (beroende) mellan klasser och med ansvarsdriven design är att göra förändringar lokala • När en förändring är nödvändig bör så få klasser som möjligt påverkas

14. Tänk efter före • När vi designar klasser bör vi fundera på vilka förändringar som är sannolika i framtiden • Vårt mål är att designa klasser som är enkla att förändra

15. Refactoring • Ny kod introduceras ofta när klasser underhålls • Klasser och metoder blir ofta längre • Då och då bör vi gå igenom koden för att se till att metoder och klasser har avgränsade ansvarsområden och att vi har svag koppling mellan klasser • Det kan var att flytta en metod till en annan klass eller att dela upp en metod i två • Processen kallas refactoring

16. Refactoring och testning • Separera refactoring av kod från andra förändringar • Testa både före och efter refactoring för att vara säker på att ingen funktionalitet har påverkats

17. Designfrågor Vanliga frågor: • Hur långa bör en klass vara? • Hur långa bör en metod vara? • Bör inte besvaras med antal rader utan genom att titta på ansvar och koppling till andra klasser

18. Designrekommendationer • En metod är för lång om den utför mer än en logiskt uppgift • En klass är allt för komplex om den representerar mer än en logisk enhet • Om det är svårt att ge metoden eller klassen ett bra namn är det ett tecken på att den har ett för stort ansvarsområde • Tänk Mañana

19. Summering • Ansvarsdriven design • Koppling • Avgränsat ansvar • Refactoring