Η παρουσίαση φορτώνεται. Παρακαλείστε να περιμένετε

Η παρουσίαση φορτώνεται. Παρακαλείστε να περιμένετε

Μεθοδολογίες Προγραμματισμού ΙΙ ΣΧΕΔΙΑΣΗ ΑΝΤΙΚΕΙΜΕΝΩΝ ΜΕ ΑΡΜΟΔΙΟΤΗΤΕΣ GRASP - Πρότυπα Παναγιώτης Σφέτσος, PhD

Παρόμοιες παρουσιάσεις


Παρουσίαση με θέμα: "Μεθοδολογίες Προγραμματισμού ΙΙ ΣΧΕΔΙΑΣΗ ΑΝΤΙΚΕΙΜΕΝΩΝ ΜΕ ΑΡΜΟΔΙΟΤΗΤΕΣ GRASP - Πρότυπα Παναγιώτης Σφέτσος, PhD"— Μεταγράφημα παρουσίασης:

1 Μεθοδολογίες Προγραμματισμού ΙΙ ΣΧΕΔΙΑΣΗ ΑΝΤΙΚΕΙΜΕΝΩΝ ΜΕ ΑΡΜΟΔΙΟΤΗΤΕΣ GRASP - Πρότυπα Παναγιώτης Σφέτσος, PhD

2 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ2 Στόχοι Στόχοι • Ανάθεση αρμοδιοτήτων ή εκχώρηση ευθυνών • Ανάλυση των GRASP προτύπων • Παραδείγματα χρήσης • Ανάθεση αρμοδιοτήτων ή εκχώρηση ευθυνών • Ανάλυση των GRASP προτύπων • Παραδείγματα χρήσης

3 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ3 Στόχοι • Σημαντική ικανότητα στην ΟΟΑ/D είναι η επιδέξια ανάθεση αρμοδιοτήτων (ή εκχώρηση ευθυνών) στα Αντικείμενα. αρμοδιοτήτων (ή εκχώρηση ευθυνών) στα Αντικείμενα. • Γιατί; Για σταθερότητα, επαναχρησιμοποίηση και συντηρησιμότητα • Η κατανόηση και η χρησιμοποίηση των σχεδιαστικών αρχών βασίζεται στα πρότυπα και στην ανάθεση αρμοδιοτήτων. βασίζεται στα πρότυπα και στην ανάθεση αρμοδιοτήτων. Τα πρότυπα GRASP (General Responsibility Assignment Software Pattern) αποτελούν ένα βοήθημα εκμάθησης και κατανόησης της ουσιαστικής σχεδίασης αντικειμένων, καθώς η κατανόησης της ουσιαστικής σχεδίασης αντικειμένων, καθώς η αιτιολόγηση της προσέγγισής της γίνεται με ένα μεθοδικό, λογικό, αιτιολόγηση της προσέγγισής της γίνεται με ένα μεθοδικό, λογικό, και επεξηγηματικό τρόπο. • Σημαντική ικανότητα στην ΟΟΑ/D είναι η επιδέξια ανάθεση αρμοδιοτήτων (ή εκχώρηση ευθυνών) στα Αντικείμενα. αρμοδιοτήτων (ή εκχώρηση ευθυνών) στα Αντικείμενα. • Γιατί; Για σταθερότητα, επαναχρησιμοποίηση και συντηρησιμότητα • Η κατανόηση και η χρησιμοποίηση των σχεδιαστικών αρχών βασίζεται στα πρότυπα και στην ανάθεση αρμοδιοτήτων. βασίζεται στα πρότυπα και στην ανάθεση αρμοδιοτήτων. Τα πρότυπα GRASP (General Responsibility Assignment Software Pattern) αποτελούν ένα βοήθημα εκμάθησης και κατανόησης της ουσιαστικής σχεδίασης αντικειμένων, καθώς η κατανόησης της ουσιαστικής σχεδίασης αντικειμένων, καθώς η αιτιολόγηση της προσέγγισής της γίνεται με ένα μεθοδικό, λογικό, αιτιολόγηση της προσέγγισής της γίνεται με ένα μεθοδικό, λογικό, και επεξηγηματικό τρόπο. Ανάθεση Αρμοδιοτήτων (Assigning Responsibilities)

4 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ4 Στόχοι Αρμοδιότητες και Μέθοδοι - 1 Η UML ορίζει μια ευθύνη ή αρμοδιότητα ως:  «μία σύμβαση (συμβόλαιο) ή υποχρέωση » μιας οντότητας (συμπεριφορά)  Υλοποίηση με μεθόδους συνήθως κατά τη διάρκεια της δημιουργίας διαγραμμάτων αλληλεπίδρασης. διαγραμμάτων αλληλεπίδρασης. Οι ευθύνες είναι δύο τύπων: Πράξη (doing responsibility)  Κάτι που κάνει μόνο του (πχ. δημιουργία ενός αντικειμένου, ενός υπολογισμού, κλπ.)  Έναρξη λειτουργίας σε άλλη κλάση  Έλεγχος και συντονισμός ενεργειών σε άλλες κλάσεις Γνώση  σχετικά με ιδιωτικά δεδομένα  σχετικά σε σχετιζόμενα αντικείμενα  σχετικά με πράγματα που μπορεί να παράγει ή να υπολογίσει Η UML ορίζει μια ευθύνη ή αρμοδιότητα ως:  «μία σύμβαση (συμβόλαιο) ή υποχρέωση » μιας οντότητας (συμπεριφορά)  Υλοποίηση με μεθόδους συνήθως κατά τη διάρκεια της δημιουργίας διαγραμμάτων αλληλεπίδρασης. διαγραμμάτων αλληλεπίδρασης. Οι ευθύνες είναι δύο τύπων: Πράξη (doing responsibility)  Κάτι που κάνει μόνο του (πχ. δημιουργία ενός αντικειμένου, ενός υπολογισμού, κλπ.)  Έναρξη λειτουργίας σε άλλη κλάση  Έλεγχος και συντονισμός ενεργειών σε άλλες κλάσεις Γνώση  σχετικά με ιδιωτικά δεδομένα  σχετικά σε σχετιζόμενα αντικείμενα  σχετικά με πράγματα που μπορεί να παράγει ή να υπολογίσει

5 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ5 Στόχοι Αρμοδιότητες και Μέθοδοι - 2 Που ψάχνουμε ; Στο Domain Model ή στο Design Model για να αναλύσουμε τις κλάσεις που έχουν τις πληροφορίες που χρειάζονται; - Στο design model, αν υπάρχουν σχετιζόμενες κλάσεις - Συνήθως στο domain model, ιδίως στην αρχή της ανάπτυξης Οι ευθύνες ανατίθενται στις κλάσεις αντικειμένων κατά τη διάρκεια του σχεδιασμού των αντικειμένων (object design), δηλαδή κατά το σχεδιασμό του Domain Model αλλά κυρίως του Class Model. Για παράδειγμα, μπορώ να δηλώσω ότι “η κλάση Sale είναι υπεύθυνη για τη δημιουργία της SalesLineltems (πράξη-δράση)”, “ή ότι η Sale είναι υπεύθυνη για τη γνώση του συνολικοί ποσού που πρέπει να χρεωθεί ο Πελάτης” (γνώση). Παρόμοιες ευθύνες σχετικές με “τη γνώση” συχνά Συνάγονται από το Domain Model, λόγω των ιδιοτήτων και των συσχετίσεων που επεξηγεί. Που ψάχνουμε ; Στο Domain Model ή στο Design Model για να αναλύσουμε τις κλάσεις που έχουν τις πληροφορίες που χρειάζονται; - Στο design model, αν υπάρχουν σχετιζόμενες κλάσεις - Συνήθως στο domain model, ιδίως στην αρχή της ανάπτυξης Οι ευθύνες ανατίθενται στις κλάσεις αντικειμένων κατά τη διάρκεια του σχεδιασμού των αντικειμένων (object design), δηλαδή κατά το σχεδιασμό του Domain Model αλλά κυρίως του Class Model. Για παράδειγμα, μπορώ να δηλώσω ότι “η κλάση Sale είναι υπεύθυνη για τη δημιουργία της SalesLineltems (πράξη-δράση)”, “ή ότι η Sale είναι υπεύθυνη για τη γνώση του συνολικοί ποσού που πρέπει να χρεωθεί ο Πελάτης” (γνώση). Παρόμοιες ευθύνες σχετικές με “τη γνώση” συχνά Συνάγονται από το Domain Model, λόγω των ιδιοτήτων και των συσχετίσεων που επεξηγεί.

6 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ6 Στόχοι Αρμοδιότητες και Μέθοδοι - 3 • Μια ευθύνη δεν είναι μία μέθοδος, αλλά πολλές μέθοδοι υλοποιούν μία ευθύνη. • Οι ευθύνες εφαρμόζονται χρησιμοποιώντας τις μεθόδους, οι οποίες είτε ενεργούν μόνες τους είτε συνεργάζονται με άλλες μεθόδους και αντικείμενα. • Για το παράδειγμα, η κλάση Sale μπορεί να καθορίσει μια ή περισσότερες μεθόδους για να μάθει το συνολικό ποσό που πρέπει να χρεωθεί ο πελάτης: Ας υποθέσουμε μια μέθοδο με όνομα getTotal.. Για να εκπληρώσει αυτή την ευθύνη, η κλάση Sale μπορεί να συνεργαστεί με άλλα αντικείμενα, όπως η αποστολή του μηνύματος getSubtotal σε κάθε ένα αντικείμενο SalesLineltem για να ζητήσει το μερικό σύνολο. • Μια ευθύνη δεν είναι μία μέθοδος, αλλά πολλές μέθοδοι υλοποιούν μία ευθύνη. • Οι ευθύνες εφαρμόζονται χρησιμοποιώντας τις μεθόδους, οι οποίες είτε ενεργούν μόνες τους είτε συνεργάζονται με άλλες μεθόδους και αντικείμενα. • Για το παράδειγμα, η κλάση Sale μπορεί να καθορίσει μια ή περισσότερες μεθόδους για να μάθει το συνολικό ποσό που πρέπει να χρεωθεί ο πελάτης: Ας υποθέσουμε μια μέθοδο με όνομα getTotal.. Για να εκπληρώσει αυτή την ευθύνη, η κλάση Sale μπορεί να συνεργαστεί με άλλα αντικείμενα, όπως η αποστολή του μηνύματος getSubtotal σε κάθε ένα αντικείμενο SalesLineltem για να ζητήσει το μερικό σύνολο.

7 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ7 Στόχοι Ευθύνες και διαγράμματα αλληλεπίδρασης • Στα έγγραφα της UML, η ανάθεση των ευθυνών (που υλοποιούνται ως μέθοδοι) γίνεται συνήθως κατά τη διάρκεια της δημιουργίας των διαγραμμάτων αλληλεπίδρασης. • Στα έγγραφα της UML, η ανάθεση των ευθυνών (που υλοποιούνται ως μέθοδοι) γίνεται συνήθως κατά τη διάρκεια της δημιουργίας των διαγραμμάτων αλληλεπίδρασης. Στα αντικείμενα Sale ανατέθηκε η ευθύνη της δημιουργίας αντικειμένων Payments με το μήνυμα makePayment και την υλοποίηση της μεθόδου makePayment. Για την υλοποίηση της ευθύνης απαιτείται περαιτέρω συνεργασία με τα αντικείμενα SalesLineltem.

8 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ8 Στόχοι Κωδικοποιημένα ζεύγη «προβλημάτων / λύσεων», που έχουν προταθεί από έμπειρους δημιουργούς με βάση συγκεκριμένες σχεδιαστικές αρχές. Παράδειγμα Παρουσίασης Προτύπου: Όνομα προτύπου: Φορέας πληροφορίας (Information Expert) Όνομα προτύπου: Φορέας πληροφορίας (Information Expert) Πρόβλημα που επιλύει: Ποια είναι η βασική αρχή με την οποία ορίζουμε Πρόβλημα που επιλύει: Ποια είναι η βασική αρχή με την οποία ορίζουμε ευθύνες στα αντικείμενα; ευθύνες στα αντικείμενα; Λύση: Ανάθεση αρμοδιότητας στην κλάση η οποία έχει την πληροφορία Λύση: Ανάθεση αρμοδιότητας στην κλάση η οποία έχει την πληροφορία για να την εκπληρώσει Κωδικοποιημένα ζεύγη «προβλημάτων / λύσεων», που έχουν προταθεί από έμπειρους δημιουργούς με βάση συγκεκριμένες σχεδιαστικές αρχές. Παράδειγμα Παρουσίασης Προτύπου: Όνομα προτύπου: Φορέας πληροφορίας (Information Expert) Όνομα προτύπου: Φορέας πληροφορίας (Information Expert) Πρόβλημα που επιλύει: Ποια είναι η βασική αρχή με την οποία ορίζουμε Πρόβλημα που επιλύει: Ποια είναι η βασική αρχή με την οποία ορίζουμε ευθύνες στα αντικείμενα; ευθύνες στα αντικείμενα; Λύση: Ανάθεση αρμοδιότητας στην κλάση η οποία έχει την πληροφορία Λύση: Ανάθεση αρμοδιότητας στην κλάση η οποία έχει την πληροφορία για να την εκπληρώσει Σχεδιαστικά Πρότυπα (1/2)

9 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ9 Στόχοι • Η ιδέα ενός προτύπου αναφέρεται σε επαναληπτικές εφαρμογές. • Δεν εκφράζουν νέες ιδέες σχεδίασης, αλλά κωδικοποιούν υπάρχουσες εμπειρίες σχεδιαστικών αρχών. εμπειρίες σχεδιαστικών αρχών. • Όσο συχνότερα και ευρύτερα χρησιμοποιούνται τόσο καλύτερα. • Τα πρότυπα έχουν δηλωτικά ονόματα, για να:  κατανοούμε και να απομνημονεύουμε μια έννοια,  βοηθούν στην επικοινωνία μεταξύ δημιουργών • Εφαρμόζονται κατά την δημιουργία Διαγραμμάτων Αλληλεπίδρασης και Κωδικοποίησης. Κωδικοποίησης. • Η ιδέα ενός προτύπου αναφέρεται σε επαναληπτικές εφαρμογές. • Δεν εκφράζουν νέες ιδέες σχεδίασης, αλλά κωδικοποιούν υπάρχουσες εμπειρίες σχεδιαστικών αρχών. εμπειρίες σχεδιαστικών αρχών. • Όσο συχνότερα και ευρύτερα χρησιμοποιούνται τόσο καλύτερα. • Τα πρότυπα έχουν δηλωτικά ονόματα, για να:  κατανοούμε και να απομνημονεύουμε μια έννοια,  βοηθούν στην επικοινωνία μεταξύ δημιουργών • Εφαρμόζονται κατά την δημιουργία Διαγραμμάτων Αλληλεπίδρασης και Κωδικοποίησης. Κωδικοποίησης. Σχεδιαστικά Πρότυπα (2/2)

10 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ10 Στόχοι Ο Larman εισήγαγε τα πρότυπα GRASP: 1. Φορέας πληροφορίας (Information Expert) 2. Δημιουργός (Creator) 3. Υψηλή Συνοχή (High Cohesion) 4. Μειωμένη Σύζευξη (Low Coupling) 5. Ελεγκτής (Controller) 6. Πολυμορφισμού 7. Indirection 8. Pure Fabrication 9. Protected Variations Ο Larman εισήγαγε τα πρότυπα GRASP: 1. Φορέας πληροφορίας (Information Expert) 2. Δημιουργός (Creator) 3. Υψηλή Συνοχή (High Cohesion) 4. Μειωμένη Σύζευξη (Low Coupling) 5. Ελεγκτής (Controller) 6. Πολυμορφισμού 7. Indirection 8. Pure Fabrication 9. Protected Variations GRASP Πρότυπα Σχεδίασης

11 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ11 Στόχοι Πρόβλημα: Ποια είναι η γενική αρχή ανάθεσης ευθυνών στα αντικείμενα; Λύση: Ανάθεση αρμοδιότητας στον φορέα της πληροφορίας, δηλαδή την κλάση η οποία έχει την πληροφορία για να εκπληρώσει την αρμοδιότητα. • Συμβάλει στην ευκολία κατανόησης, συντήρησης, επέκτασης, και επαναχρησιμοποίησης • Παράδειγμα Sale: Που θα δημιουργηθεί το ‘Γενικό σύνολο’ ; Πρόβλημα: Ποια είναι η γενική αρχή ανάθεσης ευθυνών στα αντικείμενα; Λύση: Ανάθεση αρμοδιότητας στον φορέα της πληροφορίας, δηλαδή την κλάση η οποία έχει την πληροφορία για να εκπληρώσει την αρμοδιότητα. • Συμβάλει στην ευκολία κατανόησης, συντήρησης, επέκτασης, και επαναχρησιμοποίησης • Παράδειγμα Sale: Που θα δημιουργηθεί το ‘Γενικό σύνολο’ ; Φορέας Πληροφορίας – (1/5) (Information Expert)

12 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ12 Στόχοι Ποιες πληροφορίες απαιτούνται για τον καθορίσουν του τελικού ποσού; Στο Design Model, η κλάση Sale θα είναι ο φορέας της πληροφορίας: Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ12 Φορέας Πληροφορίας – (2/5) (Information Expert)

13 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ13 Στόχοι Η ευθύνη της γνώσης και πράξης της συνολικής πώλησης εκχωρούνται σε τρεις κλάσεις σχεδίασης αντικειμένων: Η ευθύνη της γνώσης και πράξης της συνολικής πώλησης εκχωρούνται σε τρεις κλάσεις σχεδίασης αντικειμένων: Κλάσεις λογισμικού ΕυθύνηSaleΞέρει το συνολικό ποσό SalesLineltemΞέρει το υποσύνολο για κάθε γραμμή στην απόδειξη/τιμολόγιο ProductSpecificationΞέρει την τιμή του προϊόντος Το τμήμα απεικόνισης των μεθόδου ενός διαγράμματος κλάσης μπορεί να συνοψίσει τις μεθόδους, ενώ ένα διαγρ. αλληλεπίδρασης την συνεργασία των μηνυμάτων. Φορέας Πληροφορίας – (3/5) (Information Expert)

14 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ14 Στόχοι Φορέας Πληροφορίας – (4/5) (Information Expert)

15 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ15 Στόχοι • Ο φορέας πληροφορίας (ανάθεση ευθυνών) είναι μια βασική κατευθυντήρια • αρχή στη σχεδίαση αντικειμένων. • Συχνά η εκπλήρωση μιας ευθύνης συχνά απαιτεί πληροφορίες που είναι διασκορπισμένες σε αντικείμενα διαφορετικών κλάσεων. Σε αυτές τις περιπτώσεις τα διαφορετικά αντικείμενα θα πρέπει να αλληλεπιδράσουν μέσω των μηνυμάτων για να μοιραστούν την εργασία. Πλεονεκτήματα:  Τηρείται η αρχή της ενθυλάκωσης πληροφοριών  Η συμπεριφορά κατανέμεται σε διάφορες κλάσεις υποστηρίζοντας τη συνοχή και σύζευξη • Ο φορέας πληροφορίας (ανάθεση ευθυνών) είναι μια βασική κατευθυντήρια • αρχή στη σχεδίαση αντικειμένων. • Συχνά η εκπλήρωση μιας ευθύνης συχνά απαιτεί πληροφορίες που είναι διασκορπισμένες σε αντικείμενα διαφορετικών κλάσεων. Σε αυτές τις περιπτώσεις τα διαφορετικά αντικείμενα θα πρέπει να αλληλεπιδράσουν μέσω των μηνυμάτων για να μοιραστούν την εργασία. Πλεονεκτήματα:  Τηρείται η αρχή της ενθυλάκωσης πληροφοριών  Η συμπεριφορά κατανέμεται σε διάφορες κλάσεις υποστηρίζοντας τη συνοχή και σύζευξη Φορέας Πληροφορίας – (5/5) (Information Expert)

16 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ16 Στόχοι Πρόβλημα: ποιος είναι αρμόδιος για την δημιουργία νέου στιγμιότυπου (αντικειμένου) κλάσης; Λύση: Ανάθεση στην κλάση Β την αρμοδιότητα να δημιουργήσει ένα στιγμιότυπο της κλάσης Α, εάν συντρέχει ένας από τους κάτωθι λόγους: 1. η Β συνθέτει (αθροίζει) αντικείμενα της Α 2. η Β περιλαμβάνει (συσσωματώνει) αντικείμενα της Α 3. η Β καταγράφει στιγμιότυπα αντικειμένων της Α 4. η Β χρησιμοποιεί αντικείμενα της Α 5. η Β έχει τα δεδομένα αρχικοποίησης αντικειμένων της Α (η Β είναι φορέας 6. Πληροφοριών) Τότε λέμε ότι η Β είναι δημιουργός των αντικειμένων Α Εάν ισχύουν περισσότερες από μια επιλογές, τότε προτιμήστε τις επιλ. 1 ή 2. Ποιος πρέπει να είναι αρμόδιος για τη δημιουργία της SalesLineItem; Πρόβλημα: ποιος είναι αρμόδιος για την δημιουργία νέου στιγμιότυπου (αντικειμένου) κλάσης; Λύση: Ανάθεση στην κλάση Β την αρμοδιότητα να δημιουργήσει ένα στιγμιότυπο της κλάσης Α, εάν συντρέχει ένας από τους κάτωθι λόγους: 1. η Β συνθέτει (αθροίζει) αντικείμενα της Α 2. η Β περιλαμβάνει (συσσωματώνει) αντικείμενα της Α 3. η Β καταγράφει στιγμιότυπα αντικειμένων της Α 4. η Β χρησιμοποιεί αντικείμενα της Α 5. η Β έχει τα δεδομένα αρχικοποίησης αντικειμένων της Α (η Β είναι φορέας 6. Πληροφοριών) Τότε λέμε ότι η Β είναι δημιουργός των αντικειμένων Α Εάν ισχύουν περισσότερες από μια επιλογές, τότε προτιμήστε τις επιλ. 1 ή 2. Ποιος πρέπει να είναι αρμόδιος για τη δημιουργία της SalesLineItem; Δημιουργός (Creator) – 1/4

17 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ17 Στόχοι Από το Domain Model, η κλάση Sale περιέχει (αθροίζει) πολλά αντικείμενα SalesLineltem, άρα μπορεί να είναι Δημιουργός. Δημιουργός (Creator) – 2/4

18 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ18 Στόχοι Ο σχεδιασμός των αλληλεπιδράσεων των αντικειμένων: Δημιουργός (Creator) – 3/4

19 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ19 Στόχοι • Κλάσεις που καταγράφουν ή περιέχουν άλλες κλάσεις είναι καλές υποψήφιες για την ανάθεση της ευθύνης της δημιουργίας των αντικειμένων. • Η κλάση δημιουργός περιέχει συνήθως τα δεδομένα αρχικοποίησης των αντικειμένων (Φορέας Πληροφορίας). Η αρχικοποίηση των δεδομένων γίνεται μέσω κάποιων μεθόδων αρχικοποίησης (π.χ παραμετρικός γίνεται μέσω κάποιων μεθόδων αρχικοποίησης (π.χ παραμετρικός δομητής). δομητής). • Αντενδείξεις: Συχνά λόγω πολυπλοκότητας στη δημιουργία των αντικειμένων, ανατίθεται η δημιουργία σε μια βοηθητική κλάση αποκαλούμενη Factory παρά στην Δημιουργό που είναι υποψήφια από τις υπάρχουσες κλάσεις. • Οφέλη: Υποστηρίζεται η χαμηλή σύζευξη (περιγράφεται στη συνέχεια). Καλύτερες προοπτικές Επαναχρησιμοποίησης. • Κλάσεις που καταγράφουν ή περιέχουν άλλες κλάσεις είναι καλές υποψήφιες για την ανάθεση της ευθύνης της δημιουργίας των αντικειμένων. • Η κλάση δημιουργός περιέχει συνήθως τα δεδομένα αρχικοποίησης των αντικειμένων (Φορέας Πληροφορίας). Η αρχικοποίηση των δεδομένων γίνεται μέσω κάποιων μεθόδων αρχικοποίησης (π.χ παραμετρικός γίνεται μέσω κάποιων μεθόδων αρχικοποίησης (π.χ παραμετρικός δομητής). δομητής). • Αντενδείξεις: Συχνά λόγω πολυπλοκότητας στη δημιουργία των αντικειμένων, ανατίθεται η δημιουργία σε μια βοηθητική κλάση αποκαλούμενη Factory παρά στην Δημιουργό που είναι υποψήφια από τις υπάρχουσες κλάσεις. • Οφέλη: Υποστηρίζεται η χαμηλή σύζευξη (περιγράφεται στη συνέχεια). Καλύτερες προοπτικές Επαναχρησιμοποίησης. Δημιουργός (Creator) – 4/4

20 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ20 Στόχοι • Πρόβλημα: Πώς μπορεί να υποστηριχθεί η χαμηλή εξάρτηση, να κρατηθεί χαμηλό αντίκτυπο ανταλλαγής μηνυμάτων, και να αυξηθεί η επαναχρησιμοποίηση του κώδικα; επαναχρησιμοποίηση του κώδικα; • Λύση: Αναθέτει μια ευθύνη έτσι ώστε η σύζευξη να παραμένει χαμηλή. • Σύζευξη: μέτρο του βαθμού διασύνδεσης, γνώσης ή εξάρτησης με άλλα αντικείμενα αντικείμενα Προβλήματα αυξημένου βαθμού σύζευξης (στήριξη σε πολλές κλάσεις): • Αλλαγές σε σχετιζόμενες κλάσεις επιφέρουν τοπικές αλλαγές • Είναι πιο δύσκολη η κατανόηση μιας μεμονωμένης κλάσης • Είναι πιο δύσκολη η επαναχρησιμοποίηση (εξαρτάται και από άλλες κλάσεις). • Πρόβλημα: Πώς μπορεί να υποστηριχθεί η χαμηλή εξάρτηση, να κρατηθεί χαμηλό αντίκτυπο ανταλλαγής μηνυμάτων, και να αυξηθεί η επαναχρησιμοποίηση του κώδικα; επαναχρησιμοποίηση του κώδικα; • Λύση: Αναθέτει μια ευθύνη έτσι ώστε η σύζευξη να παραμένει χαμηλή. • Σύζευξη: μέτρο του βαθμού διασύνδεσης, γνώσης ή εξάρτησης με άλλα αντικείμενα αντικείμενα Προβλήματα αυξημένου βαθμού σύζευξης (στήριξη σε πολλές κλάσεις): • Αλλαγές σε σχετιζόμενες κλάσεις επιφέρουν τοπικές αλλαγές • Είναι πιο δύσκολη η κατανόηση μιας μεμονωμένης κλάσης • Είναι πιο δύσκολη η επαναχρησιμοποίηση (εξαρτάται και από άλλες κλάσεις). Χαμηλή Σύζευξη (Low Coupling) – 1/4

21 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ21 Στόχοι Πρόβλημα: Μεταξύ 3 εννοιολογικών κλάσεων (Payment, Sale, Register), ποια κλάση θα διασύνδεει το στιγμιότυπο της Payment με τη Sale; Λύση: Η Register "καταγράφει" μια Payment στην πραγματική περιοχή, άρα ο δημιουργός προτύπου προτείνει την Register ως υποψήφια για τη δημιουργία της Payment. Το αντικείμενο της κλάσης Register θα μπορούσε δημιουργία της Payment. Το αντικείμενο της κλάσης Register θα μπορούσε έπειτα να στείλει ένα μήνυμα add Payment στην Sale, περνώντας τη νέα Payment ως παράμετρο (αντικείμενο - p). Πρόβλημα: Μεταξύ 3 εννοιολογικών κλάσεων (Payment, Sale, Register), ποια κλάση θα διασύνδεει το στιγμιότυπο της Payment με τη Sale; Λύση: Η Register "καταγράφει" μια Payment στην πραγματική περιοχή, άρα ο δημιουργός προτύπου προτείνει την Register ως υποψήφια για τη δημιουργία της Payment. Το αντικείμενο της κλάσης Register θα μπορούσε δημιουργία της Payment. Το αντικείμενο της κλάσης Register θα μπορούσε έπειτα να στείλει ένα μήνυμα add Payment στην Sale, περνώντας τη νέα Payment ως παράμετρο (αντικείμενο - p). Χαμηλή Σύζευξη (Low Coupling) – 2/4

22 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ22 Στόχοι Μια εναλλακτική λύση στη δημιουργία της Payment και την ένωση της με την Sale παρουσιάζεται στο παρακάτω σχήμα. Ποιος σχεδιασμός, βασισμένος στην ανάθεση των ευθυνών, υποστηρίζει τη χαμηλότερη σύζευξη; Στο σχέδιο 1 (Register-δημιουργός της Payment), η Register προσθέτει σύζευξη στην Payment, ενώ στο 2 (Sale-δημιουργός), δεν αυξάνεται η σύζευξη Μια εναλλακτική λύση στη δημιουργία της Payment και την ένωση της με την Sale παρουσιάζεται στο παρακάτω σχήμα. Ποιος σχεδιασμός, βασισμένος στην ανάθεση των ευθυνών, υποστηρίζει τη χαμηλότερη σύζευξη; Στο σχέδιο 1 (Register-δημιουργός της Payment), η Register προσθέτει σύζευξη στην Payment, ενώ στο 2 (Sale-δημιουργός), δεν αυξάνεται η σύζευξη Χαμηλή Σύζευξη (Low Coupling) – 3/4

23 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ23 Στόχοι • Καθαρά από την άποψη του προτύπου Χαμηλή Σύζευξη, το σχέδιο 2 είναι προτιμότερο. προτιμότερο. Στην πραγματικότητα ο βαθμός της σύζευξης δεν μπορεί να σχεδιαστεί Στην πραγματικότητα ο βαθμός της σύζευξης δεν μπορεί να σχεδιαστεί Και υλοποιηθεί αυτόνομα και ανεξάρτητα από τα αλλά πρότυπα όπως ο Και υλοποιηθεί αυτόνομα και ανεξάρτητα από τα αλλά πρότυπα όπως ο Φορέας Πληροφορίας και η Υψηλή Συνοχή. Σε κάθε περίπτωση είναι ένας Φορέας Πληροφορίας και η Υψηλή Συνοχή. Σε κάθε περίπτωση είναι ένας παράγοντας που πρέπει να λαμβάνεται υποψιών για την βελτίωση της παράγοντας που πρέπει να λαμβάνεται υποψιών για την βελτίωση της σχεδίασης λογισμικού. σχεδίασης λογισμικού. • Καθαρά από την άποψη του προτύπου Χαμηλή Σύζευξη, το σχέδιο 2 είναι προτιμότερο. προτιμότερο. Στην πραγματικότητα ο βαθμός της σύζευξης δεν μπορεί να σχεδιαστεί Στην πραγματικότητα ο βαθμός της σύζευξης δεν μπορεί να σχεδιαστεί Και υλοποιηθεί αυτόνομα και ανεξάρτητα από τα αλλά πρότυπα όπως ο Και υλοποιηθεί αυτόνομα και ανεξάρτητα από τα αλλά πρότυπα όπως ο Φορέας Πληροφορίας και η Υψηλή Συνοχή. Σε κάθε περίπτωση είναι ένας Φορέας Πληροφορίας και η Υψηλή Συνοχή. Σε κάθε περίπτωση είναι ένας παράγοντας που πρέπει να λαμβάνεται υποψιών για την βελτίωση της παράγοντας που πρέπει να λαμβάνεται υποψιών για την βελτίωση της σχεδίασης λογισμικού. σχεδίασης λογισμικού.  Στην πραγματικότητα δεν υπάρχει απόλυτο μέτρο για το πότε η σύζευξη είναι πολύ μεγάλη. σύζευξη είναι πολύ μεγάλη.Οφέλη:  Δεν επηρεάζεται από αλλαγές σε άλλα μέλη  Εύκολη η κατανόηση μεμονωμένα  Ευκολία επαναχρησιμοποίησης Χαμηλή Σύζευξη (Low Coupling) – 4/4

24 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ24 Στόχοι Πρόβλημα: Πως να διατηρηθεί η πολυπλοκότητα υπό έλεγχο; Λύση: Ανάθεση μιας αρμοδιότητας ούτως ώστε η συνοχή να παραμένει μεγάλη • Συνοχή: μέτρο του βαθμού σχέσης και «συγγένειας», των αρμοδιοτήτων σε μια κλάση. Υψηλή Συνοχή: Συγκεκριμένες ευθύνες χωρίς μεγάλο φόρτο εργασίας. Μια κλάση με χαμηλή συνοχή παρουσιάζει τα παρακάτω προβλήματα:  Δυσκολία κατανόησης, επαναχρησιμοποίησης, συντήρησης  «συστέγαση» πολλών άσχετων μεταξύ τους αρμοδιοτήτων  Είναι ευαίσθητες και επηρεάζονται πολύ εύκολα από αλλαγές στην σχεδίαση ή τον κώδικα. Πρόβλημα: Πως να διατηρηθεί η πολυπλοκότητα υπό έλεγχο; Λύση: Ανάθεση μιας αρμοδιότητας ούτως ώστε η συνοχή να παραμένει μεγάλη • Συνοχή: μέτρο του βαθμού σχέσης και «συγγένειας», των αρμοδιοτήτων σε μια κλάση. Υψηλή Συνοχή: Συγκεκριμένες ευθύνες χωρίς μεγάλο φόρτο εργασίας. Μια κλάση με χαμηλή συνοχή παρουσιάζει τα παρακάτω προβλήματα:  Δυσκολία κατανόησης, επαναχρησιμοποίησης, συντήρησης  «συστέγαση» πολλών άσχετων μεταξύ τους αρμοδιοτήτων  Είναι ευαίσθητες και επηρεάζονται πολύ εύκολα από αλλαγές στην σχεδίαση ή τον κώδικα. Υψηλή Συνοχή (High Cohesion – 1/4

25 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ25 Στόχοι Παράδειγμα: Το πρόβλημα της χαμηλής Σύζευξης (προηγ.): Υψηλή Συνοχή (High Cohesion – 2/4 Η Register παίρνει μέρος στην ευθύνη για τη λειτουργία του συστήματος makePayment. Αποδεκτό, αλλά τι θα γίνει αν έχει και άλλες ευθύνες;

26 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ26 Στόχοι Επιθυμητός ο δεύτερος σχεδιασμός που αναθέτει την ευθύνη στην Sale, κάτι το οποίο υποστηρίζει υψηλότερη συνοχή (και χαμηλή σύζευξη). Επιθυμητός ο δεύτερος σχεδιασμός που αναθέτει την ευθύνη στην Sale, κάτι το οποίο υποστηρίζει υψηλότερη συνοχή (και χαμηλή σύζευξη). Υψηλή Συνοχή (High Cohesion – 3/4 Στην πραγματικότητα ο βαθμός της συνοχής δεν μπορεί να σχεδιαστεί και υλοποιηθεί αυτόνομα και ανεξάρτητα από τα αλλά πρότυπα όπως ο Φορέας Πληροφορίας και η Χαμηλή Σύζευξη.

27 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ27 Στόχοι Σενάρια που επεξηγούν τους ποικίλους βαθμούς λειτουργικής συνοχής: Πολύ χαμηλή συνοχή. Μια κλάση είναι αποκλειστικά αρμόδια για πολλά πράγματα σε πολύ διαφορετικές λειτουργικές περιοχές. Χαμηλή Συνοχή. Μια κλάση έχει απόλυτη ευθύνη για έναν σύνθετο στόχο σε μια λειτουργική περιοχή. Υψηλή συνοχή. Μια κλάση έχει μέτριες αρμοδιότητες για μια λειτουργική περιοχή και συνεργάζεται με άλλες κλάσεις για να εκπληρώσει τους περιοχή και συνεργάζεται με άλλες κλάσεις για να εκπληρώσει τους στόχους της. Μέτρια συνοχή. Μια κλάση έχει ελαφριές και αποκλειστικές αρμοδιότητες σε λίγες αλλά διαφορετικές περιοχές που συσχετίζονται λογικά με την κλάση, αλλά όχι μεταξύ τους. Σενάρια που επεξηγούν τους ποικίλους βαθμούς λειτουργικής συνοχής: Πολύ χαμηλή συνοχή. Μια κλάση είναι αποκλειστικά αρμόδια για πολλά πράγματα σε πολύ διαφορετικές λειτουργικές περιοχές. Χαμηλή Συνοχή. Μια κλάση έχει απόλυτη ευθύνη για έναν σύνθετο στόχο σε μια λειτουργική περιοχή. Υψηλή συνοχή. Μια κλάση έχει μέτριες αρμοδιότητες για μια λειτουργική περιοχή και συνεργάζεται με άλλες κλάσεις για να εκπληρώσει τους περιοχή και συνεργάζεται με άλλες κλάσεις για να εκπληρώσει τους στόχους της. Μέτρια συνοχή. Μια κλάση έχει ελαφριές και αποκλειστικές αρμοδιότητες σε λίγες αλλά διαφορετικές περιοχές που συσχετίζονται λογικά με την κλάση, αλλά όχι μεταξύ τους. Υψηλή Συνοχή (High Cohesion – 4/4

28 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ28 Στόχοι Πρόβλημα: Ποιος είναι αρμόδιος για την διαχείριση ενός γεγονότος εισαγωγής στο σύστημα (από εξωτ. χρήστη); Λύση: Ανάθεση της αρμοδιότητας αποδοχής ή διαχείρισης, μηνύματος γεγονότος συστήματος, σε κλάση που αντιπροσωπεύει μια από τις εξής επιλογές (πρόσοψη):  Ολόκληρο σύστημα, συσκευή, υποσύστημα  Ένα σενάριο ΠΧ, μέσα στο οποίο συμβαίνει το γεγονός συστήματος Ελεγκτής: ένα αντικείμενο υπεύθυνο για να δεχτεί ή να διαχειριστεί ένα γεγονότος συστήματος. Πρόβλημα: Ποιος είναι αρμόδιος για την διαχείριση ενός γεγονότος εισαγωγής στο σύστημα (από εξωτ. χρήστη); Λύση: Ανάθεση της αρμοδιότητας αποδοχής ή διαχείρισης, μηνύματος γεγονότος συστήματος, σε κλάση που αντιπροσωπεύει μια από τις εξής επιλογές (πρόσοψη):  Ολόκληρο σύστημα, συσκευή, υποσύστημα  Ένα σενάριο ΠΧ, μέσα στο οποίο συμβαίνει το γεγονός συστήματος Ελεγκτής: ένα αντικείμενο υπεύθυνο για να δεχτεί ή να διαχειριστεί ένα γεγονότος συστήματος. Ελεγκτής (Controller) – 1/6

29 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ29 Στόχοι • Συνιστάται να χρησιμοποιείται ένας Ελεγκτής για κάθε Περίπτωση Χρήσης. • Ουσιαστικά ο Ελεγκτής δέχεται την αίτηση από το επίπεδο UI, συντονίζει και ελέγχει την δραστηριότητα, παραπέμποντας τη υλοποίηση σε άλλα αντικείμενα. • Είναι από την πλευρά του client. • Συνιστάται να χρησιμοποιείται ένας Ελεγκτής για κάθε Περίπτωση Χρήσης. • Ουσιαστικά ο Ελεγκτής δέχεται την αίτηση από το επίπεδο UI, συντονίζει και ελέγχει την δραστηριότητα, παραπέμποντας τη υλοποίηση σε άλλα αντικείμενα. • Είναι από την πλευρά του client. Ελεγκτής (Controller) – 2/6

30 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ30 Στόχοι Ελεγκτής (Controller) – 3/6

31 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ31 Στόχοι Σύμφωνα με το πρότυπο Ελεγκτής δύο λύσεις προτείνονται: - Register (system device) - ProcessSaleHandler (χειριστής συμβάντων του συστήματος μιας ΠΧ) Σύμφωνα με το πρότυπο Ελεγκτής δύο λύσεις προτείνονται: - Register (system device) - ProcessSaleHandler (χειριστής συμβάντων του συστήματος μιας ΠΧ) Ελεγκτής (Controller) – 4/6

32 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ32 Στόχοι Ελεγκτής (Controller) – 5/6

33 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ33 Στόχοι Ελεγκτής (Controller) – 6/6 Πλεονεκτήματα: • Αυξάνει την δυνατότητα επαναχρησιμοποίησης • Προσαρμόσιμη διεπιφάνεια • Ελέγχει τη σειρά εκτέλεσης λειτουργιών μιας Περίπτωσης Χρήσης • Η endSale() εκτελείται μετά την Payment() Πλεονεκτήματα: • Αυξάνει την δυνατότητα επαναχρησιμοποίησης • Προσαρμόσιμη διεπιφάνεια • Ελέγχει τη σειρά εκτέλεσης λειτουργιών μιας Περίπτωσης Χρήσης • Η endSale() εκτελείται μετά την Payment()

34 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ34 Στόχοι Πρότυπο Πολυμορφισμού (1/4) • Πρόβλημα: Πως να χειριστείς εναλλακτικές λύσεις βάσει τύπου; Πως να δημιουργήσεις προσαρμόσιμες μονάδες λογισμικού; • Λύση: Όταν σχετικές εναλλακτικές λύσεις ή συμπεριφορές ποικίλουν σε τύπο (κλάση) • Παράδειγμα: Διαφορετικοί εξωτ. υπολογιστές φόρου, με διαφορετική διασύνδεση και πρωτόκολλο (TCP socket, SOAP, Java RMI) διασύνδεση και πρωτόκολλο (TCP socket, SOAP, Java RMI) • Οι «προσαρμοστές» είναι εσωτ. αντικείμενα που αντιπροσωπεύουν εξωτ. υπολογιστές φόρου • Πρόβλημα: Πως να χειριστείς εναλλακτικές λύσεις βάσει τύπου; Πως να δημιουργήσεις προσαρμόσιμες μονάδες λογισμικού; • Λύση: Όταν σχετικές εναλλακτικές λύσεις ή συμπεριφορές ποικίλουν σε τύπο (κλάση) • Παράδειγμα: Διαφορετικοί εξωτ. υπολογιστές φόρου, με διαφορετική διασύνδεση και πρωτόκολλο (TCP socket, SOAP, Java RMI) διασύνδεση και πρωτόκολλο (TCP socket, SOAP, Java RMI) • Οι «προσαρμοστές» είναι εσωτ. αντικείμενα που αντιπροσωπεύουν εξωτ. υπολογιστές φόρου

35 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ35 Στόχοι Πρότυπο Πολυμορφισμού (2/4)

36 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ36 Στόχοι Πρότυπο Πολυμορφισμού (3/4)

37 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ37 Στόχοι Πρότυπο Πολυμορφισμού (4/4) Πολυμορφισμός είναι μια θεμελιώδης αρχή σχεδίασης και οργάνωσης ενός συστήματος για τον χειρισμό παρόμοιων (συναφών) παραλλαγών Οφέλη  Εύκολη προσθήκη νέων επεκτάσεων για νέες παραλλαγές  Εισαγωγή νέων υλοποιήσεων δίχως να επηρεάζονται οι εξυπηρετητές Πολυμορφισμός είναι μια θεμελιώδης αρχή σχεδίασης και οργάνωσης ενός συστήματος για τον χειρισμό παρόμοιων (συναφών) παραλλαγών Οφέλη  Εύκολη προσθήκη νέων επεκτάσεων για νέες παραλλαγές  Εισαγωγή νέων υλοποιήσεων δίχως να επηρεάζονται οι εξυπηρετητές

38 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ38 Στόχοι Τεχνητή Επινόηση (Pure Fabrication) (1/3) Πρόβλημα: Σε ποιο αντικείμενο αναθέτουμε μία αρμοδιότητα χωρίς να παραβιαστούν οι κανόνες Συνοχής – Σύζευξης, αλλά η λύση του Φορέα Πληροφορίας δεν είναι η καταλληλότερη; Λύση: Όρισε ένα σύνολο αρμοδιοτήτων υψηλής συνοχής σε μια τεχνητή κλάση η οποία δεν αντιπροσωπεύει κάτι στο Domain Model. κλάση η οποία δεν αντιπροσωπεύει κάτι στο Domain Model. Παράδειγμα: Η καταχώρηση στιγμιότυπων Sale σε ΒΔ. Πρόβλημα: Σε ποιο αντικείμενο αναθέτουμε μία αρμοδιότητα χωρίς να παραβιαστούν οι κανόνες Συνοχής – Σύζευξης, αλλά η λύση του Φορέα Πληροφορίας δεν είναι η καταλληλότερη; Λύση: Όρισε ένα σύνολο αρμοδιοτήτων υψηλής συνοχής σε μια τεχνητή κλάση η οποία δεν αντιπροσωπεύει κάτι στο Domain Model. κλάση η οποία δεν αντιπροσωπεύει κάτι στο Domain Model. Παράδειγμα: Η καταχώρηση στιγμιότυπων Sale σε ΒΔ.

39 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ39 Στόχοι Τεχνητή Επινόηση (Pure Fabrication) (2/3) Προβλήματα που επιλύει:  Η Sale παραμένει καλοσχεδιασμένη  Η PersistentStorage κλάση είναι συνεκτική  Η PersistentStorage κλάση είναι πολύ γενική και επαναχρησιμοποιήσιμη Προβλήματα που επιλύει:  Η Sale παραμένει καλοσχεδιασμένη  Η PersistentStorage κλάση είναι συνεκτική  Η PersistentStorage κλάση είναι πολύ γενική και επαναχρησιμοποιήσιμη

40 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ40 Στόχοι Τεχνητή Επινόηση (Pure Fabrication) (3/3) Η σχεδίαση αντικειμένων περιλαμβάνει 2 ομάδες:  Αντιπροσωπευτική ταξινόμηση (representational decomposition – πχ. ‘Sale’)  Μειώνει το αντιπροσωπευτικό χάσμα  Ταξινόμηση συμπεριφοράς (behavioral decomposition, πχ. ‘TableOfContentsGenerator’)  Ομαδοποίηση γενικών αρμοδιοτήτων Οφέλη • Υψηλή συνοχή, λόγω ομαδοποίησης σχετικών μεταξύ τους γενικών αρμοδιοτήτων • Δυνατότητα αύξησης επαναχρησιμοποίησης Η σχεδίαση αντικειμένων περιλαμβάνει 2 ομάδες:  Αντιπροσωπευτική ταξινόμηση (representational decomposition – πχ. ‘Sale’)  Μειώνει το αντιπροσωπευτικό χάσμα  Ταξινόμηση συμπεριφοράς (behavioral decomposition, πχ. ‘TableOfContentsGenerator’)  Ομαδοποίηση γενικών αρμοδιοτήτων Οφέλη • Υψηλή συνοχή, λόγω ομαδοποίησης σχετικών μεταξύ τους γενικών αρμοδιοτήτων • Δυνατότητα αύξησης επαναχρησιμοποίησης

41 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ41 Στόχοι Indirection (1/3) Πρόβλημα: Αποσύνδεση μεταξύ αντικειμένων με στόχο την μειωμένη σύζευξη και αύξηση της δυνατότητας επαναχρησιμοποίησης. σύζευξη και αύξηση της δυνατότητας επαναχρησιμοποίησης. Λύση: Ανάθεσε την αρμοδιότητα σε ενδιάμεσο αντικείμενο το οποίο μεσολαβεί μεταξύ άλλων μονάδων ή υπηρεσιών, ώστε να μεσολαβεί μεταξύ άλλων μονάδων ή υπηρεσιών, ώστε να αποφεύγεται η άμεση σύνδεση τους. Παραδείγματα TaxCalculatorAdapter Indirection + Πολυμορφισμός => προστασία της εσωτ. Σχεδίασης από διαφορετικές εξωτ. διασυνδέσεις από διαφορετικές εξωτ. διασυνδέσεις Πρόβλημα: Αποσύνδεση μεταξύ αντικειμένων με στόχο την μειωμένη σύζευξη και αύξηση της δυνατότητας επαναχρησιμοποίησης. σύζευξη και αύξηση της δυνατότητας επαναχρησιμοποίησης. Λύση: Ανάθεσε την αρμοδιότητα σε ενδιάμεσο αντικείμενο το οποίο μεσολαβεί μεταξύ άλλων μονάδων ή υπηρεσιών, ώστε να μεσολαβεί μεταξύ άλλων μονάδων ή υπηρεσιών, ώστε να αποφεύγεται η άμεση σύνδεση τους. Παραδείγματα TaxCalculatorAdapter Indirection + Πολυμορφισμός => προστασία της εσωτ. Σχεδίασης από διαφορετικές εξωτ. διασυνδέσεις από διαφορετικές εξωτ. διασυνδέσεις

42 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ42 Στόχοι Indirection (2/3) PersistentStorage υποστηρίζει την indirection ανάμεσα στην Sale και την ΒΔ. Οφέλη  Χαμηλή Σύζευξη (σύνδεση) μεταξύ αντικειμένων PersistentStorage υποστηρίζει την indirection ανάμεσα στην Sale και την ΒΔ. Οφέλη  Χαμηλή Σύζευξη (σύνδεση) μεταξύ αντικειμένων

43 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ43 Στόχοι Indirection (3/3)

44 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ44 Στόχοι Protected Variations (1/3) Πρόβλημα: Σχεδίαση αντικειμένων, υποσυστημάτων ή συστημάτων, ώστε οι αλλαγές σ’ αυτά να μην επιφέρουν επιπτώσεις σε άλλα μέρη. Λύση: Εντοπισμός προβλεπόμενων ασταθών σημείων. Δημιουργία σταθερής διασύνδεσης γύρω από αυτά. Παράδειγμα: Τα σημεία αστάθειας και αλλαγών στις διασυνδέσεις των υπολογ. Φόρων. Τα εσωτ. αντικείμενα συνεργάζονται πλέον με μια σταθερή διασύνδεση.

45 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ45 Στόχοι Protected Variations (2/3) Μηχανισμοί υποστήριξης PVs Core Protected Variations Mechanisms: Η ενθυλάκωση, οι διασυνδέσεις, ο πολυμορφισμός και η Indirection. (πχ. Broker, Virtual machines) The Liskov Substitution Principle: Αν για κάθε αντικείμενο α1 του τύπου S υπάρχει αντικείμενο α2 του τύπου Τ ώστε όλα τα προγράμματα P που αναφέρονται στο Τ, η συμπεριφορά του Ρ δεν αλλάζει όταν το α1 αντικαθίσταται από το α2, τότε το S είναι υπό-τύπος του Τ.

46 Παναγιώτης Σφέτσος, Μεθοδολογίες Προγραμματισμού ΙΙ46 Στόχοι Protected Variations (3/3) Σχεδίαση Απόκρυψης Δομής (Law of Demeter) Θεωρεί ότι μέσα σε μια μέθοδο τα μηνύματα θα αποστέλλονται μόνο στα ακόλουθα αντικείμενα:  Στο this  Σε παράμετρο της μεθόδου  Σε χαρακτηριστικό του this  Σε μέλος συλλογής (πχ. πίνακα) ο οποίος είναι χαρακτηριστικό του this  Σε αντικείμενο που δημιουργείται στην μέθοδο


Κατέβασμα ppt "Μεθοδολογίες Προγραμματισμού ΙΙ ΣΧΕΔΙΑΣΗ ΑΝΤΙΚΕΙΜΕΝΩΝ ΜΕ ΑΡΜΟΔΙΟΤΗΤΕΣ GRASP - Πρότυπα Παναγιώτης Σφέτσος, PhD"

Παρόμοιες παρουσιάσεις


Διαφημίσεις Google