Μια σύντομη επισκόπηση του αντικειμενοστρεφούς σχεδιασμού λογισμικού

Επίδειξη με την εφαρμογή των μαθημάτων ενός παιχνιδιού ρόλων

Εισαγωγή

Οι περισσότερες σύγχρονες γλώσσες προγραμματισμού υποστηρίζουν και ενθαρρύνουν τον αντικειμενοστρεφή προγραμματισμό (OOP). Παρόλο που τον τελευταίο καιρό φαίνεται να βλέπουμε μια μικρή μετατόπιση από αυτό, καθώς οι άνθρωποι αρχίζουν να χρησιμοποιούν γλώσσες που δεν επηρεάζονται έντονα από το OOP (όπως Go, Rust, Elixir, Elm, Scala), οι περισσότεροι εξακολουθούν να έχουν αντικείμενα. Οι αρχές σχεδιασμού που πρόκειται να σκιαγραφήσουμε εδώ ισχύουν και για γλώσσες εκτός ΟΟΠ.

Για να πετύχετε στη σύνταξη σαφούς, υψηλής ποιότητας, διατηρήσιμου και επεκτάσιμου κώδικα, θα πρέπει να γνωρίζετε για τις αρχές σχεδίασης που έχουν αποδειχθεί αποτελεσματικές για δεκαετίες εμπειρίας.

Αποκάλυψη: Το παράδειγμα που θα περάσουμε θα είναι στο Python. Υπάρχουν παραδείγματα για να αποδειχθεί ένα σημείο και μπορεί να είναι ατημέλητοι με άλλους, προφανείς τρόπους.

Τύποι αντικειμένων

Δεδομένου ότι πρόκειται να μοντελοποιήσουμε τον κώδικά μας γύρω από αντικείμενα, θα ήταν χρήσιμο να γίνει διάκριση μεταξύ των διαφορετικών ευθυνών και παραλλαγών τους.

Υπάρχουν τρεις τύποι αντικειμένων:

1. Αντικείμενο οντότητας

Αυτό το αντικείμενο αντιστοιχεί γενικά σε κάποια πραγματική οντότητα στον προβληματικό χώρο. Ας πούμε ότι χτίζουμε ένα παιχνίδι ρόλων (RPG), ένα αντικείμενο οντότητας θα ήταν η απλή Heroτάξη μας:

Αυτά τα αντικείμενα γενικά περιέχουν ιδιότητες για τον εαυτό τους (όπως healthή mana) και μπορούν να τροποποιηθούν μέσω ορισμένων κανόνων.

2. Αντικείμενο ελέγχου

Τα αντικείμενα ελέγχου (μερικές φορές ονομάζονται και αντικείμενα διαχειριστή ) είναι υπεύθυνα για τον συντονισμό άλλων αντικειμένων. Αυτά είναι αντικείμενα που ελέγχουνκαι χρησιμοποιήστε άλλα αντικείμενα. Ένα εξαιρετικό παράδειγμα στην αναλογία RPG θα ήταν η Fightτάξη, η οποία ελέγχει δύο ήρωες και τους κάνει να πολεμούν.

Ενσωμάτωση της λογικής για έναν αγώνα σε μια τέτοια τάξη σας παρέχει πολλαπλά οφέλη: ένα από τα οποία είναι η εύκολη επεκτασιμότητα της δράσης. Μπορείτε πολύ εύκολα να μεταβιβάσετε έναν τύπο χαρακτήρα χωρίς παίκτη (NPC) για να πολεμήσει ο ήρωας, με την προϋπόθεση ότι εκθέτει το ίδιο API. Μπορείτε επίσης να κληρονομήσετε πολύ εύκολα την τάξη και να παρακάμψετε ορισμένες από τις λειτουργίες για να καλύψετε τις ανάγκες σας.

3. Οριακό αντικείμενο

Αυτά είναι αντικείμενα που βρίσκονται στο όριο του συστήματός σας. Κάθε αντικείμενο που λαμβάνει είσοδο από ή παράγει έξοδο σε άλλο σύστημα - ανεξάρτητα από το αν το σύστημα είναι Χρήστης, το Διαδίκτυο ή μια βάση δεδομένων - μπορεί να ταξινομηθεί ως αντικείμενο ορίου.

Αυτά τα οριακά αντικείμενα είναι υπεύθυνα για τη μετάφραση πληροφοριών μέσα και έξω από το σύστημά μας. Σε ένα παράδειγμα όπου παίρνουμε εντολές χρήστη, θα χρειαζόμασταν το οριακό αντικείμενο για να μεταφράσουμε μια είσοδο πληκτρολογίου (όπως μια διαστημική γραμμή) σε ένα αναγνωρίσιμο συμβάν τομέα (όπως άλμα χαρακτήρων).

Μπόνους: Αντικείμενο τιμής

Τα αντικείμενα τιμής αντιπροσωπεύουν μια απλή τιμή στον τομέα σας. Είναι αμετάβλητα και δεν έχουν καμία ταυτότητα.

Εάν επρόκειτο να τα ενσωματώσουμε στο παιχνίδι μας, ένα Moneyή Damageτάξη θα ήταν πολύ κατάλληλο. Τα εν λόγω αντικείμενα μας επιτρέπουν να διακρίνουμε, να εντοπίζουμε και να εντοπίζουμε εντοπισμό σφαλμάτων λειτουργικότητας, ενώ η αφελής προσέγγιση της χρήσης ενός πρωτόγονου τύπου - μια σειρά από ακέραιους ή έναν ακέραιο - δεν το κάνει.

Μπορούν να ταξινομηθούν ως υποκατηγορία του Entityαντικείμενα.

Βασικές αρχές σχεδιασμού

Οι αρχές σχεδιασμού είναι κανόνες στο σχεδιασμό λογισμικού που έχουν αποδειχθεί πολύτιμοι με την πάροδο των ετών. Η αυστηρή παρακολούθηση τους θα σας βοηθήσει να διασφαλίσετε ότι το λογισμικό σας είναι κορυφαίας ποιότητας.

Αφαίρεση

Η αφαίρεση είναι η ιδέα της απλοποίησης μιας έννοιας στα γυμνά βασικά στοιχεία της σε κάποιο πλαίσιο. Σας επιτρέπει να κατανοήσετε καλύτερα την έννοια, απογυμνώνοντάς την σε μια απλοποιημένη έκδοση.

Τα παραπάνω παραδείγματα απεικονίζουν την αφαίρεση - δείτε πώς Fightείναι δομημένη η τάξη. Ο τρόπος που το χρησιμοποιείτε είναι όσο το δυνατόν πιο απλός - του δίνετε δύο ήρωες ως επιχειρήματα σε περίπτωση και καλείτε τη fight()μέθοδο. Τίποτα περισσότερο, τίποτα λιγότερο.

Η αφαίρεση στον κωδικό σας πρέπει να ακολουθεί τον κανόνα της λιγότερο έκπληξης. Η αφαίρεσή σας δεν πρέπει να εκπλήσσει κανέναν με περιττές και άσχετες συμπεριφορές / ιδιότητες. Με άλλα λόγια - πρέπει να είναι διαισθητικό.

Σημειώστε ότι η Hero#take_damage()λειτουργία μας δεν κάνει κάτι απροσδόκητο, όπως διαγραφή του χαρακτήρα μας μετά το θάνατο. Αλλά μπορούμε να περιμένουμε να σκοτώσει τον χαρακτήρα μας εάν η υγεία του είναι κάτω από το μηδέν.

Ενθυλάκωση

Η ενθυλάκωση μπορεί να θεωρηθεί ότι βάζει κάτι μέσα σε μια κάψουλα - περιορίζετε την έκθεσή της στον έξω κόσμο. Στο λογισμικό, ο περιορισμός της πρόσβασης σε εσωτερικά αντικείμενα και ιδιότητες βοηθά στην ακεραιότητα των δεδομένων.

Εσωτερική λογική εγκλεισμού σε μαύρα κουτιά και διευκολύνει τη διαχείριση των τάξεων σας, επειδή γνωρίζετε ποιο μέρος χρησιμοποιείται από άλλα συστήματα και τι όχι. Αυτό σημαίνει ότι μπορείτε εύκολα να επεξεργαστείτε ξανά την εσωτερική λογική διατηρώντας τα δημόσια μέρη και να είστε βέβαιοι ότι δεν έχετε σπάσει τίποτα. Ως παρενέργεια, η εργασία με την ενσωματωμένη λειτουργικότητα από το εξωτερικό γίνεται πιο απλή καθώς έχετε λιγότερα πράγματα να σκεφτείτε.

Στις περισσότερες γλώσσες, αυτό γίνεται μέσω των λεγόμενων τροποποιητών πρόσβασης (ιδιωτικοί, προστατευμένοι και ούτω καθεξής). Το Python δεν είναι το καλύτερο παράδειγμα αυτού, καθώς δεν διαθέτει τόσο ρητούς τροποποιητές ενσωματωμένους στο χρόνο εκτέλεσης, αλλά χρησιμοποιούμε συμβάσεις για να το επιλύσουμε. Το _πρόθεμα των μεταβλητών / μεθόδων τις δηλώνει ως ιδιωτικές.

Για παράδειγμα, φανταστείτε ότι αλλάζουμε τη Fight#_run_attackμέθοδο μας για να επιστρέψουμε μια δυαδική μεταβλητή που δείχνει εάν ο αγώνας έχει τελειώσει αντί να δημιουργήσει μια εξαίρεση. Θα γνωρίζουμε ότι ο μόνος κώδικας που ενδέχεται να έχουμε σπάσει είναι μέσα στην Fightτάξη, επειδή κάναμε τη μέθοδο ιδιωτική.

Θυμηθείτε, ο κώδικας αλλάζει συχνότερα από ό, τι γράφεται εκ νέου. Το να αλλάζετε τον κώδικά σας με όσο το δυνατόν σαφέστερες και λιγότερες επιπτώσεις είναι η ευελιξία που θέλετε ως προγραμματιστής.

Αποσύνθεση

Η αποσύνθεση είναι η ενέργεια του διαχωρισμού ενός αντικειμένου σε πολλαπλά χωριστά μικρότερα μέρη. Τα εν λόγω μέρη είναι ευκολότερα κατανοητά, συντηρούνται και προγραμματίζονται.

Φανταστείτε ότι θέλαμε να ενσωματώσουμε περισσότερες δυνατότητες RPG όπως buffs, απόθεμα, εξοπλισμό και χαρακτηριστικά χαρακτήρων πάνω από τα Heroεξής:

Υποθέτω ότι μπορείτε να πείτε ότι αυτός ο κώδικας γίνεται αρκετά ακατάστατος. Το Heroαντικείμενο μας είναι να κάνουμε πάρα πολλά πράγματα ταυτόχρονα και αυτός ο κώδικας γίνεται αρκετά εύθραυστος ως αποτέλεσμα αυτού.

Για παράδειγμα, ένα σημείο αντοχής αξίζει 5 υγεία. Εάν θέλουμε ποτέ να το αλλάξουμε αυτό στο μέλλον για να το κάνουμε αξίζει 6 υγεία, θα πρέπει να αλλάξουμε την εφαρμογή σε πολλά μέρη.

Η απάντηση είναι η αποσύνθεση του Heroαντικειμένου σε πολλαπλά μικρότερα αντικείμενα που το καθένα περιλαμβάνει μέρος της λειτουργικότητας.

Τώρα, μετά την αποσύνθεση λειτουργικότητα αντικείμενο ήρωα μας στο HeroAttributes, HeroInventory, HeroEquipmentκαι HeroBuffαντικείμενα, προσθέτοντας λειτουργικότητα μέλλον θα είναι πιο εύκολη, πιο έγκλειστα και καλύτερη αντλείται. Μπορείτε να πείτε ότι ο κώδικάς μας είναι πολύ καθαρότερος και σαφέστερος σχετικά με το τι κάνει.

Υπάρχουν τρεις τύποι σχέσεων αποσύνθεσης:

  • σχέση- Καθορίζει μια χαλαρή σχέση μεταξύ δύο συστατικών. Και οι δύο συνιστώσες δεν εξαρτώνται το ένα από το άλλο, αλλά μπορεί να συνεργάζονται

Παράδειγμα:Hero και ένα Zoneαντικείμενο.

  • agregation - Ορίζει μια αδύναμη σχέση «έχει-α» μεταξύ ενός συνόλου και των τμημάτων του. Θεωρείται αδύναμο, επειδή τα μέρη μπορούν να υπάρχουν χωρίς το σύνολο.

Παράδειγμα:HeroInventory και Item.

Ένα HeroInventoryκουτί μπορεί να έχει πολλά Itemsκαι ένα Itemμπορεί να ανήκει σε οποιοδήποτε HeroInventory(όπως είδη συναλλαγών).

  • σύνθεση - Μια ισχυρή σχέση «έχει-α» όπου το σύνολο και το μέρος δεν μπορούν να υπάρχουν χωρίς το ένα το άλλο. Τα ανταλλακτικά δεν μπορούν να μοιραστούν, καθώς το σύνολο εξαρτάται από αυτά τα ακριβή μέρη.

Παράδειγμα:Hero και HeroAttributes.

Αυτά είναι τα χαρακτηριστικά του Ήρωα - δεν μπορείτε να αλλάξετε τον ιδιοκτήτη τους.

Γενίκευση

Η γενίκευση μπορεί να είναι η πιο σημαντική αρχή σχεδιασμού - είναι η διαδικασία εξαγωγής κοινών χαρακτηριστικών και συνδυασμού τους σε ένα μέρος. Όλοι μας γνωρίζουμε για την έννοια των λειτουργιών και της ταξικής κληρονομιάς - και οι δύο είναι ένα είδος γενίκευσης.

Μια σύγκριση μπορεί να ξεκαθαρίσει τα πράγματα: ενώ η αφαίρεση μειώνει την πολυπλοκότητα κρύβοντας περιττές λεπτομέρειες, η γενίκευση μειώνει την πολυπλοκότητα αντικαθιστώντας πολλές οντότητες που εκτελούν παρόμοιες λειτουργίες με μία μόνο κατασκευή.

Στο δεδομένο παράδειγμα, έχουμε γενικεύσει τη λειτουργικότητα των κοινών Heroκαι των NPC τάξεων μας σε έναν κοινό πρόγονο που ονομάζεται Entity. Αυτό επιτυγχάνεται πάντα μέσω της κληρονομιάς.

Εδώ, αντί να εφαρμόσουμε τις κατηγορίες NPCκαι τα Heroμαθήματά μας δύο φορές και να παραβιάσουμε την αρχή DRY, μειώσαμε την πολυπλοκότητα μεταφέροντας την κοινή λειτουργικότητά τους σε μια βασική τάξη.

Ως προειδοποίηση - μην παρακάνετε την κληρονομιά. Πολλοί έμπειροι άνθρωποι σας προτείνουν να προτιμήσετε τη σύνθεση έναντι της κληρονομιάς.

Η κληρονομικότητα κακοποιείται συχνά από ερασιτέχνες προγραμματιστές, πιθανώς επειδή είναι μια από τις πρώτες τεχνικές OOP που κατανοούν λόγω της απλότητάς της.

Σύνθεση

Η σύνθεση είναι η αρχή του συνδυασμού πολλαπλών αντικειμένων σε ένα πιο περίπλοκο. Πρακτικά λέγεται - δημιουργεί παρουσίες αντικειμένων και χρησιμοποιεί τη λειτουργικότητά τους αντί να το κληρονομούν άμεσα.

Ένα αντικείμενο που χρησιμοποιεί σύνθεση μπορεί να ονομαστεί σύνθετο αντικείμενο . Είναι σημαντικό αυτό το σύνθετο να είναι απλούστερο από το άθροισμα των συνομηλίκων του. Όταν συνδυάζουμε πολλές κατηγορίες σε μία, θέλουμε να ανεβάσουμε το επίπεδο της αφαίρεσης και να κάνουμε το αντικείμενο πιο απλό.

Το API του σύνθετου αντικειμένου πρέπει να κρύψει τα εσωτερικά του στοιχεία και τις αλληλεπιδράσεις μεταξύ τους. Σκεφτείτε ένα μηχανικό ρολόι, έχει τρία χέρια για να δείξει την ώρα και ένα κουμπί για ρύθμιση - αλλά εσωτερικά περιέχει δεκάδες κινούμενα και αλληλοεξαρτώμενα μέρη.

Όπως είπα, η σύνθεση προτιμάται από την κληρονομιά, πράγμα που σημαίνει ότι πρέπει να προσπαθήσετε να μετακινήσετε την κοινή λειτουργικότητα σε ένα ξεχωριστό αντικείμενο που στη συνέχεια χρησιμοποιούν οι κλάσεις - αντί να την αποθηκεύσετε σε μια βασική τάξη που έχετε κληρονομήσει.

Ας παρουσιάσουμε ένα πιθανό πρόβλημα με τη λειτουργικότητα υπερβολικής κληρονομιάς:

Μόλις προσθέσαμε κίνηση στο παιχνίδι μας.

Όπως μάθαμε, αντί να αντιγράψουμε τον κώδικα χρησιμοποιήσαμε τη γενίκευση για να βάλουμε το move_rightκαι τις move_leftλειτουργίες στην Entityτάξη.

Εντάξει, τώρα τι γίνεται αν θέλαμε να εισαγάγουμε mounts στο παιχνίδι;

Οι βάσεις θα πρέπει επίσης να κινούνται αριστερά και δεξιά, αλλά δεν έχουν την ικανότητα να επιτεθούν. Ελάτε να το σκεφτείτε - μπορεί να μην έχουν καν υγεία!

Ξέρω ποια είναι η λύση σας:

Απλώς μετακινήστε τη moveλογική σε ξεχωριστό MoveableEntityή MoveableObjectκλάση που έχει μόνο αυτήν τη λειτουργικότητα. Το Mountμάθημα μπορεί τότε να το κληρονομήσει.

Τότε, τι κάνουμε εάν θέλουμε αναρτήσεις που έχουν υγεία αλλά δεν μπορούν να επιτεθούν; Περισσότερο χωρίζεται σε υποκατηγορίες; Ελπίζω να δείτε πώς η ιεραρχία της τάξης μας θα άρχιζε να γίνεται περίπλοκη παρόλο που η επιχειρηματική μας λογική εξακολουθεί να είναι αρκετά απλή.

Μια κάπως καλύτερη προσέγγιση θα ήταν να αφαιρεθεί η λογική της κίνησης σε μια Movementτάξη (ή κάποιο καλύτερο όνομα) και να την δημιουργήσει στις τάξεις που μπορεί να τη χρειάζονται. Αυτό θα συσκευάσει όμορφα τη λειτουργικότητα και θα την επαναχρησιμοποιήσει σε όλα τα είδη αντικειμένων που δεν περιορίζονται σε αυτά Entity.

Hore, σύνθεση!

Αποποίηση ευθύνης κριτικής σκέψης

Παρόλο που αυτές οι αρχές σχεδιασμού έχουν διαμορφωθεί μέσα από δεκαετίες εμπειρίας, είναι ακόμα εξαιρετικά σημαντικό να μπορείτε να σκεφτείτε κριτικά πριν εφαρμόσετε τυφλά μια αρχή στον κώδικά σας.

Όπως όλα τα πράγματα, το πάρα πολύ μπορεί να είναι κακό. Μερικές φορές οι αρχές μπορούν να ληφθούν πολύ μακριά, μπορείτε να τις πάρετε πολύ έξυπνες και να καταλήξετε σε κάτι που είναι πραγματικά πιο δύσκολο να εργαστείτε.

Ως μηχανικός, το κύριο χαρακτηριστικό σας είναι να αξιολογήσετε κριτικά την καλύτερη προσέγγιση για τη μοναδική σας κατάσταση, όχι να ακολουθείτε τυφλά και να εφαρμόζετε αυθαίρετους κανόνες.

Συνοχή, σύζευξη & διαχωρισμός ανησυχιών

Συνοχή

Η συνοχή αντιπροσωπεύει τη σαφήνεια των ευθυνών μέσα σε μια ενότητα ή με άλλα λόγια - την πολυπλοκότητά της.

Εάν η τάξη σας εκτελεί μία εργασία και τίποτα άλλο, ή έχει σαφή σκοπό - αυτή η τάξη έχει υψηλή συνοχή . Από την άλλη πλευρά, εάν είναι κάπως ασαφές στο τι κάνει ή έχει περισσότερους από έναν σκοπούς - έχει χαμηλή συνοχή .

Θέλετε τα μαθήματά σας να έχουν υψηλή συνοχή. Θα πρέπει να έχουν μόνο μία ευθύνη και αν τους πιάσετε να έχουν περισσότερες - ίσως είναι καιρός να το χωρίσετε.

Σύζευξη

Η σύζευξη καταγράφει την πολυπλοκότητα μεταξύ της σύνδεσης διαφορετικών κατηγοριών. Θέλετε τα μαθήματά σας να έχουν όσο το δυνατόν λιγότερες και απλές συνδέσεις με άλλα μαθήματα, ώστε να μπορείτε να τα ανταλλάξετε σε μελλοντικά συμβάντα (όπως η αλλαγή πλαισίων ιστού). Ο στόχος είναι να υπάρχει χαλαρή ζεύξη .

Σε πολλές γλώσσες αυτό επιτυγχάνεται με μεγάλη χρήση διεπαφών - αφαιρούν τη συγκεκριμένη κλάση που χειρίζεται τη λογική και αντιπροσωπεύουν ένα είδος στρώματος προσαρμογέα στο οποίο κάθε κλάση μπορεί να συνδεθεί.

Διαχωρισμός των ανησυχιών

Το Separation of Concerns (SoC) είναι η ιδέα ότι ένα σύστημα λογισμικού πρέπει να χωριστεί σε μέρη που δεν αλληλεπικαλύπτονται στη λειτουργικότητα. Ή όπως λέει το όνομα - ανησυχία - Ένας γενικός όρος για οτιδήποτε παρέχει λύση σε ένα πρόβλημα - πρέπει να χωριστεί σε διαφορετικά μέρη.

Μια ιστοσελίδα είναι ένα καλό παράδειγμα - έχει τα τρία επίπεδα (Πληροφορίες, Παρουσίαση και Συμπεριφορά) χωρισμένα σε τρία μέρη (HTML, CSS και JavaScript αντίστοιχα).

Εάν κοιτάξετε ξανά το Heroπαράδειγμα RPG , θα δείτε ότι είχε πολλές ανησυχίες από την αρχή (εφαρμόστε buffs, υπολογίστε τις ζημίες επίθεσης, χειριστείτε το απόθεμα, εξοπλίστε τα στοιχεία, διαχειριστείτε τα χαρακτηριστικά). Διαχωρίσαμε αυτές τις ανησυχίες μέσω αποσύνθεσης σε πιο συνεκτικές τάξεις που αφαιρούν και ενσωματώνουν τις λεπτομέρειες τους. Η Heroτάξη μας λειτουργεί τώρα ως σύνθετο αντικείμενο και είναι πολύ απλούστερη από πριν.

Εξόφληση

Η εφαρμογή τέτοιων αρχών μπορεί να φαίνεται υπερβολικά περίπλοκη για ένα τόσο μικρό κομμάτι κώδικα. Η αλήθεια είναι ότι πρέπει για κάθε έργο λογισμικού που σκοπεύετε να αναπτύξετε και να συντηρήσετε στο μέλλον. Η σύνταξη ενός τέτοιου κώδικα έχει πολύ γενικό κόστος στην αρχή αλλά αποδίδει πολλές φορές μακροπρόθεσμα.

Αυτές οι αρχές διασφαλίζουν ότι το σύστημά μας είναι περισσότερο:

  • Επεκτάσιμο : Η υψηλή συνοχή διευκολύνει την υλοποίηση νέων ενοτήτων χωρίς ανησυχία για άσχετη λειτουργικότητα. Η χαμηλή σύζευξη σημαίνει ότι μια νέα μονάδα έχει λιγότερα πράγματα για σύνδεση, επομένως είναι πιο εύκολο να εφαρμοστεί.
  • Συντηρείται : Η χαμηλή σύνδεση διασφαλίζει ότι μια αλλαγή σε μία μονάδα γενικά δεν θα επηρεάσει άλλους. Η υψηλή συνοχή διασφαλίζει ότι μια αλλαγή στις απαιτήσεις του συστήματος θα απαιτήσει όσο το δυνατόν λιγότερη τροποποίηση τάξεων.
  • Επαναχρησιμοποιήσιμο : Η υψηλή συνοχή διασφαλίζει ότι η λειτουργικότητα μιας ενότητας είναι πλήρης και καλά καθορισμένη. Η χαμηλή σύνδεση καθιστά τη μονάδα λιγότερο εξαρτημένη από το υπόλοιπο σύστημα, καθιστώντας ευκολότερη την επαναχρησιμοποίηση σε άλλο λογισμικό.

Περίληψη

Ξεκινήσαμε εισάγοντας μερικούς βασικούς τύπους αντικειμένων υψηλού επιπέδου (οντότητα, όριο και έλεγχος).

Στη συνέχεια μάθαμε βασικές αρχές στη δομή των εν λόγω αντικειμένων (Αφαίρεση, Γενίκευση, Σύνθεση, Αποσύνθεση και Ενκαψουλίωση).

Για να συνεχίσουμε, παρουσιάσαμε δύο μετρήσεις ποιότητας λογισμικού (Σύζευξη και Συνοχή) και μάθαμε για τα οφέλη από την εφαρμογή των εν λόγω αρχών.

Ελπίζω ότι αυτό το άρθρο παρείχε μια χρήσιμη επισκόπηση ορισμένων αρχών σχεδιασμού. Εάν θέλετε να εκπαιδεύσετε περαιτέρω τον εαυτό σας σε αυτόν τον τομέα, ακολουθούν ορισμένοι πόροι που θα συνιστούσα.

Περαιτέρω αναγνώσεις

Σχέδια προτύπων: Στοιχεία επαναχρησιμοποιήσιμου αντικειμενοστρεφούς λογισμικού - Αναμφισβήτητα το πιο σημαντικό βιβλίο στον τομέα. Λίγο χρονολογημένο στα παραδείγματα (C ++ 98), αλλά τα σχέδια και οι ιδέες παραμένουν πολύ σχετικά.

Αυξανόμενο Αντικειμενοστρεφό Λογισμικό Καθοδηγούμενο από Δοκιμές - Ένα εξαιρετικό βιβλίο που δείχνει πώς να εφαρμόζουμε πρακτικά τις αρχές που περιγράφονται σε αυτό το άρθρο (και πολλά άλλα) με την εργασία μέσω ενός έργου.

Αποτελεσματική σχεδίαση λογισμικού - Ένα κορυφαίο ιστολόγιο που περιέχει πολύ περισσότερα από τις ιδέες σχεδιασμού.

Σχεδιασμός λογισμικού και εξειδίκευση αρχιτεκτονικής - Μια μεγάλη σειρά από 4 μαθήματα βίντεο που σας διδάσκουν αποτελεσματικό σχεδιασμό σε όλη την εφαρμογή του σε ένα έργο που καλύπτει και τα τέσσερα μαθήματα.

Εάν αυτή η επισκόπηση ήταν ενημερωτική για εσάς, σκεφτείτε το ενδεχόμενο να του δώσετε το ποσό των χειροκροτημάτων που νομίζετε ότι αξίζει, έτσι ώστε περισσότεροι άνθρωποι μπορούν να το σκοντάψουν και να κερδίσουν αξία από αυτό.