'
Καλώς ορίσατε στην πρώτη ανάρτηση της σειράς 'Design Patterns Exposed'. Σε αυτήν τη σειρά θα αποκαλύψουμε κάθε σχέδιο μοτίβου από το μηδέν.
Η απλή γνώση μιας γλώσσας προγραμματισμού και των κατασκευών της δεν θα σας κάνει καλύτερο προγραμματιστή ή προγραμματιστή. Απαιτεί γνώση των Design Patterns για τη δημιουργία λογισμικού που θα λειτουργεί σήμερα και στο μέλλον.
Πολλοί προγραμματιστές έχουν ήδη αντιμετωπίσει αυτά τα προβλήματα σχεδιασμού που αντιμετωπίζετε τώρα ή θα αντιμετωπίσετε στο μέλλον. Έχουν καθορίσει έναν τυπικό τρόπο αντιμετώπισης αυτού του προβλήματος. Έτσι, χρησιμοποιώντας τα σχέδια μοτίβων, έχετε το πλεονέκτημα της χρήσης αποδεδειγμένων τεχνικών.
Κάθε σχέδιο σχεδίασης προορίζεται για την επίλυση ενός συγκεκριμένου είδους κατάστασης, μπορεί να υπάρχουν καταστάσεις όπου μπορούν να χρησιμοποιηθούν περισσότερα από ένα σχέδια σχεδίασης.
Οι περισσότεροι από τους προγραμματιστές προσπαθούν απλώς να λύσουν το πρόβλημα που αντιμετωπίζουν χωρίς να ασχολούνται με τα μοτίβα σχεδιασμού, τον περιττό κώδικα ή ακόμη και τη στενή σύζευξη. Αλλά οι καλοί προγραμματιστές ξεκινούν διαφορετικά. Σκέφτονται τις σημερινές απαιτήσεις, τις μελλοντικές απαιτήσεις, τη συντήρηση του κώδικα και την επαναχρησιμοποίηση του κώδικα.
Οι καλοί προγραμματιστές δεν βιάζονται να ξεκινήσουν την κωδικοποίηση μόλις λάβουν τις απαιτήσεις. Κάθονται και σκέφτονται το πρόβλημα σχετικά με το αν το σχέδιό τους θα λειτουργήσει. Εάν ναι, εάν θα λειτουργήσει μετά από 6 μήνες, πότε θα αλλάξουν οι απαιτήσεις.
Οι καλοί προγραμματιστές παίρνουν το στυλό και το χαρτί τους και αρχίζουν να σχεδιάζουν τα μαθήματά τους και τη σχέση μεταξύ των τάξεων. Προσπαθούν να χαλαρώσουν τη σύζευξη και την υψηλή συνοχή στο σχεδιασμό τους, ενώ κάνουν όλα αυτά στο μυαλό τους έχουν αντικειμενοστρεφείς αρχές. Δεν μπαίνουν αμέσως σε κωδικό χαμηλού επιπέδου. Για να σχεδιάσετε ευέλικτο και επαναχρησιμοποιήσιμο λογισμικό, θα πρέπει να ακολουθήσετε αυτήν την προσέγγιση, διαφορετικά θα βρείτε πάντα τον εαυτό σας να τροποποιεί τον κώδικα που είχατε γράψει νωρίτερα.
Υπάρχει μόνο ένα πράγμα που είναι σταθερό στη βιομηχανία λογισμικού και είναι Αλλαγή. Οι απαιτήσεις σίγουρα θα συνεχίσουν να αλλάζουν. Πώς λοιπόν σχεδιάζουμε το λογισμικό που ο κώδικάς σας μπορεί εύκολα να προσαρμοστεί στις μελλοντικές απαιτήσεις; Για αυτό πρέπει να ξεκινήσετε νωρίς και να το σχεδιάσετε με τέτοιο τρόπο ώστε οι μελλοντικές απαιτήσεις να μην παραβιάζουν τον προηγούμενο κωδικό σας.
Πως μπορώ να το κάνω αυτό?
Λοιπόν, μπορεί να γίνει ακολουθώντας τις Αρχές Σχεδιασμού και τα Σχέδια Σχεδιασμού με βάση αυτές τις αρχές.
Τώρα, ας δούμε την κωδικοποίηση και να ξεκινήσουμε το ταξίδι για να γίνουμε καλύτερος προγραμματιστής. Σε αυτήν την ανάρτηση, θα αποκαλύψουμε ένα από τα πιο σημαντικά μοτίβα - Σχέδιο στρατηγικής .
Όταν λέω το πιο σημαντικό αντικατοπτρίζεται στο κοινό πρόβλημα που επιλύεται με τη στρατηγική.
Τι είναι το σχέδιο στρατηγικής;
Εδώ είναι ο ορισμός κατευθείαν από το βιβλίο 'Gang of Four':Το Στρατηγικό Μοτίβο χρησιμοποιείται για τη δημιουργία μιας εναλλάξιμης οικογένειας αλγορίθμων από τους οποίους επιλέγεται η απαιτούμενη διαδικασία κατά το χρόνο εκτέλεσης'.
Σε περίπτωση που είστεδεν καταλαβαίνουμε, μην ανησυχείτε, θα το εξηγήσουμε στο ααπλούστεροτρόποςγια εσάςκαταλαβαίνουν.
Ας καταλάβουμε πρώτα το πρόβλημα και μετά θα δούμε πώς μπορεί να λύσει αυτό το Σχήμα Στρατηγικής.
Στο παραπάνω διάγραμμα UML, έχουμε την κλάση περίληψης ζώων και δύο συγκεκριμένες κατηγορίες, το σκυλί και το πουλί, που εκτείνονται από την κατηγορία super των ζώων.
Ας ορίσουμε λοιπόν μια κατηγορία αφηρημένων ζώων και δύο συγκεκριμένες κατηγορίες, το σκυλί και το πουλί.
Τι πιστεύετε για τον παραπάνω σχεδιασμό; Υπάρχει ένα μεγάλο λάθος στο σχεδιασμό μας.
Όλα τα ζώα δεν μπορούν να πετάξουν, όπως στην παραπάνω περίπτωση ένα σκυλί δεν μπορεί να πετάξει. Αλλά εξακολουθεί να έχει «μύγα» συμπεριφορά.
Κάναμε ένα λάθος γράφοντας τη μέθοδο αφηρημένης μύγας () μέσα στην τάξη των ζώων. Αυτός ο σχεδιασμός θα αναγκάσει κάθε υποκατηγορία Dog, Bird, Penguin, Crocodile, Goose κ.λπ. να εφαρμόσει τη μέθοδο fly ().
Θα έπρεπε να καταλάβουμε ότι η πτήση είναι μια ικανότητα που δεν θα έχουν όλα τα ζώα. Παρέχοντας τη μέθοδο fly () στην κατηγορία αφηρημένων ζώων, έχουμε ορίσει την ικανότητα πτήσης σε όλες τις υποκατηγορίες που δεν είναι σωστή για όλες τις υποκατηγορίες ζώων.
Ίσως να σκεφτείτε ποιο είναι το πρόβλημα στην εφαρμογή της μεθόδου fly στις υποκατηγορίες. Παρόλο που μπορείτε να εφαρμόσετε τη μέθοδο fly () στις υποκατηγορίες ζώων που δεν πετούν για να εκτυπώσετε απλά 'Δεν μπορώ να πετάξω'. Αλλά το πρόβλημα είναι ότι εξακολουθείτε να δίνετε τη συμπεριφορά της μύγας σε ζώα που δεν πετούν. Αυτό δεν είναι σωστό.
Πώς αισθάνεστε να καλέσετε dog.fly () ή crocodile.fly ().
Έτσι, τώρα καταλάβαμε ότι ο σχεδιασμός μας δεν είναι σωστός και πρέπει να αφαιρέσουμε τη μέθοδο fly () από την υποκατηγορία Animal.
Ποιος είναι ο άλλος τρόπος σχεδιασμού των τάξεων μας με τέτοιο τρόπο ώστε ο σχεδιασμός μας να μην επιβάλλει σε όλες τις υποκατηγορίες ζώων να έχουν συμπεριφορά μύγας.
Μια λύση που έρχεται αμέσως στο μυαλό είναι ότι μπορούμε να φτιάξουμε μια διεπαφή πτήσης με μέθοδο πτήσης και μόνο τα ζώα που μπορούν να πετάξουν θα εφαρμόσουν αυτή τη διεπαφή πτήσης. Με αυτόν τον τρόπο δεν θα επιβάλουμε σε όλες τις υποκατηγορίες ζώων να καθορίσουν μια συμπεριφορά κατά τη διάρκεια της πτήσης. Ας κωδικοποιήσουμε λοιπόν αυτήν την προσέγγιση σχεδιασμού.
Τώρα, η τάξη των ζώων μας θα μοιάζει με τον παρακάτω κώδικα αφού αφαιρεθεί η μέθοδος πτήσης από την κατηγορία ζώων.
Τώρα ας καθορίσουμε τη διεπαφή Flying
Τώρα, η κατηγορία σκυλιών θα αλλάξειόπως καιο παρακάτω κώδικας και δεν χρειάζεται να έχει συμπεριφορά πτήσης.
Ας δούμε μερικές από τις υποκατηγορίες των ζώων μας που θα έχουν συμπεριφορά πτήσης.
Το system.exit (0) μπορεί να χρησιμοποιηθεί για τον τερματισμό του προγράμματος.
Λύσαμε το προηγούμενο πρόβλημά μας, αλλά αντιμετωπίσαμε ένα νέο πρόβλημα και αυτό είναι το 'Code Duplication'.
Ας πούμε, θα έχουμε 100 διαφορετικές υποκατηγορίες ιπτάμενων ζώων. Πρέπει να αντιγράψουμε τον κώδικα για τη συμπεριφορά της πτήσης, καθώς η διεπαφή πτήσης δεν μπορεί να παρέχει καμία εφαρμογή για συμπεριφορά πτήσης, και αργότερα εάν θέλουμε να αλλάξουμε την εφαρμογή της μεθόδου πτήσης () σε οποιαδήποτε υποκατηγορία θα πρέπει να ανοίξουμε αυτήν την κλάση και να αλλάξουμε τον κώδικα που είναι κακό. Μας λείπει κάτι μεγάλο και, δηλαδή, δεν μπορούμε να αλλάξουμε τη συμπεριφορά της τάξης στο χρόνο εκτέλεσης.
Αλλά μην ανησυχείτε, το Σχήμα Στρατηγικής είναι εκεί για να σας βγάλει από αυτό το πρόβλημα.
Ας αναθεωρήσουμε λοιπόν τον κώδικά μας για να χρησιμοποιήσουμε τη στρατηγική.
μεταβείτε στη δήλωση στο c ++
Η διεπαφή πτήσης θα παραμείνει η ίδια όπως είναι. Τώρα, αντί για κάθε υποκατηγορία ιπτάμενου που εφαρμόζει την ίδια τη διεπαφή πτήσης, θα ορίσουμε ξεχωριστές συγκεκριμένες κατηγορίες που θα εφαρμόσουν διαφορετική συμπεριφορά πτήσης. Ας δούμε πώς να το κάνουμε αυτό.
Λοιπόν, πώς λειτουργούν όλα, ας δούμε το TestClass
Χρησιμοποιώντας το Στρατηγικό Μοτίβο είμαστε πλέον σε θέση να αλλάξουμε τη συμπεριφορά πτήσης οποιουδήποτε ζώου στο χρόνο εκτέλεσης και αυτό χωρίς να επιβάλουμε υποκατηγορίες για να καθορίσουμε την ίδια τη συμπεριφορά πτήσης.
Πότε να χρησιμοποιήσετε το σχέδιο στρατηγικής;
Όταν θέλετε να μπορείτε να αλλάξετε τη συμπεριφορά στο χρόνο εκτέλεσης δυναμικά.
Για να βεβαιωθείτε ότι έχετε κατανοήσει με σαφήνεια το Στρατηγικό Μοτίβο ας πάρουμε ένα άλλο παράδειγμα.
Στην παραπάνω τάξη υπαλλήλων ορίζουμε την αμοιβή του υπαλλήλου ανάλογα με τον ορισμό του. Εάν ένας υπάλληλος είναι 'Intern' προσθέτουμε 10% μπόνους στον βασικό μισθό για να υπολογίσουμε την πραγματική αμοιβή.
Εάν ένας υπάλληλος είναι 'Web Developer' προσθέτουμε 20% μπόνους στον βασικό μισθό για να υπολογίσουμε την πραγματική αμοιβή και ακολουθεί η παρόμοια διαδικασία για άλλους τύπους εργαζομένων. Αν και ο αλγόριθμός μας για τον υπολογισμό της πραγματικής αμοιβής είναι πολύ απλός για να γίνει ευκολότερη η κατανόησή του, αλλά τις περισσότερες φορές, περιλαμβάνει πολλές συγκρίσεις και υπολογισμούς.
Λοιπόν, τι συμβαίνει με τον κωδικό υπαλλήλου;
Λοιπόν, ο κωδικός για τον υπολογισμό της αμοιβής (getPay ()) είναι στατικός. Ας υποθέσουμε ότι θέλω να αλλάξω το μπόνους για το «Intern» από 10% σε 14%. Θα πρέπει να ανοίξω τον κωδικό υπαλλήλου και να τον αλλάξω.
Και ένα άλλο πρόβλημα είναι ότι δεν μπορώ να αλλάξω τον αλγόριθμο αμοιβών ενός υπαλλήλου κατά το χρόνο εκτέλεσης. Λοιπόν, πώς να το κάνετε αυτό; Η στρατηγική Pattern χρησιμοποιείται ειδικά για τον χειρισμό αυτού του είδους προβλημάτων.
Ας αναδιαμορφώσουμε τον κώδικα για να χρησιμοποιήσουμε το Στρατηγικό μοτίβο.
Θα καθορίσω διάφορους αλγόριθμους για τον υπολογισμό της αμοιβής. Τότε θα μπορέσω να χρησιμοποιήσω οποιονδήποτε από αυτούς τους αλγόριθμους για τον υπολογισμό της αμοιβής κατά το χρόνο εκτέλεσης.
Τώρα, ας δούμε πώς θα αλλάξει η τάξη υπαλλήλων.
Σημείωση: Έχω καταργήσει τη λογική υπολογισμού αμοιβών από την τάξη υπαλλήλων και δημιούργησα μια καθορισμένη μέθοδο PayAlgorithm () μέσω της οποίας θα ορίσω τον PayAlgorithm που θέλω να χρησιμοποιήσω για τον υπολογισμό των αμοιβών.
Αυτό θα μου δώσει την ευελιξία να υπολογίσω την αμοιβή, καθορίζοντας τυχόν PayAlgorithm δυναμικά κατά το χρόνο εκτέλεσης. Επίσης, σημειώστε ότι αργότερα, εάν πρέπει να αλλάξω τη λογική υπολογισμού αμοιβών, μπορώ να δημιουργήσω έναν νέο αλγόριθμο PayAl και να τον χρησιμοποιήσω για τον υπολογισμό της αμοιβής. Δεν χρειάζεται να αλλάξω τον προηγούμενο κώδικα, δεν είναι υπέροχο;
Ας το δούμε λοιπόν να λειτουργεί.
Ελπίζω να καταλάβατε πολύ καλά τη Στρατηγική. Ο καλύτερος τρόπος για να μάθετε κάτι είναι να εξασκηθείτε.
Σε περίπτωση που έχετε οποιεσδήποτε ερωτήσεις σχετικά με το Στρατηγικό Μοτίβο ή οποιοδήποτε άλλο Μοτίβο, αφήστε τα ερωτήματά σας παρακάτω.
Προσέξτε για την επόμενη ανάρτηση, όπου θα αποκαλύψουμε ένα από τα πιο δημοφιλή Design Pattern, Factory Pattern.
Μέχρι τότε μπορείτε να κατεβάσετε τον κωδικό παιχνιδιού μαζί του και να βεβαιωθείτε ότι έχετε παγώσει το Σχήμα Στρατηγικής στο κεφάλι σας.
Έχετε μια ερώτηση για εμάς; Αναφέρετέ τα στην ενότητα σχολίων και θα επικοινωνήσουμε μαζί σας.
Σχετικές αναρτήσεις: