16 ΑΝΤΙΚΕΙΜΕΝΟΣΤΡΕΦΗΣ ΣΧΕ ΙΑΣΗ

ΕΙΣΑΓΩΓΗ Ο αντικειµενοστρεφής προγραµµατισµός (object-oriented programming) έχει αναχθεί την τελευταία δεκαετία σε εξαιρετικά δηµοφιλή τεχνολογία ανάπτυξης λογισµικού. Το γεγονός αυτό αποδεικνύεται από πολλαπλά στοιχεία: Οι κατασκευαστές λογισµικού σπεύδουν να αναπτύξουν αντικειµενοστρεφείς εκδόσεις των προϊόντων τους τα ακαδηµαϊκά ιδρύµατα έχουν εντάξει πλήρως µαθήµατα αντικειµενοστρεφούς ανάλυσης και σχεδίασης στα προγράµµατά σπουδών τους αµέτρητα βιβλία και επιστηµονικά άρθρα γράφονται για το θέµα αυτό ετησίως οι επαγγελµατίες της πληροφορικής προσπαθούν να εισάγουν αντίστοιχες γνώσεις στα βιογραφικά τους και γενικά όλοι επιχειρούν να προσδώσουν ένα "άρωµα" αντικειµενοστρέφειας στις εφαρµογές τους. Οι λόγοι για τους οποίους ο αντικειµενοστρεφής προγραµµατισµός γνωρίζει τέτοιες ηµέρες δόξας είναι επίσης πολλαπλοί: Η έρευνα αλλά και η πράξη απέδειξαν ότι οι αντικειµενοστρεφείς τεχνικές εφαρµόζονται επιτυχώς τόσο σε προβλήµατα µεγάλης κλίµακας όσο και σε απλά προγράµµατα. Παρέχουν µια µεθοδολογία αφαίρεσης που προσοµοιάζει µε τις τεχνικές που οι άνθρωποι χρησιµοποιούν για να λύνουν καθηµερινά προβλήµατα. Επιπλέον, οι πολύ ισχυρές και εύχρηστες γλώσσες προγραµµατισµού που διατίθενται και οι οποίες υποστηρίζουν το αντικειµενοστρεφές µοντέλο, συνοδεύονται από ένα ολοένα και αυξανόµενο αριθµό εργαλείων και βιβλιοθηκών προσελκύοντας το ενδιαφέρον έµπειρων αλλά και νέων προγραµµατιστών. Βεβαίως και ένας επιπλέον λόγος, είναι πιθανόν η (λανθασµένη) αντίληψη ότι κάποιος που γνωρίζει για παράδειγµα C (ή κάποια άλλη γλώσσα διαδικασιακού προγραµµατισµού), µπορεί µε µικρή προσπάθεια να προγραµµατίζει σε C++ (ή κάποια άλλη γλώσσα αντικειµενοστρεφούς προγραµµατισµού). Ωστόσο, ο αντικειµενοστρεφής προγραµµατισµός είναι ένας ριζοσπαστικά διαφορετικός τρόπος σκέψης για τον τρόπο µε τον ο- ποίο δοµείται και µεταφέρεται η πληροφορία σε ένα σύστηµα. Αξίζει να σηµειωθεί ότι η χρήση µιας αντικειµενοστρεφούς γλώσσας (όπως η Java ή η C++) δεν αποτελεί από µόνη της ούτε ικανή ούτε αναγκαία συνθήκη για την ανάπτυξη αντικειµενοστρεφών συστηµάτων λογισµικού. Αναφέρθηκε ότι ο αντικειµενοστρεφής προγραµµατισµός είναι κατάλληλος τόσο για έργα λογισµικού µικρής όσο και µεγάλης κλίµακας. Με τον όρο µεγάλη κλίµακα, 15

16 ΑΝΤΙΚΕΙΜΕΝΟΣΤΡΕΦΗΣ ΣΧΕ ΙΑΣΗ εννοούνται έργα στην ανάπτυξη των οποίων θα συµµετάσχουν πολλά άτοµα και τα προϊόντα που θα παραχθούν θα εξελιχθούν σε πολλαπλές εκδόσεις (multi-person, multi-version projects). Είναι ακριβώς αυτή η κατηγορία προβληµάτων όπου το αντικειµενοστρεφές µοντέλο σκέψης εµφανίζει τα µεγαλύτερα πλεονεκτήµατά του. Σε τέτοια έργα, το µείζον πρόβληµα δεν είναι η κατάστρωση των αλγορίθµων ή η µετατροπή των αλγορίθµων σε κώδικα αλλά η επικοινωνία µεταξύ των υποµονάδων του έργου και η συντήρηση του λογισµικού. Το πρόβληµα επικοινωνίας των υποµονάδων δεν αφορά µόνο στην (αναµενόµενη) αναγκαιότητα συνεργασίας µεταξύ των διαφόρων τµηµάτων κώδικα που θα αναπτυχθούν. Αφορά επίσης στη συννενόηση µεταξύ των ατόµων µε πολλαπλούς ρόλους (αναλυτές, σχεδιαστές, προγραµµατιστές, ελεγκτές, διοίκηση) που συµµετέχουν στην οµάδα ανάπτυξης. Ο αντικειµενοστρεφής τρόπος ανάλυσης και σχεδίασης αποτελεί την ιδανική µεθοδολογία για το διαχωρισµό και την οργάνωση ενός µεγάλου έργου το οποίο θα αναπτυχθεί σε τµήµατα. Η συντήρηση ενός έργου λογισµικού προφανώς δεν σχετίζεται µε την κλασσική έννοια της συντήρησης, καθώς το λογισµικό δεν "φθείρεται" από τη χρήση και τα συστατικά του δεν χρήζουν αντικατάστασης λόγω βλάβης που επήλθε από την πάροδο του χρόνου. Η συντήρηση συνίσταται στις ενέργειες εκείνες που είναι απαραίτητες λόγω της εξέλιξης του λογισµικού και περιλαµβάνει δύο υποκατηγορίες: α) τη διορθωτική συντήρηση (corrective maintenance) που έχει ως στόχο τη διόρθωση σφαλµάτων που αποκαλύπτονται λόγω της εγκατάστασης και χρήσης του λογισµικού που παρήχθη και β) την προσαρµοστική συντήρηση (adaptive maintenance) που πραγµατοποιείται για την προσθήκη στο λογισµικό νέων λειτουργιών βάσει των νέων απαιτήσεων που προέρχονται από τους χρήστες. Αν υποθέσουµε ότι κάποιο έργο λογισµικού δεν πρόκειται να εξελιχθεί ποτέ (δηλαδή µετά την ανάπτυξη της πρώτης γενιάς δεν αναµένεται νέα γενιά), είναι ίσως δύσκολο να επιχειρηµατολογήσει κανείς υπέρ των πλεονεκτηµάτων του αντικειµενοστρεφούς προγραµµατισµού έναντι άλλων µοντέλων. Για την ακρίβεια, ίσως επισηµάνει κανείς µειονεκτήµατα καθώς θα περιλαµβάνονται στοιχεία στον κώδικα που θα µοιάζουν ίσως περιττά. Ωστόσο, η πραγµατική "δύναµη" του αντικειµενοστρεφούς προγραµµατισµού αποκαλύπτεται όταν το λογισµικό που έχει παραχθεί πρόκειται να εξελιχθεί και µάλιστα πολλαπλές φορές. Γλώσσες όπως η Java, C++ και Smalltalk, σε συνδυασµό µε καλή αντικειµενοστρεφή σχεδίαση, δηµιουργούν το πλαίσιο για την ανάπτυξη λογισµικού, το οποίο συντηρείται εύκολα και αποδοτικά, δηλαδή µε µικρή προσπάθεια και κόστος χωρίς να υποβαθµίζεται η ποιότητα του λογισµικού. Κατά συνέπεια, ένας καλός προγραµµατιστής λογισµικού χαρακτηρίζεται από την ικανότητά του να σχεδιάζει το λογισµικό λαµβάνοντας υπόψη τις πιθανές αλλαγές που πρόκειται να προέλθουν από τους χρήστες. Όπως χαρακτηριστικά λέγεται, η µόνη α- λήθεια στο λογισµικό είναι ότι "οι απαιτήσεις πρόκειται πάντοτε να αλλάζουν". Καλή σχεδίαση σηµαίνει ότι αν και όταν έρθουν αλλαγές που αφορούν τις απαιτήσεις του συστήµατος, το λογισµικό θα πρέπει να είναι "ευέλικτο" και να µπορεί να τροποποιηθεί ανάλογα, µε την ελάχιστη δυνατή προσπάθεια και µε τις µικρότερες δυνατές συνέπειες για τις υπόλοιπες λειτουργίες του. Αν για παράδειγµα, σε ένα αντικειµενοστρε-

1 Εισαγωγή 17 φές σύστηµα χιλίων κλάσεων ζητηθεί η προσθήκη µιας νέας λειτουργίας και αυτή µπορεί να υλοποιηθεί τροποποιώντας µία ή δύο κλάσεις, τότε το σύστηµα είναι ευέλικτο. Αν από την άλλη απαιτείται η ριζική αναπροσαρµογή των περισσοτέρων κλάσεων, η ικανοποίηση των απαιτήσεων ισοδυναµεί µε την ανάπτυξη νέου λογισµικού. Παρόλο που οι αντικειµενοστρεφείς γλώσσες παρέχουν την υποδοµή για την ανάπτυξη ευέλικτων προγραµµάτων, η σχεδίαση ενός συστήµατος είναι αυτή που εξασφαλίζει την ποιότητα αναφορικά µε την εύκολη συντήρηση. Οι αρχές, τα πρότυπα και οι ευρετικοί κανόνες σχεδίασης που παρουσιάζονται σε αυτό το βιβλίο, έχουν ως στόχο την αξιοποίηση των πλεονεκτηµάτων που προσφέρει το αντικειµενοστρεφές µοντέλο, κυρίως σε σχέση µε τη δυνατότητα εύκολης συντήρησης. Βεβαίως, η καλή σχεδίαση έχει και άλλες θετικές και εξίσου σηµαντικές συνέπειες. Ένα ορθά σχεδιασµένο σύστηµα είναι εύκολα κατανοητό, στοιχείο ιδιαιτέρως σηµαντικό όταν το λογισµικό δεν πρόκειται να αναπτύσσεται πάντοτε από τα ίδια άτο- µα. Σχεδόν όλοι οι προγραµµατιστές γνωρίζουν ότι η κατανόηση κώδικα που έχει γραφεί από άλλους (ή ακόµα και από τον ίδιο προγραµµατιστή πριν από κάποιο χρονικό διάστηµα) είναι από τις δυσκολότερες εργασίες. Επιπλέον, η καλή σχεδίαση διευκολύνει τον έλεγχο του λογισµικού κατά τη διάρκεια και µετά το πέρας της υλοποίησης. υσκολία στην πραγµατοποίηση του ελέγχου και του εντοπισµού των αιτιών των σφαλµάτων έχει ως συνέπεια τη δραµατική αύξηση του κόστους ανάπτυξης και την καθυστέρηση στην παράδοση του προϊόντος. Τέλος, η παραγωγή τεκµηρίωσης (συνοδευτικών εγγράφων και διαγραµµάτων) σε όλες τις φάσεις ανάπτυξης στον κύκλο ζωής του λογισµικού είναι πολύ πιο αξιόπιστη και συνεπής, στην περίπτωση αντικειµενοστρεφών συστηµάτων που πληρούν τις προδιαγραφές καλής ποιότητας σχεδίασης. Για την παρουσίαση των προβληµάτων που µπορούν να παρουσιαστούν κατά την ανάπτυξη ενός έργου λογισµικού το οποίο υφίσταται αλλαγές και εξελίσσεται λόγω νέων απαιτήσεων από πλευράς χρηστών, θα χρησιµοποιηθεί ένα απλοποιηµένο, υποθετικό παράδειγµα. Το παράδειγµα υπερβάλλει σε ορισµένα σηµεία καθώς στόχος είναι να καταδειχθεί η αναγκαιότητα θεώρησης των πιθανών επερχόµενων αλλαγών στις απαιτήσεις. Αρχικά θα παρουσιαστεί η αντιµετώπιση µε µία διαδικασιακή γλώσσα και στη συνέχεια η ορθή σχεδίαση µε χρήση αντικειµενοστρεφούς προγραµµατισµού. 1.1 Πρόγραµµα Σχεδίασης Σχηµάτων Αρχική Σχεδίαση Θεωρούµε ότι η αρχική απαίτηση από τους πελάτες για ένα έργο λογισµικού, αφορά ένα πρόγραµµα το οποίο διαβάζοντας την επιλογή χρώµατος του χρήστη από το πληκτρολόγιο, σχεδιάζει έναν κύκλο µε το συγκεκριµένο χρώµα. Θεωρώντας ότι υπάρχει ήδη µία µονάδα (συνάρτηση) η οποία επιστρέφει το χρώµα που επέλεξε ο χρήστης στο πληκτρολόγιο ως ακέραιο και µία µονάδα η οποία σχεδιάζει έναν κύκλο µε συγκεκρι- µένο χρώµα στην οθόνη, η σχεδίαση της δοµής του συστήµατος (δοµηµένη σχεδίαση) θα ήταν αυτή του Σχήµατος 1.1.

18 ΑΝΤΙΚΕΙΜΕΝΟΣΤΡΕΦΗΣ ΣΧΕ ΙΑΣΗ DrawColoredShape int int KeyboardRead DrawCircle Σχήµα 1.1: Αρχική δοµή προγράµµατος σχεδίασης σχηµάτων Η ανωτέρω σχεδίαση είναι η πλέον λογική, για τις δεδοµένες απαιτήσεις. Η συνάρτηση DrawColoredShape που καλεί τις άλλες δύο, µπορεί να υλοποιηθεί ως εξής: void DrawColoredShape() { int color; color = KeyboardRead(); DrawCircle(color); } //ανάγνωση χρώµατος από πληκτρολόγιο //σχεδίαση κύκλου Έστω, ότι µετά από κάποιο διάστηµα οι απαιτήσεις τροποποιούνται και οι πελάτες ζητούν πλέον και τη δυνατότητα σχεδίασης τετραγώνων µε το χρώµα που επέλεξε ο χρήστης. Η λογικότερη επιλογή θα ήταν η προσθήκη µιας παραµέτρου στη συνάρτηση DrawColoredShape() ώστε µε βάση την τιµή της παραµέτρου να σχεδιάζεται ένας κύκλος ή ένα τετράγωνο αντίστοιχα. Ωστόσο, σε πραγµατικό περιβάλλον, ένα πρόγραµµα σαν το DrawColoredShape που έχει ήδη δηµιουργηθεί, έχει εγκατασταθεί και πολύ πιθανόν να χρησιµοποιείται από πλήθος άλλων προγραµµάτων. Κατά συνέπεια, δεν υπάρχει η δυνατότητα προσθήκης παραµέτρου στη συνάρτηση, διότι τότε θα άλλαζε η υπογραφή της (υπογραφή = όνοµα συνάρτησης, τύπος και αριθµός παραµέτρων, επιστρεφόµενος τύπος) και κατά συνέπεια θα έπρεπε να τροποποιηθούν όλες οι συναρτήσεις που καλούν την DrawColoredShape()! Κάτι τέτοιο, εκτός από τα προβλήµατα κόστους και χρόνου που εισάγει, µπορεί να είναι και αδύνατο στην περίπτωση προϊόντων που έχουν παραδοθεί σε πελάτες. Αφού η αλλαγή της εξωτερικής διασύνδεσης του προγράµµατος δεν είναι δυνατή, η µοναδική λύση είναι η χρήση µιας καθολικής µεταβλητής. Οι καθολικές µεταβλητές είναι γνωστό ότι πρέπει να αποφεύγονται καθώς οδηγούν σε µεγάλο βαθµό σύζευξης µεταξύ των µονάδων, ωστόσο, εδώ είναι η µοναδική εναλλακτική λύση. Μία λογική καθολική µεταβλητή καθορίζει το είδος του σχήµατος που πρόκειται να σχεδιαστεί. Η εξ' ορισµού τιµή της είναι τέτοια ώστε τα ήδη υπάρχοντα προγράµµατα (και τα οποία σχεδιάζουν κύκλους) να µην επηρεαστούν από την αλλαγή. Το πρόγραµµα της DrawColoredShape() θα είναι πλέον:

1 Εισαγωγή 19 //καθολική µεταβλητή bool shapeiscircle = true; void DrawColoredShape() { int color; color = KeyboardRead(); if(shapeiscircle) DrawCircle(color); else DrawSquare(color); } όπου DrawSquare θεωρούµε ότι είναι µία µονάδα σχεδίασης τετραγώνων. Αν κάποιο πρόγραµµα-πελάτης της DrawColoredShape() επιθυµεί να σχεδιάσει τετράγωνα, θα πρέπει να θέσει πρώτα την τιµή false στην καθολική µεταβλητή. Επιπλέον, µετά την κλήση της συνάρτησης, το πρόγραµµα-πελάτης θα πρέπει να επαναφέρει την καθολική µεταβλητή στην αρχική της τιµή, ειδάλλως όλες οι επόµενες κλήσεις θα σχεδιάζουν κύκλους! Η έλλειψη ευελιξίας του συστήµατος ως προς τις νέες απαιτήσεις έχει αρχίσει ήδη να γίνεται εµφανής. Μετά από κάποιο χρονικό διάστηµα θεωρούµε ότι οι χρήστες επανέρχονται µε µία νέα απαίτηση. Επιθυµούν η επιλογή του χρώµατος να µη γίνεται µόνο από το πληκτρολόγιο, αλλά να µπορεί να γίνει και µέσω κατάλληλης οθόνης αφής (touchscreen). Αν υποθέσουµε ότι υπάρχει µια µονάδα ανάγνωσης από την οθόνη αφής, το προηγού- µενο πρόγραµµα τροποποιείται µε τη χρήση µιας νέας καθολικής µεταβλητής, ως εξής: //καθολικές µεταβλητές bool shapeiscircle = true; bool inputiskeyboard = true; void DrawColoredShape() { int color; if(inputiskeyboard) color = KeyboardRead(); else color = TouchScreenRead(); if(shapeiscircle) DrawCircle(color); else DrawSquare(color); }

20 ΑΝΤΙΚΕΙΜΕΝΟΣΤΡΕΦΗΣ ΣΧΕ ΙΑΣΗ Η καθολική µεταβλητή για ακόµα µία φορά προστέθηκε ώστε να µην τροποποιηθεί η υπογραφή της συνάρτησης DrawColoredShape(). Ωστόσο, είναι φανερό, ότι ακό- µα και η έλευση δύο µόνο νέων απαιτήσεων αλλοίωσαν την αρχική σχεδίαση και υποβάθµισαν την ποιότητά της. Πλέον είναι αρκετά δύσκολο να πραγµατοποιηθούν νέες αλλαγές ακόµα και του ιδίου τύπου. Αν για παράδειγµα, ζητηθεί η δυνατότητα σχεδίασης και ενός νέου σχήµατος, η φιλοσοφία του ελέγχου που εξετάζει µία απλή λογική µεταβλητή πρέπει να επανεξεταστεί. Το λογισµικό έχει αρχίσει να εµφανίζει συµπτώ- µατα "φτωχής" σχεδίασης τα οποία θα αναλυθούν στα επόµενα κεφάλαια. 1.2 Πρόγραµµα Σχεδίασης Σχηµάτων Βελτιωµένη Σχεδίαση Αν υποθέσουµε ότι η οµάδα ανάπτυξης είχε γνώση των αντικειµενοστρεφών τεχνικών, η αρχική σχεδίαση του συστήµατος θα ήταν ουσιαστικά η ίδια. Η διαφορετική αντιµετώπιση λαµβάνει χώρα µόνο µετά την εµφάνιση των νέων απαιτήσεων. Το γεγονός ότι το σχήµα που σχεδιάζεται άλλαξε, υποδηλώνει έναν "άξονα αλλαγών" (axis of change), κατά µήκος του οποίου µπορούν να γίνουν και άλλες παρόµοιες αλλαγές στο µέλλον. Με άλλα λόγια, µπορεί στο µέλλον να ζητηθεί και η σχεδίαση άλλων σχηµάτων εκτός από κύκλους και τετράγωνα. Για το λόγο αυτό, η οµάδα ανάπτυξης επιλέγει να καταστήσει το σχέδιο ανθεκτικό σε τέτοιου τύπου αλλαγές, χρησιµοποιώντας την αφηρηµένη έννοια ενός Σχήµατος, εφοδιασµένη µε µία λειτουργία σχεδίασης. Η συνάρτηση DrawColoredShape() µπορεί πλέον να αποστέλλει µηνύµατα σε αυτή την αφαίρεση τύπου Σχήµα (Shape) και η οποία υλοποιείται στις αντικειµενοστρεφείς γλώσσες ως αφηρηµένη κλάση (C++) ή ως διασύνδεση (Java). Κάθε πραγµατικό σχήµα (π.χ. κύκλος, τετράγωνο) υλοποιείται ως µία συγκεκριµένη κλάση που κληρονοµεί (υλοποιεί) την αφαίρεση τύπου Σχήµα. Η στατική δοµή του βελτιωµένου πλέον συστήµατος θα µπορούσε να αναπαρασταθεί µε ένα διάγραµµα κλάσεων όπως αυτό του Σχήµατος 1.2 (Τα διαγράµµατα κλάσεων θα εξεταστούν στο 2 ο κεφάλαιο. Για DrawColoredShape Shape KeyboardRead Circle Square Σχήµα 1.2: Βελτιωµένη δοµή προγράµµατος σχεδίασης σχηµάτων µετά την πρώτη αλλαγή στις απαιτήσεις

1 Εισαγωγή 21 την κατανόηση του διαγράµµατος, κάθε ορθογώνιο συµβολίζει µία κλάση, οι γραµµές συµβολίζουν διαύλους επικοινωνίας µεταξύ των κλάσεων, ενώ σηµειώνονται επίσης και τα ονόµατα των µεθόδων). Το σύστηµα πλέον δεν καλύπτει απλώς την νέα απαίτηση αλλά έχει καλύτερη σχεδίαση καθώς συµµορφώνεται µε την αρχή της Ανοικτής-Κλειστής Σχεδίασης που θα εξεταστεί σε επόµενο κεφάλαιο. Πλέον, η λειτουργικότητα της µονάδας DrawColored- Shape µπορεί να επεκταθεί (προσθέτοντας τη δυνατότητα σχεδίασης οποιουδήποτε νέου σχήµατος πέραν των κύκλων και τετραγώνων) χωρίς να απαιτείται η τροποποίηση του κώδικά της. Με άλλα λόγια, η συµπεριφορά του συστήµατος που παράγει η υποτιθέµενη οµάδα ανάπτυξης µπορεί να εµπλουτίζεται (ανοικτή σε επέκταση) χωρίς καµία αλλαγή του λογισµικού (κλειστή σε αλλαγές)! Ο κώδικας θα έχει την ακόλουθη µορφή: class Shape { virtual void draw() = 0; //αµιγώς υπερβατή µέθοδος: ίνει τη //δυνατότητα πολυµορφικής συµπεριφοράς class Circle : public Shape { virtual void draw() { DrawCircle(); } class Square : public Shape { virtual void draw() { DrawSquare(); } void DrawColoredShape(Shape* myshape) { int color; color = KeyboardRead(); myshape->draw(); } Όπως γίνεται φανερό, ο κώδικας (και η υπογραφή) της DrawColoredShape τροποποιήθηκε. Αυτό ήταν αναγκαίο για τη βελτίωση της σχεδίασης, ωστόσο απαιτείται µόνο για τη συγκεκριµένη αλλαγή σχήµατος. Πλέον, η συνάρτηση DrawColored- Shape() λαµβάνει ως παράµετρο έναν δείκτη (pointer) προς την αφηρηµένη κλάση Σχήµα. H συνάρτηση DrawColoredShape() θα λειτουργήσει εξίσου, για οποιοδήποτε πραγµατικό σχήµα (κύκλο, τετράγωνο ή οτιδήποτε άλλο) περάσει ως παράµετρος. Η δυνατότητα αυτή παρέχεται µέσω του πολυµορφισµού που θα εξεταστεί αναλυτικά στο 4 ο κεφάλαιο. Σηµειώνεται ότι, η οµάδα σχεδίασης δεν επιχείρησε να προβλέψει το είδος των ε- περχόµενων αλλαγών (κάτι τέτοιο θα ήταν εξαιρετικά δύσκολο αν όχι αδύνατο). Η

22 ΑΝΤΙΚΕΙΜΕΝΟΣΤΡΕΦΗΣ ΣΧΕ ΙΑΣΗ αρχική σχεδίαση ήταν η πλέον προφανής. Μόνο µετά την αλλαγή των απαιτήσεων η σχεδίαση του συστήµατος τροποποιήθηκε και µάλιστα προς την κατεύθυνση της ανθεκτικότητας του συστήµατος σε περαιτέρω αλλαγές του ιδίου τύπου. Το να επιχειρήσει κανείς να σχεδιάσει ένα σύστηµα ανθεκτικό ως προς όλες τις πιθανές µελλοντικές α- παιτήσεις, σηµαίνει ότι το λογισµικό θα πρέπει να ενσωµατώσει πληθώρα περιττών στοιχείων. Με άλλα λόγια, η βελτίωση της σχεδίασης επιδιώκεται µόνο αφού πρώτα διαγνωστεί κάποια αδυναµία που αφορά στη συντήρηση του συστήµατος. Στην περίπτωση έλευσης νέων αλλαγών στις απαιτήσεις, όπως για παράδειγµα η δυνατότητα χρήσης ως συσκευής εισόδου µιας οθόνης αφής, η σχεδίαση πρέπει να αναδοµηθεί ως προς τον συγκεκριµένο άξονα αλλαγών. Με στόχο το "κλείσιµο" της σχεδίασης έναντι άλλων πιθανών συσκευών εισόδου, εισάγεται στο σύστηµα η αφαίρεση τύπου Είσοδος και υλοποιείται ως αφηρηµένη κλάση ή διασύνδεση. Κάθε συγκεκριµένη είσοδος κληρονοµεί την αφαίρεση παρέχοντας υλοποίηση στις λειτουργίες που απαιτούνται, όπως φαίνεται στο διάγραµµα κλάσεων της UML του Σχήµατος 1.3. +read() Input DrawColoredShape Shape Keyboard TouchScreen Circle Square +read() +read() Σχήµα 1.3: Βελτιωµένη δοµή προγράµµατος σχεδίασης σχηµάτων µετά τη δεύτερη αλλαγή στις απαιτήσεις ενώ ο αντίστοιχος κώδικας είναι: class Input { virtual int read() = 0; class Keyboard : public Input { virtual int read() { return KeyboardRead(); } class TouchScreen : public Input { virtual int read() { return TouchScreenRead(); }

1 Εισαγωγή 23 class Shape { virtual void draw() = 0; class Circle : public Shape { virtual void draw() { DrawCircle(); } class Square : public Shape { virtual void draw() { DrawSquare(); } void DrawColoredShape(Shape* myshape, Input* myinput) { int color; color = myinput -> read(); myshape -> draw(); } Πλέον, η συνάρτηση DrawColoredShape() λαµβάνει ως παράµετρο και έναν δείκτη προς την αφαίρεση τύπου Είσοδος. Μπορεί δε, να λειτουργήσει σωστά, για οποιοδήποτε αντικείµενο µιας κλάσης η οποία υλοποιεί την αφαίρεση Input, ακόµα και αν µια τέτοια κλάση (π.χ. µια νέα συσκευή εισόδου) δεν έχει ακόµα εφευρεθεί! 1.3 ιάγνωση Προβληµάτων Εύρεση της βελτιωµένης σχεδίασης Το ερώτηµα που τίθεται, είναι πώς µπορεί να γνωρίζει η οµάδα ανάπτυξης τι ακριβώς πρέπει να τροποποιηθεί ώστε η σχεδίαση να παραµείνει ανθεκτική έναντι µελλοντικών αλλαγών στα σχήµατα ή τις εισόδους. Το θέµα αυτό είναι το αντικείµενο των κεφαλαίων που διαπραγµατεύονται τις αρχές, τα πρότυπα και τους ευρετικούς κανόνες της αντικειµενοστρεφούς σχεδίασης. Στο συγκεκριµένο παράδειγµα, η αρχική σχεδίαση περιελάµβανε τη µονάδα Draw- ColoredShape η οποία εξαρτιόταν από τις µονάδες KeyboardRead και DrawCircle. Η εξάρτηση υφίσταται, καθώς για την κλήση των αντίστοιχων συναρτήσεων η DrawColoredShape πρέπει τουλάχιστον να γνωρίζει τις υπογραφές τους. Ωστόσο, η συνάρτηση DrawColoredShape() είναι µια µονάδα υψηλού επιπέδου η οποία θέτει τη στρατηγική στο συγκεκριµένο σύστηµα. Οι άλλες δύο συναρτήσεις είναι µονάδες χαµηλού επιπέδου που παρέχουν απλώς την υλοποίηση. Η συγκεκριµένη σχεδίαση πάσχει από το ότι η στρατηγική υψηλού επιπέδου εξαρτάται από τις λεπτοµέρειες υλοποίησης.

24 ΑΝΤΙΚΕΙΜΕΝΟΣΤΡΕΦΗΣ ΣΧΕ ΙΑΣΗ Η κατανόηση αυτής της αδυναµίας είναι το πρώτο βήµα για τη βελτίωση της σχεδίασης. Στόχος πλέον είναι η αντιστροφή των εξαρτήσεων έτσι ώστε οι µονάδες χαµηλού επιπέδου να εξαρτώνται από τη στρατηγική (ότι ακριβώς είναι επιθυµητό και στην πραγµατικότητα). Η επίλυση αυτού του σχεδιαστικού προβλήµατος επιτεύχθηκε µε την εφαρµογή ενός κατάλληλου προτύπου σχεδίασης (την ίδια φιλοσοφία έχουν τα πρότυπα σχεδίασης "Στρατηγική", "Κατάσταση" και "Μέθοδος Υπόδειγµα"). Στη βελτιωµένη σχεδίαση η συνάρτηση DrawColoredShape() σχετίζεται µόνο µε τις αφαιρέσεις τύπου Σχήµα και Είσοδος και δεν εξαρτάται από αυτές, καθώς δεν αποτελούν κάτι συγκεκριµένο. Οι διάφορες κλάσεις που υλοποιούν αυτές τις αφηρηµένες κλάσεις είναι πλέον υποχρεωµένες να συµµορφώνονται µε ότι επιβάλλουν οι αφαιρέσεις. Με το ανωτέρω απλουστευτικό παράδειγµα επιχειρήθηκε να δοθεί µια εικόνα των προβληµάτων που µπορούν να εµφανιστούν ως συνέπεια µιας κακής σχεδίασης. Το αντικείµενο των επόµενων κεφαλαίων είναι η απεικόνιση ενός συστήµατος µε τη χρήση της Ενοποιηµένης Γλώσσας Μοντελοποίησης (UML) καθώς και η παράθεση αντιπροσωπευτικών τεχνικών βελτίωσης της σχεδίασης αντικειµενοστρεφούς λογισµικού.