Οσμές στη Σχεδίαση του Λογισμικού (Code Smells)

1. Οσμές στη Σχεδίαση του Λογισμικού (Code Smells) Πρόγραμμα Μεταπτυχιακών Σπουδών στην Εφαρμοσμένη Πληροφορική

2. Design Problems non-compliance with design principles excessive metric values violations of design heuristics lack of design patterns Fowler’s bad smells

3. Software Ageing well-designed code Design quality decays

4. Οσμές • Οι ενδείξεις κακής σχεδίασης λογισμικού είναι γνωστές ως «οσμές» λογισμικού (code smells - Fowler) • Τα code smells δεν προκαλούν προβλήματα στη λειτουργικότητα του συστήματος (για αυτό και συχνά συσσωρεύονται) • Ωστόσο, η ύπαρξή τους ενδέχεται να δυσχεράνει τη μελλοντική συντήρηση του λογισμικού (προσθήκη λειτουργικότητας, διόρθωση σφαλμάτων, κατανόηση, επαναχρησιμοποίηση κλπ) • Οι κακές οσμές ανιχνεύονται σχετικά εύκολα από τους έμπειρους σχεδιαστές και ο εντοπισμός μπορεί να υποβοηθάται από εργαλεία • Οι οσμές μπορούν να εξαλειφθούν με την εφαρμογή κατάλληλη αναδόμησης

5. Long Method Pieces of code with large size, high complexity and low cohesion int i; int sum = 0; for(i = 0; i < N; ++i) { sum = sum + i; } System.out.println(sum); int i; int product = 1; for(i = 0; i < N; ++i) { product = product *i; } System.out.println(product); Ενδεδειγμένη Αναδόμηση: Εξαγωγή μεθόδου (Extract Method)

6. Feature Envy A method is “more interested in a class other than the one it actually is in” Target Source m1() m2() m3() m(Target t) { t.m1(); t.m2(); t.m3(); } m() { m1(); m2(); m3(); } Ενδεδειγμένη Αναδόμηση: Μετακίνηση μεθόδου (Move Method)

7. Large (& Complex) Class You have one class doing work that should be done by two Καθηγητής Καθηγητής Υπάλληλος • + υπολΦόρου(); • + υπολΑπόδοσης(); • + υπολΑπόδοσης(); • + υπολΦόρου(); • - type : int • ΑΦΜ • Εφορία • Εισόδημα • Αξιολόγηση • Βαθμολογία • Σεμινάρια • - type : int • Αξιολόγηση • Βαθμολογία • Σεμινάρια • - type : int • ΑΦΜ • Εφορία • Εισόδημα Ενδεδειγμένη Αναδόμηση: Εξαγωγή Κλάσης (Extract Class)

8. Duplicated Code Number one on the stink parade is duplicated code. If you see the same code structure in more than one place, you can be sure that your program will be better if you find a way to unify them Ενδεδειγμένη Αναδόμηση: Pull Up Method

9. State Checking type State Checking manifests itself as conditional statements that select an execution path based on the state of an object StateB StateA Type Context Context • + method() { • } • + method() { • type.method(); • } +method() { } +method() { } +method() - type : int -STATE_A : int = 1 -STATE_B : int = 2 - type : int -STATE_A : int = 1 -STATE_B : int = 2 • switch(type) { • case STATE_A: • break; • case STATE_B: • break; • } doStateA(); doStateB(); Ενδεδειγμένη Αναδόμηση: Αντικατάσταση Συνθήκης με Πολυμορφισμός (Replace Conditional with Polymorphism)

10. And even more complex smells Refused Bequest

11. Context Mammal In the world of OO systems, inheritance is not a panacea + breatheAir() + regulateBodyTemp() + giveBirthToLiveYoung() + produceMilkIfFemale() + swim() + breatheAir() + regulateBodyTemp() + giveBirthToLiveYoung() + produceMilkIfFemale() + swim() + breatheAir() + regulateBodyTemp() + giveBirthToLiveYoung() + produceMilkIfFemale() + swim()

12. Problem Goal: Identification of Refused Bequest Code Smells Refused Bequest: “a subclass does not want to support the interface inherited from its parent class” [Fowler] non-trivial problem to resolve Appropriate Refactoring: Replace Inheritance with Delegation Famous quote: “Favor Composition over Inheritance” [GoF]