Αρχή Ενιαίας Ευθύνης. Όχι τόσο απλό όσο φαίνεται

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

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

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

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

Ορισμός 1. Ενιαία ευθύνη.

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

Σκεφτείτε το αντικείμενο "Drinker" (Μπέκρος).
Για να εφαρμόσουμε την αρχή SRP, θα χωρίσουμε τις αρμοδιότητες σε τρεις:

• Ένα χύνει (PourOperation)
• Ένας πίνει (DrinkUpOperation)
• Ο ένας έχει ένα σνακ (TakeBiteOperation)

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

Η τρύπα πόσης, με τη σειρά της, είναι μια πρόσοψη για αυτές τις λειτουργίες:

сlass Tippler {
    //...
    void Act(){
        _pourOperation.Do() // налить
        _drinkUpOperation.Do() // выпить
        _takeBiteOperation.Do() // закусить
    }
}

Γιατί;

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

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

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

Τώρα, Το SRP είναι μια αρχή που εξηγεί ΠΩΣ να αποσυντεθεί, δηλαδή πού να τραβήξετε τη διαχωριστική γραμμή.

Λέει ότι είναι απαραίτητο να αποσυντεθεί σύμφωνα με την αρχή της κατανομής της «ευθύνης», δηλαδή σύμφωνα με τα καθήκοντα ορισμένων αντικειμένων.

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

• Ο κώδικας έχει γίνει εξαιρετικά σαφής σε κάθε επίπεδο
• Ο κώδικας μπορεί να γραφτεί από πολλούς προγραμματιστές ταυτόχρονα (ο καθένας γράφει ένα ξεχωριστό στοιχείο)
• Οι αυτοματοποιημένες δοκιμές απλοποιούνται - όσο πιο απλό είναι το στοιχείο, τόσο πιο εύκολο είναι να δοκιμαστεί
• Εμφανίζεται η συνθετικότητα του κώδικα - μπορείτε να αντικαταστήσετε DrinkUpOperation σε μια επέμβαση κατά την οποία ένας μεθυσμένος ρίχνει υγρό κάτω από το τραπέζι. Ή αντικαταστήστε τη διαδικασία έκχυσης με μια λειτουργία κατά την οποία αναμιγνύετε κρασί και νερό ή βότκα και μπύρα. Ανάλογα με τις επιχειρηματικές απαιτήσεις, μπορείτε να κάνετε τα πάντα χωρίς να αγγίξετε τον κωδικό της μεθόδου Tippler.Act.
• Από αυτές τις λειτουργίες μπορείτε να διπλώσετε τον λαίμαργο (μόνο χρησιμοποιώντας TakeBitOperation), Αλκοολούχο (με χρήση μόνο DrinkUpOperation κατευθείαν από το μπουκάλι) και πληρούν πολλές άλλες επιχειρηματικές απαιτήσεις.

(Ω, φαίνεται ότι αυτή είναι ήδη μια αρχή OCP και παραβίασα την ευθύνη αυτής της ανάρτησης)

Και φυσικά τα μειονεκτήματα:

• Θα πρέπει να δημιουργήσουμε περισσότερους τύπους.
• Ένας μεθυσμένος πίνει για πρώτη φορά μερικές ώρες αργότερα από ό,τι θα έπινε.

Ορισμός 2. Ενοποιημένη μεταβλητότητα.

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

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

Το δεύτερο είναι γραμμένο μέσω της μεθοδολογίας «Forward and Only Forward» και περιέχει όλη τη λογική της μεθόδου Πράξη:

//Не тратьте время  на изучение этого класса. Лучше съешьте печеньку
сlass BrutTippler {
   //...
   void Act(){
        // наливаем
    if(!_hand.TryDischarge(from:_bottle, to:_glass, size:_glass.Capacity))
        throw new OverdrunkException();

    // выпиваем
    if(!_hand.TryDrink(from: _glass,  size: _glass.Capacity))
        throw new OverdrunkException();

    //Закусываем
    for(int i = 0; i< 3; i++){
        var food = _foodStore.TakeOrDefault();
        if(food==null)
            throw new FoodIsOverException();

        _hand.TryEat(food);
    }
   }
}

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

Σύγχυση!

Στη συνέχεια, μπαίνουμε στο διαδίκτυο και ανακαλύπτουμε έναν άλλο ορισμό του SRP - την Αρχή της Ενιαίας Μεταβλητότητας.

Το SCP αναφέρει ότι "Μια ενότητα έχει έναν και μόνο λόγο να αλλάξει". Δηλαδή, «Η ευθύνη είναι λόγος αλλαγής».

(Φαίνεται ότι τα παιδιά που κατέληξαν στον αρχικό ορισμό ήταν σίγουροι για τις τηλεπαθητικές ικανότητες του ανθρώπου-πίθηκο)

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

Στην προσέγγιση «Εμπρός και μόνο προς τα εμπρός», όλα όσα μπορούν να αλλάξουν αλλάζουν μόνο στη μέθοδο Πράξη. Αυτό μπορεί να είναι ευανάγνωστο και αποτελεσματικό όταν υπάρχει λίγη λογική και σπάνια αλλάζει, αλλά συχνά καταλήγει σε τρομερές μεθόδους των 500 γραμμών η καθεμία, με περισσότερες δηλώσεις αν από αυτές που απαιτούνται για την ένταξη της Ρωσίας στο ΝΑΤΟ.

Ορισμός 3. Εντοπισμός αλλαγών.

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

Ας ξεκινήσουμε την καταγραφή με τη διαδικασία έκχυσης:

class PourOperation: IOperation{
    PourOperation(ILogger log /*....*/){/*...*/}
    //...
    void Do(){
        _log.Log($"Before pour with {_hand} and {_bottle}");
        //Pour business logic ...
        _log.Log($"After pour with {_hand} and {_bottle}");
    }
}

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

interface IPourLogger{
    void LogBefore(IHand, IBottle){}
    void LogAfter(IHand, IBottle){}
    void OnError(IHand, IBottle, Exception){}
}

class PourOperation: IOperation{
    PourOperation(IPourLogger log /*....*/){/*...*/}
    //...
    void Do(){
        _log.LogBefore(_hand, _bottle);
        try{
             //... business logic
             _log.LogAfter(_hand, _bottle");
        }
        catch(exception e){
            _log.OnError(_hand, _bottle, e)
        }
    }
}

Ο σχολαστικός αναγνώστης θα το παρατηρήσει LogAfter, Σύνδεση Πριν и Σφάλμα μπορεί επίσης να αλλάξει μεμονωμένα και, κατ' αναλογία με τα προηγούμενα βήματα, θα δημιουργήσει τρεις κλάσεις: PourLoggerBefore, PourLoggerAfter и PourErrorLogger.

Και θυμόμαστε ότι υπάρχουν τρεις επεμβάσεις για έναν πότη, παίρνουμε εννέα μαθήματα υλοτομίας. Ως αποτέλεσμα, ολόκληρος ο κύκλος του ποτού αποτελείται από 14 (!!!) τάξεις.

Υπερβολή? Μετά βίας! Ένας άντρας-πίθηκος με μια χειροβομβίδα αποσύνθεσης θα χωρίσει τον «χύστη» σε μια καράφα, ένα ποτήρι, χειριστές έκχυσης, μια υπηρεσία παροχής νερού, ένα φυσικό μοντέλο σύγκρουσης μορίων και για το επόμενο τρίμηνο θα προσπαθήσει να ξεμπερδέψει τις εξαρτήσεις χωρίς καθολικές μεταβλητές. Και πιστέψτε με, δεν θα σταματήσει.

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

... χωρίς ποτέ να μάθουμε για την ύπαρξη ενός τρίτου ορισμού του Srp:

«Η Αρχή της Ενιαίας Ευθύνης αναφέρει ότι πράγματα που μοιάζουν με αλλαγή θα πρέπει να αποθηκεύονται σε ένα μέρος". ή "Ό,τι αλλάζει μαζί πρέπει να φυλάσσεται σε ένα μέρος"

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

Αυτό είναι ένα πολύ σημαντικό σημείο - δεδομένου ότι όλες οι εξηγήσεις του SRP που προαναφέρθηκαν έλεγαν ότι ήταν απαραίτητο να συνθλίβονται οι τύποι ενώ συνθλίβονταν, δηλαδή επέβαλαν ένα "ανώτατο όριο" στο μέγεθος του αντικειμένου και τώρα Μιλάμε ήδη για «κατώτερο όριο». Με άλλα λόγια, Το SRP όχι μόνο απαιτεί "θρυμματισμό κατά τη σύνθλιψη", αλλά και να μην το παρακάνετε - "μην συνθλίβετε τα αλληλένδετα πράγματα". Αυτή είναι η μεγάλη μάχη ανάμεσα στο ξυράφι του Occam και τον άνθρωπο πίθηκο!

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

class OperationLogger{
    public OperationLogger(string operationName){/*..*/}
    public void LogBefore(object[] args){/*...*/}       
    public void LogAfter(object[] args){/*..*/}
    public void LogError(object[] args, exception e){/*..*/}
}

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

Ως αποτέλεσμα, έχουμε 5 τάξεις για την επίλυση του προβλήματος του ποτού:

• Λειτουργία έκχυσης
• Λειτουργία πόσης
• Λειτουργία εμπλοκής
• Κόπτων δέντρα διά ξυλείαν
• Πρόσοψη ποτών

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

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

Κάποτε γράψαμε μια υπηρεσία για αυτόματη εγγραφή ενός πελάτη b2b. Και μια μέθοδος ΘΕΟΣ εμφανίστηκε για 200 γραμμές παρόμοιου περιεχομένου:

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

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

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

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

Φορμαλισμός.

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

Φορμαλισμός 1. Ορισμός SRP

1. Διαχωρίστε τα στοιχεία έτσι ώστε καθένα από αυτά να είναι υπεύθυνο για ένα πράγμα.
2. Η ευθύνη σημαίνει «λόγος για αλλαγή». Δηλαδή, κάθε στοιχείο έχει μόνο έναν λόγο αλλαγής, όσον αφορά την επιχειρηματική λογική.
3. Πιθανές αλλαγές στην επιχειρηματική λογική. πρέπει να εντοπιστεί. Τα στοιχεία που αλλάζουν συγχρονισμένα πρέπει να βρίσκονται κοντά.

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

Δεν έχω δει επαρκή κριτήρια για την εκπλήρωση του SRP. Υπάρχουν όμως απαραίτητες προϋποθέσεις:

1) Αναρωτηθείτε τι κάνει αυτή η τάξη/μέθοδος/ενότητα/υπηρεσία. πρέπει να απαντήσετε με έναν απλό ορισμό. ( Ευχαριστώ Brightori )

εξηγήσεις

Ωστόσο, μερικές φορές είναι πολύ δύσκολο να βρεθεί ένας απλός ορισμός

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

εξηγήσεις

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

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

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

εξηγήσεις

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

4) Όταν σας τίθεται μια διευκρινιστική ερώτηση σχετικά με την επιχειρηματική λογική (από έναν προγραμματιστή ή διαχειριστή), πηγαίνετε αυστηρά σε μια κατηγορία/αρχείο και λαμβάνετε πληροφορίες μόνο από εκεί.

εξηγήσεις

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

5) Η ονομασία είναι ξεκάθαρη.

εξηγήσεις

Η τάξη ή η μέθοδός μας είναι υπεύθυνη για ένα πράγμα και η ευθύνη αντικατοπτρίζεται στο όνομά της

AllManagersManagerService - πιθανότατα μια τάξη Θεού
LocalPayment - μάλλον όχι

Φορμαλισμός 3. Μεθοδολογία ανάπτυξης πρώτου Occam.

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

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

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

Ήρθε η ώρα να το ονομάσουμε μια μέρα

Το πεδίο εφαρμογής του SRP δεν περιορίζεται στο OOP και το SOLID. Εφαρμόζεται σε μεθόδους, συναρτήσεις, κλάσεις, ενότητες, μικροϋπηρεσίες και υπηρεσίες. Ισχύει τόσο για την ανάπτυξη «figax-figax-and-prod» όσο και για την ανάπτυξη «rocket-science», κάνοντας τον κόσμο λίγο καλύτερο παντού. Αν το καλοσκεφτείτε, αυτή είναι σχεδόν η θεμελιώδης αρχή όλης της μηχανικής. Η μηχανολογία, τα συστήματα ελέγχου, και μάλιστα όλα τα πολύπλοκα συστήματα κατασκευάζονται από εξαρτήματα, και ο «υποκατακερματισμός» στερεί από τους σχεδιαστές την ευελιξία, ο «υπερκατακερματισμός» στερεί από τους σχεδιαστές την αποτελεσματικότητα και τα λανθασμένα όρια τους στερεί τη λογική και την ηρεμία.

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

Πηγή: www.habr.com