Μεθοδολογίες Προγραμματισμού ΙΙ ΣΧΕΔΙΑΣΗ ΑΝΤΙΚΕΙΜΕΝΩΝ ΜΕ ΑΡΜΟΔΙΟΤΗΤΕΣ ΣΧΕΔΙΑΣΗ ΑΝΤΙΚΕΙΜΕΝΩΝ ΜΕ ΑΡΜΟΔΙΟΤΗΤΕΣ GRASP - Πρότυπα Παναγιώτης Σφέτσος, PhD http://aetos.it.teithe.gr/~sfetsos/ sfetsos@it.teithe.gr Παναγιώτης Σφέτσος Μεθοδολογίες Προγραμματισμού ΙΙ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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