Μεθοδολογίες Προγραμματισμού ΙΙ Αναδόμηση Λογισμικού Software Refactoring Παναγιώτης Σφέτσος, PhD

Παρουσίαση με θέμα: "Μεθοδολογίες Προγραμματισμού ΙΙ Αναδόμηση Λογισμικού Software Refactoring Παναγιώτης Σφέτσος, PhD"— Μεταγράφημα παρουσίασης:

1 Μεθοδολογίες Προγραμματισμού ΙΙ Αναδόμηση Λογισμικού Software Refactoring Παναγιώτης Σφέτσος, PhD http://aetos.it.teithe.gr/~sfetsos/ sfetsos@it.teithe.gr

2 2Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ  Στη σχεδίαση ενός έργου λογισμικού επιδιώκεται η:  Αποσύνθεση του συστήματος σε τμήματα  Ανάθεση αρμοδιοτήτων σε κάθε τμήμα  Επικύρωση ότι όλα τα τμήματα μαζί επιτυγχάνουν τους σκοπούς του συστήματος.  Γραφική αναπαράσταση του συστήματος, συνήθως με διαγράμματα UML.  Tο σύστημα θα πρέπει να επεκτείνεται και να τροποποιείται εύκολα με μικρή προσπάθεια. Σχεδίαση

3 3Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ  Δυσκαμψία (Rigidity): Το σύστημα είναι δύσκολο να τροποποιηθεί διότι κάθε αλλαγή οδηγεί σε πληθώρα αλλαγών σε άλλα τμήματα του συστήματος.  Ευθραυστότητα (Fragility): Οι αλλαγές που πραγματοποιούνται στο λογισμικό προκαλούν σφάλματα σε διάφορα σημεία.  Ακινησία (Immobility): Υπάρχει δυσκολία διαχωρισμού του συστήματος σε συστατικά τα οποία μπορούν να επαναχρησιμοποιηθούν σε άλλες εφαρμογές.  Έλλειψη ρευστότητας (Viscosity): Η πραγματοποίηση τροποποιήσεων με λάθος τρόπο είναι ευκολότερη από την πραγματοποίησή τους με τον ορθό τρόπο.  Περιττή Πολυπλοκότητα (Needless Complexity): Το λογισμικό περιλαμβάνει στοιχεία που δεν είναι (ούτε πρόκειται να γίνουν) χρήσιμα.  Περιττή Επανάληψη (Needless Repetition): Η σχεδίαση περιλαμβάνει επαναλαμβανόμενες δομές που θα μπορούσαν να ενοποιηθούν υπό μία κοινή αφαίρεση.  Αδιαφάνεια (Opacity): Δυσκολία κατανόησης μιας μονάδας (σε επίπεδο σχεδίου ή κώδικα). Συμπτώματα "κακής" σχεδίασης

4 4Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Στην εμφάνιση κάποιου συμπτώματος κακής σχεδίασης:  Οφείλουμε να λάβουμε υπόψη κάποιες βασικές αρχές σχεδίασης και να προβούμε σε κάποιες επεμβάσεις στο λογισμικό.  Η δραστηριότητα αυτή ονομάζεται αναδόμηση(Refactoring) Λύση

5 5Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ  Αρχή της Ανοικτής-Κλειστής Σχεδίασης (Open-Closed Principle - OCP)  Αρχή της Ενσωμάτωσης  Αρχή της Χαμηλής Σύζευξης  Αρχή της Μοναδικής Αρμοδιότητας (Single Responsibility Principle - SRP)  Αρχή της Υποκατάστασης της Liskov (Liskov Substitution Principle - LSP)  Αρχή της Αντιστροφής των Εξαρτήσεων (Dependency Inversion Principle - DIP)  Αρχή του Διαχωρισμού των Διασυνδέσεων (Interface Segregation Principle - ISP)  Οι ανωτέρω αρχές είναι προϊόν εμπειρίας δεκαετιών στην τεχνολογία λογισμικού.  Προτείνονται ως θεραπεία σε κάποιο σύμπτωμα που έχει ήδη διαπιστωθεί. Αρχές Αντικειμενοστρεφούς Σχεδίασης

6 6Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Οι οντότητες λογισμικού (κλάσεις, μονάδες, συναρτήσεις, κλπ) θα πρέπει να είναι ανοικτές για επέκταση, αλλά κλειστές για τροποποίηση.  Ανοικτές για επέκταση: Η συμπεριφορά της μονάδας μπορεί να επεκταθεί.  Κλειστές για τροποποίηση: Η επέκταση της συμπεριφοράς δεν οδηγεί σε αλλαγές του κώδικα της μονάδας.  Η αρχή της Ανοικτής-Κλειστής Σχεδίασης θεραπεύει τα συμπτώματα της δυσκαμψίας και ευθραυστότητας.  Η αφαίρεση (abstraction) και ο πολυμορφισμός (polymorphism) είναι η λύση. Αρχή της Ανοικτής-Κλειστής Σχεδίασης (1/6)

7 7Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Η κλάση Painter δεν συμμορφώνεται με την αρχή της Ανοικτής-Κλειστής Σχεδίασης, γιατί δεν μπορεί να "κλειστεί" έναντι νέων τύπων σχημάτων. Αν θέλαμε να επεκτείνουμε την κλάση ώστε να περιελάμβανε και τρίγωνα, θα έπρεπε να τροποποιήσουμε τον κώδικα της κλάσης. Γενικότερα, η κλάση πρέπει να τροποποιείται για κάθε νέο τύπο σχήματος που προστίθεται (ο κώδικας Java στο βιβλίο). Αρχή της Ανοικτής-Κλειστής Σχεδίασης (2/6) Παραβίαση της αρχής Ανοικτής-Κλειστής Σχεδίασης

8 8Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Η λύση με την αφαίρεση και τον πολυμορφισμό. Μια νέα αφηρημένη κλάση Shape προστίθεται στο σύστημα και ενσωματώνει οτιδήποτε μπορεί να μεταβληθεί, δηλαδή τη μέθοδο σχεδίασης οποιουδήποτε σχήματος. Η αφηρημένη κλάση ορίζει μια αφηρημένη μέθοδο draw(), ενώ οποιοδήποτε σχήμα είναι παράγωγη κλάση της Shape και υλοποιεί ανάλογα τη μέθοδο draw(). Η κλάση Painter δεν χρειάζεται να τροποποιηθεί και κατά συνέπεια συμμορφώνεται με την αρχή της Ανοικτής- Κλειστής Σχεδίασης (ο κώδικας Java στο βιβλίο). Αρχή της Ανοικτής-Κλειστής Σχεδίασης (3/6) Συμμόρφωση με την αρχή Ανοικτής-Κλειστής Σχεδίασης

9 9Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Παράδειγμα:  Πως θα κάνουμε το αυτοκίνητο να τρέξει με μία ‘τούρμπο’ μηχανή; Στην παρακάτω σχεδίαση, αλλάζοντας την Car (Κακή σχεδίαση). Η συμπεριφορά της μονάδας μπορεί να επεκταθεί δημιουργώντας νέες υποκλάσεις της αφαίρεσης (Καλή σχεδίαση). Αρχή της Ανοικτής-Κλειστής Σχεδίασης (4/6)

10 10Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Παράδειγμα: Παραβίαση OCP: Τι θα γίνει αν ο πελάτης θελήσει να αλλάξει server; Αρχή της Ανοικτής-Κλειστής Σχεδίασης (5/6) Συμμόρφωση με OCP : Σχεδιαστικό πρότυπο STRATEGY

11 11Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Εναλλακτική δομή: Σχεδιαστικό πρότυπο TEMPLATE METHOD. Η συμπεριφορά που προσδιορίζεται μέσα στην κλάση Policy μπορεί να επεκταθεί δημιουργώντας νέες υποκλάσεις της, χωρίς να απαιτείται τροποποίηση του πηγαίου κώδικα της. Αρχή της Ανοικτής-Κλειστής Σχεδίασης (6/6)  Τα δύο αυτά πρότυπα είναι οι συνηθέστεροι τρόποι συμμόρφωσης με την αρχή OCP.

12 12Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Αρχή της Ενσωμάτωσης ή αρχή της ενθυλάκωσης (Encapsulation Principle): Η εσωτερική κατάσταση ενός αντικειμένου πρέπει να είναι τροποποιήσιμη μόνο μέσω της δημόσιας διασύνδεσης του.  Oι ιδιότητες δεν πρέπει να είναι προσπελάσιμες εκτός της κλάσης (ορατότητα private), αλλά η τροποποίηση των τιμών των θα γίνεται μόνο μέσω των δημοσίων μεθόδων.  Συνήθως εφαρμόζεται ακόμα και αν δεν συνειδητοποιείται η χρησιμότητα. Αρχή της Ενσωμάτωσης (1/4)

13 13Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Παράδειγμα: class EncapTest{ private String name; private String idNum; private int age; public void setAge( int newAge) {age = newAge; } public void setName(String newName) {name = newName;} public void setIdNum( String newId) {idNum = newId;} public int getAge() {return age; } public String getName() {return name; } public String getIdNum() {return idNum; }} Αρχή της Ενσωμάτωσης (2/4) Μόνο μέσω των δημοσίων μεθόδων setters και getters μπορούν να προσπελαθούν τα ιδιωτικά πεδία. Πλεονεκτήματα: Τα πεδία γίνονται read- only ή write-only. Μόνο η κλάση έχει τον απόλυτο έλεγχο των δεδομένων των πεδίων. Οι χρήστες της κλάσης δεν γνωρίζουν πως αυτή αποθηκεύει τα δεδομένα της.

14 14Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ public class TestEncap{ public static void main(String args[]){ EncapTest encap = new EncapTest(); encap.setName("Nikas Nikos"); encap.setAge(30); encap.setIdNum("0623457"); System.out.println("Name : " + encap.getName()); System.out.println("Age : "+ encap.getAge()); } Αρχή της Ενσωμάτωσης (3/4)

15 15Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Συμπερασματικά: Η παραβίαση της αρχής μπορεί να προκαλέσει ορισμένα από τα σημαντικότερα προβλήματα. Επιτρέποντας την τροποποίηση των τιμών των ιδιοτήτων καταργείται η ομαδοποίηση δεδομένων και συμπεριφοράς. Στη συνέχεια θα είναι δύσκολο να εντοπιστούν ποια τμήματα κώδικα επηρεάζουν ποια δεδομένα. Αρχή της Ενσωμάτωσης (4/4)

16 16Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Αρχή της Χαμηλής Σύζευξης: Σε ένα σχέδιο λογισμικού πρέπει να επιδιώκεται η επίτευξη της μικρότερης δυνατής σύζευξης μεταξύ των συστατικών του. Πλεονεκτήματα:  Ανεξαρτησία μεταξύ των συστατικών (τεχνικές της αφαίρεσης και της απόκρυψης πληροφορίας).  Ευκολότερη η υλοποίηση, ο έλεγχος και η συντήρηση του λογισμικού.  Ευκολότερη η κατανομή του έργου σε διαφορετικούς προγραμματιστές και ευκολότερος ο εντοπισμός των σφαλμάτων. Αρχή της Χαμηλής Σύζευξης (1/3)

17 17Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Παράδειγμα κακής σχεδίασης (υψηλή σύζευξη): Αν τροποποιηθεί η Χρονόμετρο απαιτείται ο έλεγχος και ενδεχομένως η μεταγλώττιση των συσχετιζόμενων κλάσεων. Για να επαναχρησιμοποιηθεί η Χρονόμετρο απαιτείται “μεταφορά” των αναφορών της προς τις συσχετιζόμενες κλάσεις. Αρχή της Χαμηλής Σύζευξης (2/3)

18 18Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ  Δύσκολη η επίτευξη της μείωσης της σύζευξης. Μετράται εύκολα με την μετρική CBO (Coupling between Objects) των Chidamber & Kemerer, 1994. Η τιμή της μετρικής για μια κλάση Α ισούται με τον αριθμό των άλλων κλάσεων με τις ποίες υπάρχει σύζευξη. Ως σύζευξη θεωρείται:  η χρήση μεθόδων  η απευθείας πρόσβαση σε μέλη δεδομένων Επίσης έχει προταθεί να θεωρείται ως σύζευξη:  η χρήση τύπων μιας κλάσης ως παραμέτρων σε μεθόδους  η δημιουργία αντικειμένων  η ύπαρξη φιλικών κλάσεων  η αποστολή μηνυμάτων κατά τον χρόνο εκτέλεσης, κλπ. Αρχή της Χαμηλής Σύζευξης (3/3)

19 19Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Single Responsibility Principle (SRP), Tom De Marco (1979): Συνεκτικότητα (Cohesion) Αρχή της Μοναδικής Αρμοδιότητας: Μια κλάση πρέπει να έχει μόνο ένα λόγο να αλλάξει.  Κάθε κλάση δεν πρέπει να έχει περισσότερες από μία αρμοδιότητες (axis of change) Στο παράδειγμα (…ο κώδικας στο βιβλίο): Η κλάση Shape περιλαμβάνει λειτουργικότητα που αφορά τη γραφική διασύνδεση χρήστη (μέθοδος draw()) και λειτουργικότητα (μέθοδοι getXLowerRightCorner() και getYLowerRightCorner()). Η συμπερίληψη και των δύο αρμοδιοτήτων στην ίδια κλάση ενδέχεται να οδηγήσει σε προβλήματα (αλλαγή στη μία επιφέρει αλλαγή και στην άλλη). Αρχή της Μοναδικής Αρμοδιότητας (1/6)

20 20Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Η εφαρμογή της αρχής SRP επιβάλλει το διαχωρισμό των δύο αρμοδιοτήτων σε δύο τελείως διαφορετικές κλάσεις. Μετακινείται η λειτουργικότητα, που αφορά τις γεωμετρικές εφαρμογές μηχανολογικού σχεδιασμού, σε μια διαφορετική κλάση η οποία δέχεται το αντικείμενο Shape ως παράμετρο στον κατασκευαστή της. Οι αλλαγές που γίνονται στη σχεδίαση των σχημάτων δεν μπορούν να επηρεάσουν την εφαρμογή μηχανολογικού σχεδιασμού. Η συνεκτικότητα των δύο κλάσεων GeometricShape και Shape είναι πολύ υψηλή, καθώς οι λειτουργίες τους εξυπηρετούν έναν και μόνο σκοπό σε κάθε κλάση. Αρχή της Μοναδικής Αρμοδιότητας (2/6)

21 21Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Ποσοτικοποίηση του βαθμού συνεκτικότητας μιας κλάσης: Μετρική LCOM (Lack of Cohesion between Methods) των Chidamber & Kemerer, 1994. Παίρνουμε κάθε ζευγάρι μεθόδων σε μια κλάση. Αν μοιράζονται ασύνδετα σύνολα μεταβλητών αυξάνουμε το P κατά 1 (καμία κοινή μεταβλητή). Αν μοιράζονται τουλάχιστον μια μεταβλητή, τότε αυξάνουμε το Q κατά 1. LCOM1 = P – Q (αν P > Q), διαφορετικά LCOM1 = 0  LCOM1 = 0, σημαίνει συνεκτική κλάση.  LCOM1 > 0, σημαίνει ότι η κλάση πρέπει να ‘σπάσει’ σε δύο ή περισσότερες κλάσεις, καθότι οι μεταβλητές τους ανήκουν σε διαφορετικά σύνολα. Αρχή της Μοναδικής Αρμοδιότητας (3/6)  Κατά συνέπεια, όσο μεγαλύτερη η συνεκτικότητα, τόσο μικρότερη η τιμή της LCOM.

22 22Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Μια αρμοδιότητα ορίζεται ως μια "αιτία αλλαγών". Πως μπορεί να εντοπισθεί; interface DataStructure { public void add(Object o); public void remove(Object o); public void write(OutputStream out); public void read(InputStream in);} Οι αρμοδιότητες που υπάρχουν εδώ είναι δύο (διαχείριση των στοιχείων της δομής και η δυνατότητα αποθήκευσης και ανάκτησης των στοιχείων). Θα πρέπει αυτές να διαχωριστούν; Η απάντηση: εξαρτάται από τον τρόπο με τον οποίο αλλάζει η εφαρμογή. Αρχή της Μοναδικής Αρμοδιότητας (4/6)

23 23Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Αν η εφαρμογή αλλάζει συχνά κατά τέτοιο τρόπο ώστε να τροποποιείται η υπογραφή των μεθόδων προσθήκης/διαγραφής στοιχείων, τότε εμφανίζεται δυσκαμψία καθώς οι κλάσεις που καλούν τις μεθόδους αποθήκευσης/ανάκτησης θα πρέπει κάθε φορά να επανα- μεταγλωττίζονται και να ελέγχονται εκ νέου. Σε αυτή την περίπτωση οι δύο αρμοδιότητες θα πρέπει να διαχωριστούν. Οι εφαρμογές που χρησιμοποιούν είτε τη διασύνδεση DataStructure, είτε τη διασύνδεση Storable αποσυνδέονται μεταξύ τους. Αρχή της Μοναδικής Αρμοδιότητας (5/6)

24 24Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Όμως, αν η εφαρμογή δεν αλλάζει έτσι ώστε να τροποποιούνται οι αρμοδιότητες ανεξάρτητα, τότε δεν υπάρχει λόγος διαχωρισμού τους. Σε αυτή την περίπτωση, ο διαχωρισμός θα προκαλούσε περιττή πολυπλοκότητα. Κατά συνέπεια, ένας άξονας αλλαγών είναι άξονας αλλαγών μόνο αν οι αλλαγές συμβαίνουν πράγματι. Συμπερασματικά:  Η αρχή της Μοναδικής Αρμοδιότητας είναι ενδεχομένως η απλούστερη αρχή αντικειμενοστρεφούς σχεδίασης αλλά είναι και μία από τις δυσκολότερες να εφαρμοστεί.  Ο συγκερασμός αρμοδιοτήτων είναι κάτι που κάνουμε κατά φυσικό τρόπο. Ο εντοπισμός και ο διαχωρισμός αυτών των αρμοδιοτήτων αποτελεί κατά πολλούς ένα ουσιαστικό κομμάτι της σχεδίασης και ανάπτυξης λογισμικού.  Οι περισσότερες από τις αρχές και τους κανόνες που θα συζητηθούν στη συνέχεια σχετίζονται με τον ένα ή άλλο τρόπο με την αρχή SRP. Αρχή της Μοναδικής Αρμοδιότητας (6/6)

25 25Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Αρχή Υποκατάστασης της Liskov (Barbara Liskov MIT, 1988): Οι παράγωγοι τύποι πρέπει να μπορούν να υποκαθιστούν τους βασικούς τους τύπους.  Η B δημόσια κληρονομεί (“is-a”) από την A, σημαίνει ότι  Κάθε αντικείμενο τύπου Β είναι επίσης αντικείμενο του τύπου Α, σημαίνει  Ότι είναι αληθές για το αντικείμενο Α είναι επίσης αληθές για το αντικείμενο Β.  Η Α αντιπροσωπεύει μια πιο γενική έννοια, ενώ η Β μια πιο ειδική.  Όπου μπορεί να χρησιμοποιηθεί ένα αντικείμενο του τύπου Α, μπορεί να χρησιμοποιηθεί ένα αντικείμενο του τύπου Β (υποκατάσταση). Αρχή της Υποκατάστασης της Liskov (1/6)

26 26Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ  Η αρχή αυτή είναι μια επέκταση της αρχής της Ανοικτής-Κλειστής Σχεδίασης και σημαίνει ότι πρέπει να είμαστε σίγουροι ότι οι υποκλάσεις επεκτείνουν την βασική κλάση χωρίς να αλλοιώνουν την συμπεριφορά της.  Με άλλα λόγια αν μια μονάδα προγράμματος αναφέρεται στη βασική κλάση, τότε πρέπει να μπορεί να την αντικαταστήσει με μια αναφορά στην υποκλάση της, χωρίς να επηρεάζεται η λειτουργικότητα του προγράμματος. Αρχή της Υποκατάστασης της Liskov (2/6)

27 27Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Έστω μία συνάρτηση ή μέθοδος: m (A ref), if m (B ref) συμπεριφέρεται λάθος, όπου B υποκλάση της A, τότε η Β παραβιάζει την αρχή LSP. Λύση: Έλεγχος μέσα στην m αν περνά ως όρισμα αντικείμενο τύπου Β. Τότε παραβιάζεται η αρχή OCP. Αρχή της Υποκατάστασης της Liskov (3/6)

28 28Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Παράδειγμα παραβίασης της αρχής LSP: Έστω η κλάση Square είναι υποκλάση της Rectangle και ότι η κλάση Square επιστρέφεται από ένα factory σύμφωνα με κάποιες συνθήκες. Δεν γνωρίζουμε τον τύπο του επιστρεφό- μενου αντικειμένου αλλά ξέρουμε ότι είναι τύπου Rectangle. Ορίζουμε μήκος πλευράς = 4 και ύψος = 5 και ζητάμε το εμβαδό του. Θα έπρεπε να είναι 4 x 5 = 20, αλλά λαμβάνουμε 25. Αρχή της Υποκατάστασης της Liskov (4/6)

29 29Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ class Rectangle { protected int m_width; protected int m_height; public void setWidth(int width){m_width = width;} public void setHeight(int height){m_height = height;} public int getWidth(){return m_width;} public int getHeight(){return m_height;} public int getArea(){return m_width * m_height;}} Αρχή της Υποκατάστασης της Liskov (5/6)

30 30Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ class Square extends Rectangle { public void setWidth(int width){ m_width = width; m_height = width;} public void setHeight(int height){ m_width = height; m_height = height; }} class LspTest { private static Rectangle getNewRectangle() {// antikeimeno apo kapoio factory... return new Square();} Αρχή της Υποκατάστασης της Liskov (6/6) public static void main(String args[]) { Rectangle r = LspTest.getNewRectangle(); r.setWidth(4); r.setHeight(5); System.out.println(r.getArea()); }} Το αποτέλεσμα θα είναι 25, αντί 20. Δεν είναι τελικά ένα τετράγωνο επίσης και ένα ορθογώνιο ;;;;; Όσον αφορά τη συμπεριφορά ΌΧΙ. Η αρχή LSP επιβάλει ότι σε μία σχέση κληρονομικότητας η συμπεριφορά των παράγωγων κλάσεων πρέπει να μπορεί να υποκαταστήσει τη συμπεριφορά των βασικών κλάσεων.

31 31Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Αρχή της Αντιστροφής των Εξαρτήσεων (1/6) Αρχή Αντιστροφής των Εξαρτήσεων (DIP): α. Οι μονάδες υψηλού επιπέδου δεν θα πρέπει να εξαρτώνται από μονάδες χαμηλού επιπέδου. β. Οι αφαιρέσεις δεν θα πρέπει να εξαρτώνται από λεπτομέρειες. Οι λεπτομέρειες θα πρέπει να εξαρτώνται από αφαιρέσεις.  Στη Δομημένη Ανάλυση και Σχεδίαση (SADT) δημιουργούνται δομές όπου οι υψηλότερες μονάδες στην ιεραρχία καλούν μονάδες χαμηλότερων επιπέδων (άρα εξαρτώνται από αυτές). Η γενική στρατηγική του συστήματος εξαρτάται από τις λεπτομέρειες υλοποίησης των μονάδων χαμηλού επιπέδου.  Μία τέτοια δομή δεν είναι λογικά σωστή. Οι μονάδες στα υψηλότερα επίπεδα εμπεριέχουν τους γενικούς κανόνες της εφαρμογής και του πεδίου του προβλήματος (business rules) και συνεπώς πρέπει να έχουν προτεραιότητα και να είναι ανεξάρτητες από τις λεπτομέρειες υλοποίησης. Δυσκολία στην επαναχρησιμοποίηση.

32 32Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Αρχή της Αντιστροφής των Εξαρτήσεων (2/6) Στόχος της αρχής της Αντιστροφής των Εξαρτήσεων (Dependency-Inversion Principle) είναι να αντιστρέφει πλήρως τη δομή ενός συστήματος λογισμικού, έτσι ώστε οι μονάδες υψηλού επιπέδου να μην εξαρτώνται αλλά να καθορίζουν τους κανόνες για τις μονάδες χαμηλού επιπέδου. Αντεστραμμένη Διαστρωμάτωση: Η αφηρημένη διασύνδεση στο ανώτερο στρώμα και η υλοποιούσα στο χαμηλό στρώμα.

33 33Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Αρχή της Αντιστροφής των Εξαρτήσεων (3/6) Γενικός κανόνας: Να μην εξαρτόμαστε από συγκεκριμένες κλάσεις, αλλά από αφηρημένες διασυνδέσεις.  Όλες οι σχέσεις σε ένα πρόγραμμα θα πρέπει να καταλήγουν σε μία αφηρημένη κλάση ή σε μία διασύνδεση. Σύμφωνα με αυτόν τον κανόνα:  Καμία μεταβλητή δεν θα πρέπει να διατηρεί έναν δείκτη ή μία αναφορά προς κάποια συγκεκριμένη κλάση  Καμία κλάση δεν θα πρέπει να κληρονομεί μία συγκεκριμένη κλάση  Καμία μέθοδος δεν θα πρέπει να επικαλύπτει υλοποιημένη μέθοδο οποιασδήποτε από τις γονικές της κλάσεις  Οι ανωτέρω κανόνες θα παραβιαστούν τουλάχιστον μία φορά, στο σημείο που κατασκευάζουμε στιγμιότυπα  Επιπλέον, δεν υπάρχει λόγος να τους ακολουθήσουμε αν γνωρίζουμε ότι μία συγκεκριμένη κλάση δεν θα αλλάξει

34 34Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Αρχή της Αντιστροφής των Εξαρτήσεων (4/6) Παράδειγμα Ένας ελεγκτής (Controller) αντιλαμβάνεται κάποια αλλαγή στο εξωτερικό περιβάλλον και αποστέλλει μήνυμα ενεργοποίησης/απενεργοποίησης στο σχετιζόμενο αντικείμενο συναγερμού (LampAlarm). Η κλάση Controller ελέγχει αντικείμενα VisibleAlarm και μόνον αυτά Αν αλλάξει ο πηγαίος κώδικας της LampAlarm (π.χ. πράσινο φως) θα πρέπει να επαναμεταγλωττιστεί και ο κώδικας της Controller Αν θέλουμε να συνδέσουμε τον ελεγκτή με άλλο μηχανισμό (π.χ. έναν κινητήρα), πρέπει να τροποποιήσουμε τον ελεγκτή Η πολιτική υψηλού επιπέδου δεν έχει διαχωριστεί από την υλοποίηση

35 35Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Αρχή της Αντιστροφής των Εξαρτήσεων (5/6) Εντοπισμός της Υποκείμενης Αφαίρεσης και Αντιστροφή της Εξάρτησης: Ευελιξία: Τα αντικείμενα Controller ελέγχουν οτιδήποτε συμμορφώνεται με τη διασύνδεση ControllerServer. Ακόμα τα αντικείμενα που θα δημιουργηθούν στο μέλλον (επέκταση).

36 36Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Αρχή της Αντιστροφής των Εξαρτήσεων (6/6) Συμπερασματικά: Διαδικασιακός προγραμματισμός: Δομές όπου οι μονάδες υψηλού επιπέδου εξαρτώνται από τις μονάδες χαμηλού επιπέδου. Ατυχής Επιλογή: Η πολιτική του συστήματος είναι ευάλωτη σε αλλαγές της υλοποίησης. Αντικειμενοστρεφής Προγραμματισμός: Δομές αντεστραμμένες Πολλοί θεωρούν τη διαφορά αυτή ως ειδοποιό.

37 37Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Αρχή του Διαχωρισμού των Διασυνδέσεων (1/5) Αρχή Διαχωρισμού των Διασυνδέσεων (ISP) 1ος ορισμός: Πολλές εξειδικευμένες διασυνδέσεις είναι προτιμότερες από μια γενική διασύνδεση 2ος ορισμός: Οι πελάτες δεν θα πρέπει να εξαναγκάζονται σε εξάρτηση από μεθόδους που δεν χρησιμοποιούν.

38 38Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Αρχή του Διαχωρισμού των Διασυνδέσεων (2/5)  Θα πρέπει να εξετάζεται προσεκτικά η σχεδίαση των διασυνδέσεων  Η αρχή ISP διαπραγματεύεται τα μειονεκτήματα των ογκωδών διασυνδέσεων ("fat" interfaces).  Οι κλάσεις που έχουν μεγάλο αριθμό δημόσιων μεθόδων είναι κλάσεις των οποίων η διασύνδεση δεν είναι συνεκτική και οι μέθοδοι μπορούν να διαχωριστούν σε ένα σύνολο διασυνδέσεων. Κάθε σύνολο εξυπηρετεί μία διαφορετική ομάδα από πελάτες.  Οι πελάτες θα πρέπει να γνωρίζουν πολλές αφηρημένες κλάσεις βάσης με συνεκτικές διασυνδέσεις.

39 39Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Αρχή του Διαχωρισμού των Διασυνδέσεων (3/5) Παράδειγμα παραβίασης της αρχής (ISP): Fat – διασύνδεση που αναγκάζει τις υλοποιούσες υποκλάσεις να εκτελούν μη χρήσιμες – μεθόδους. public interface Animal { void fly(); void run(); void bark();} public class Bird implements Animal { public void bark() { /* den xreiazetai */ } public void run() {// kodikas } public void fly() { // kodikas}} public class Cat implements Animal { public void fly() {/* den xreiazetai */ } public void bark() {/* den xreiazetai */ } public void run() {// kodikas}} public class Dog implements Animal { public void fly() { } public void bark() {//kodikas} public void run() {//kodikas}}

40 40Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Αρχή του Διαχωρισμού των Διασυνδέσεων (4/5) Παράδειγμα υλοποίησης σύμφωνα με την αρχή ISP: Πολλές εξειδικευμένες διασυνδέσεις. public interface Flyable {void fly();} public interface Runnable {void run();} public interface Barkable {void bark();} public class Bird implements Flyable, Runnable { public void run() {//kodikas} public void fly() {//kodikas}} public class Cat implements Runnable{ public void run() {//kodikas}} public class Dog implements Runnable, Barkable { public void bark() {//kodikas} public void run() {//kodikas}}

41 41Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ Αρχή του Διαχωρισμού των Διασυνδέσεων (5/5) Συμπερασματικά:  Σε μια καλή σχεδίαση, οι πελάτες θα πρέπει να εξαρτώνται μόνο από τις μεθόδους τις οποίες καλούν  Αυτό επιτυγχάνεται διαχωρίζοντας τη διασύνδεση σε πολλές διασυνδέσεις, μία για κάθε κατηγορία πελατών