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

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

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

99 μικρά σφάλματα στον κώδικα. 99 μικρά λάθη. Πάρτε ένα, βάλτε ένα μπάλωμα,

… 127 μικρά σφάλματα στον κώδικα.

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

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

Λόγοι για τους οποίους η ανάπτυξη λογισμικού επιβραδύνεται με την πάροδο του χρόνου

Λοιπόν, ποιος είναι ο λόγος για αυτό το πρόβλημα;

Η κύρια αιτία είναι η αυξανόμενη πολυπλοκότητα. Από την εμπειρία μου, ο μεγαλύτερος συντελεστής στη συνολική πολυπλοκότητα είναι το γεγονός ότι, στη συντριπτική πλειονότητα των έργων λογισμικού, όλα συνδέονται. Λόγω των εξαρτήσεων που έχει κάθε τάξη, εάν αλλάξετε κάποιο κωδικό στην τάξη που στέλνει email, οι χρήστες σας ξαφνικά δεν μπορούν να εγγραφούν. Γιατί αυτό? Επειδή ο κωδικός εγγραφής σας εξαρτάται από τον κωδικό που στέλνει τα email. Τώρα δεν μπορείτε να αλλάξετε τίποτα χωρίς να εισαγάγετε λάθη. Απλώς δεν είναι δυνατό να εντοπιστούν όλες οι εξαρτήσεις.

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

Το Big Mud Ball και πώς να το μειώσετε

Το αστείο είναι ότι αυτό το πρόβλημα είναι γνωστό εδώ και χρόνια. Είναι ένα κοινό αντιπτέρνα που ονομάζεται «μεγάλη μπάλα από πηλό». Έχω δει αυτό το είδος αρχιτεκτονικής σε σχεδόν κάθε έργο που έχω εργαστεί εδώ και χρόνια σε πολλές διαφορετικές εταιρείες.

Λοιπόν, τι ακριβώς είναι αυτό το antipattern; Με απλά λόγια, παίρνετε μια μεγάλη μπάλα από πηλό όταν κάθε αντικείμενο έχει εξάρτηση από άλλα αντικείμενα. Παρακάτω μπορείτε να δείτε ένα γράφημα των εξαρτήσεων του δημοφιλούς έργου Apache Hadoop ανοιχτού κώδικα. Για να απεικονίσετε τη μεγάλη μπάλα από πηλό (ή μάλλον τη μεγάλη μπάλα του νήματος), σχεδιάστε έναν κύκλο και τοποθετήστε τις τάξεις του έργου ομοιόμορφα σε αυτό. Απλώς σχεδιάστε μια γραμμή μεταξύ κάθε ζεύγους τάξεων που εξαρτώνται το ένα από το άλλο. Τώρα μπορείτε να δείτε την πηγή των προβλημάτων σας.

τι είναι ένα bot σε διαφωνία

Η «μεγάλη μπάλα της λάσπης» του Apache Hadoop

Λύση αρθρωτού κώδικα

Γι 'αυτό έθεσα στον εαυτό μου μια ερώτηση: θα ήταν δυνατόν να μειωθεί η πολυπλοκότητα και να διασκεδάσω όπως στην αρχή του έργου; Αλήθεια, δεν μπορείτε να διαγράψετε όλοι την πολυπλοκότητα. Εάν θέλετε να προσθέσετε νέες δυνατότητες, θα πρέπει πάντα να αυξάνετε την πολυπλοκότητα του κώδικα σας. Ωστόσο, η πολυπλοκότητα μπορεί να μετακινηθεί και να εξαπλωθεί.

Πώς άλλοι κλάδοι λύνουν αυτό το πρόβλημα

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

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

Μπορούμε να το επαναλάβουμε στη βιομηχανία λογισμικού;

Σίγουρα μπορούμε! Χρησιμοποιώντας διεπαφές και αντιστρέφοντας την αρχή ελέγχου. το καλύτερο μέρος είναι το γεγονός ότι αυτή η προσέγγιση μπορεί να χρησιμοποιηθεί σε οποιαδήποτε αντικειμενοστραφή γλώσσα: Java, C #, Swift, TypeScript, JavaScript, PHP - η λίστα συνεχίζεται και συνεχίζεται. Δεν χρειάζεστε φανταχτερό πλαίσιο για να εφαρμόσετε αυτήν τη μέθοδο. Πρέπει απλώς να ακολουθήσετε μερικούς απλούς κανόνες και να παραμείνετε πειθαρχημένοι.

Το Inversion of Control είναι ο φίλος σας

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

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

θέμα

Ας υποθέσουμε ότι έχουμε μια πολύ απλή εφαρμογή που αποτελείται από μία μόνο κλάση Main, τρεις υπηρεσίες και μία κατηγορία Util. Αυτά τα στοιχεία εξαρτώνται το ένα από το άλλο με πολλούς τρόπους. Παρακάτω μπορείτε να δείτε μια εφαρμογή χρησιμοποιώντας την προσέγγιση 'big ball of mud'. Τα μαθήματα καλούν το ένα το άλλο. Είναι στενά συνδεδεμένα και δεν μπορείτε απλώς να τραβήξετε ένα στοιχείο χωρίς να αγγίξετε τα άλλα. Οι εφαρμογές που δημιουργούνται σε αυτό το στυλ σας επιτρέπουν να αναπτύξετε αρχικά γρήγορα. Νομίζω ότι αυτό το στυλ είναι κατάλληλο για έργα δοκιμαστικής έννοιας, καθώς μπορείτε να παίζετε με ευκολία. Ωστόσο, δεν είναι κατάλληλο για έτοιμες για παραγωγή λύσεις, διότι ακόμη και η συντήρηση μπορεί να είναι επικίνδυνη και οποιαδήποτε αλλαγή μπορεί να δημιουργήσει απρόβλεπτα σφάλματα. Το παρακάτω διάγραμμα δείχνει αυτή τη μεγάλη αρχιτεκτονική από πηλό.

Γιατί η εξάρτηση από έγχυση το έκανε λάθος;

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

Η μόνη διαφορά μεταξύ της τρέχουσας κατάστασης και μιας μεγάλης μπάλας λάσπης είναι το γεγονός ότι τώρα, αντί να καλούμε τάξεις απευθείας, τα καλούμε μέσω των διεπαφών τους. Βελτιώνει ελαφρώς τα στοιχεία διαχωρισμού μεταξύ τους. Εάν, για παράδειγμα, θέλετε να επαναχρησιμοποιήσετε Servicio A Σε ένα διαφορετικό έργο, μπορείτε να το κάνετε κάνοντας λήψη Servicio A, μαζί με Interfaz A, καθώς και Interfaz B και Interface Útil. Όπως μπορείτε να δείτε, το Servicio A Εξαρτάται ακόμη από άλλα στοιχεία. Ως αποτέλεσμα, εξακολουθούμε να έχουμε πρόβλημα να αλλάξουμε τον κώδικα σε ένα μέρος και να βλάψουμε τη συμπεριφορά σε άλλο. Δημιουργεί ακόμα το πρόβλημα ότι εάν τροποποιήσετε Servicio B e Interfaz B, θα πρέπει να αλλάξετε όλα τα στοιχεία που εξαρτώνται από αυτό. Αυτή η προσέγγιση δεν λύνει τίποτα. κατά τη γνώμη μου προσθέτει απλώς ένα επίπεδο διεπαφής πάνω από τα στοιχεία. Δεν πρέπει ποτέ να κάνετε ένεση εξαρτήσεων, αλλά μάλλον να τα απαλλαγείτε μια για πάντα. Ώρα για ανεξαρτησία!

Η λύση για τον αρθρωτό κώδικα

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

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

Οι υπηρεσίες, από την άλλη πλευρά, είναι εντελώς ανεξάρτητα στοιχεία. Τώρα, μπορείτε να αφαιρέσετε κάθε υπηρεσία από αυτήν την εφαρμογή και να την χρησιμοποιήσετε ξανά αλλού. Δεν εξαρτώνται από οτιδήποτε άλλο. Αλλά περιμένετε, γίνεται καλύτερο: δεν χρειάζεται πλέον να τροποποιήσετε αυτές τις υπηρεσίες, αρκεί να μην αλλάξετε τη συμπεριφορά τους. Εφόσον αυτές οι υπηρεσίες κάνουν αυτό που πρέπει να κάνουν, μπορούν να παραμείνουν άθικτα μέχρι το τέλος του χρόνου. Μπορούν να δημιουργηθούν από ένα επαγγελματίας μηχανικός λογισμικού , ή ένας κωδικοποιητής για πρώτη φορά που έχει δεσμευτεί για τον χειρότερο κώδικα σπαγγέτι που έχει δημιουργήσει ποτέ κάποιος με δηλώσεις goto μικτός. Δεν έχει σημασία, γιατί η λογική σας είναι ενθυλακωμένη. Όσο φρικτό είναι, ποτέ δεν θα εξαπλωθεί σε άλλες τάξεις. Αυτό σας δίνει επίσης τη δυνατότητα να διαιρέσετε την εργασία σε ένα έργο μεταξύ πολλών προγραμματιστών, όπου κάθε προγραμματιστής μπορεί να εργαστεί στο δικό του στοιχείο ανεξάρτητα χωρίς να χρειάζεται να διακόψετε κάποιον άλλο ή ακόμη και να μάθετε για άλλους προγραμματιστές.

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

Στοιχείο

Ας καθορίσουμε το μοτίβο του δομικού στοιχείου ώστε να μπορούμε να το δημιουργήσουμε επαναλαμβανόμενα.

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

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

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

Ας ρίξουμε μια ματιά σε ένα απλό παράδειγμα του 'Hello World' που δημιουργήθηκε στην Java.

public class Main { interface ElementListener { void printOutput(String message); } static class Element { private ElementListener listener; public Element(ElementListener listener) { this.listener = listener; } public void sayHello() { String message = 'Hello World of Elements!'; this.listener.printOutput(message); } } static class App { public App() { } public void start() { // Build listener ElementListener elementListener = message -> System.out.println(message); // Assemble element Element element = new Element(elementListener); element.sayHello(); } } public static void main(String[] args) { App app = new App(); app.start(); } }

Αρχικά, ορίζουμε ElementListener για να καθορίσετε τη μέθοδο που εκτυπώνει την έξοδο. Το ίδιο το στοιχείο ορίζεται παρακάτω. Κλήση sayHello στο στοιχείο, απλώς εκτυπώστε ένα μήνυμα χρησιμοποιώντας το ElementListener. Σημειώστε ότι το στοιχείο είναι εντελώς ανεξάρτητο από την εφαρμογή της μεθόδου printOutput Μπορεί να εκτυπωθεί στην κονσόλα, σε έναν φυσικό εκτυπωτή ή σε μια φανταστική διεπαφή χρήστη. Το στοιχείο δεν εξαρτάται από αυτήν την εφαρμογή. Λόγω αυτής της αφαίρεσης, αυτό το στοιχείο μπορεί εύκολα να επαναχρησιμοποιηθεί σε διαφορετικές εφαρμογές.

Τώρα ρίξτε μια ματιά στην κύρια κατηγορία App. Εφαρμόστε τον ακροατή και συναρμολογήστε το στοιχείο μαζί με τη συγκεκριμένη εφαρμογή. Τώρα μπορούμε να αρχίσουμε να το χρησιμοποιούμε.

Μπορείτε επίσης να εκτελέσετε αυτό το παράδειγμα σε JavaScript εδώ

Αρχιτεκτονική στοιχείων

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

Η δομή μιας εφαρμογής ιστού πλήρους στοίβας που μου αρέσει να μοιάζει με αυτήν:

src ├── client │ ├── app │ └── elements │ └── server ├── app └── elements

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

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

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

Πρακτικά παραδείγματα

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

Παραδείγματα πραγματικής ζωής

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

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

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

Αναπτύξτε ταχύτερα, επαναχρησιμοποιήστε πιο συχνά!

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

• Πολλά προβλήματα παρουσιάζονται στο λογισμικό λόγω εξαρτήσεων μεταξύ διαφόρων στοιχείων.

• Κάνοντας μια αλλαγή σε ένα μέρος, μπορείτε να εισαγάγετε απρόβλεπτη συμπεριφορά σε άλλο μέρος.

Οι τρεις κοινές αρχιτεκτονικές προσεγγίσεις είναι:

• Η μεγάλη μπάλα από πηλό. Είναι εξαιρετικό για ταχεία ανάπτυξη, αλλά όχι τόσο καλό για σταθερούς παραγωγικούς σκοπούς.

• Ενεση εξάρτησης. Είναι μια μισή λύση που πρέπει να αποφύγετε.

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

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

Για να επιτευχθεί μια πλήρης αρχιτεκτονική στοιχείων στοίβας, το front-end διαχωρίζεται πρώτα από τον κώδικα back-end. Στη συνέχεια, δημιουργήστε ένα φάκελο σε κάθε έναν για μια εφαρμογή και στοιχεία. Ο φάκελος στοιχείων αποτελείται από όλα τα αυτόνομα στοιχεία, ενώ ο φάκελος εφαρμογών συνδέει τα πάντα μαζί.

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

Επίσης, εάν βρεθείτε να βελτιστοποιείτε πρόωρα τον κωδικό σας, διαβάστε _ Πώς να αποφύγετε την κατάρα της πρόωρης βελτιστοποίησης_ από τον συνεργάτη μου στο ApeeScape, Kevin Bloch.