עיקרון אחריות יחידה. לא פשוט כמו שזה נראה

עקרון אחריות יחידה, הידוע גם כעקרון האחריות היחידה,
העיקרון של שונות אחידה - בחור חלקלק ביותר להבנה ושאלה כל כך עצבנית בראיון מתכנת.

ההיכרות הרצינית הראשונה שלי עם העיקרון הזה התרחשה בתחילת השנה הראשונה, כשהצעירים והירוקים נלקחו ליער כדי להפוך תלמידים מהזחלים - תלמידים אמיתיים.

ביער התחלקנו לקבוצות של 8-9 אנשים כל אחת והיתה לנו תחרות - איזו קבוצה תשתה בקבוק וודקה הכי מהר, בתנאי שהראשון מהקבוצה מוזג וודקה לכוס, השני שותה אותה, ולשלישי יש חטיף. היחידה שסיימה את פעולתה עוברת לסוף התור של הקבוצה.

המקרה שבו גודל התור היה כפולה של שלוש היה יישום טוב של SRP.

הגדרה 1. אחריות יחידה.

ההגדרה הרשמית של עקרון האחריות היחידה (SRP) קובעת שלכל ישות יש אחריות משלה וסיבה לקיומו, ויש לה אחריות אחת בלבד.

שקול את האובייקט "שתיה" (טיפלר).
כדי ליישם את עקרון SRP, נחלק את האחריות לשלושה:

• אחד מוזג (PourOperation)
• אחד שותה (DrinkUpOperation)
• לאחד יש חטיף (TakeBiteOperation)

כל אחד מהמשתתפים בתהליך אחראי על מרכיב אחד בתהליך, כלומר יש לו אחריות אטומית אחת – לשתות, למזוג או לנשנש.

חור השתייה, בתורו, הוא חזית לפעולות אלה:

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

למה?

המתכנת האנושי כותב קוד לקוף-אדם, והקוף-אדם לא קשוב, טיפש ותמיד ממהר. הוא יכול להחזיק ולהבין בערך 3 - 7 מונחים בבת אחת.
במקרה של שיכור, ישנם שלושה מהמונחים הללו. עם זאת, אם נכתוב את הקוד עם גיליון אחד, אז הוא יכיל ידיים, משקפיים, מריבות ואינסופיות של ויכוחים על פוליטיקה. וכל זה יהיה בגופה של שיטה אחת. אני בטוח שראית קוד כזה באימון שלך. לא המבחן הכי אנושי לנפש.

מצד שני, איש הקוף נועד לדמות אובייקטים מהעולם האמיתי בראשו. בדמיונו הוא יכול לדחוף אותם זה לזה, להרכיב מהם חפצים חדשים ולפרק אותם באותו אופן. דמיינו לעצמכם מכונית מדגם ישן. בדמיונכם תוכלו לפתוח את הדלת, לפרק את עיפון הדלת ולראות שם את מנגנוני הרמת החלונות שבתוכם יהיו גלגלי שיניים. אבל אתה לא יכול לראות את כל רכיבי המכונה בו-זמנית, ב"רשימה" אחת. לפחות "איש הקופים" לא יכול.

לכן, מתכנתים אנושיים מפרקים מנגנונים מורכבים לקבוצה של אלמנטים פחות מורכבים ועובדים. עם זאת, ניתן לפרק אותו בדרכים שונות: במכוניות ישנות רבות צינור האוויר נכנס לדלת, ובמכוניות מודרניות כשל באלקטרוניקה של המנעול מונע את התנעת המנוע, מה שיכול להוות בעיה במהלך תיקונים.

עכשיו, SRP הוא עיקרון שמסביר כיצד לפרק, כלומר היכן למתוח את הקו המפריד.

לדבריו, יש צורך לפרק לפי עקרון חלוקת ה"אחריות", כלומר לפי משימות של אובייקטים מסוימים.

נחזור לשתייה וליתרונות שמקבל איש הקופים במהלך הפירוק:

• הקוד הפך להיות ברור ביותר בכל רמה
• הקוד יכול להיכתב על ידי מספר מתכנתים בו זמנית (כל אחד כותב אלמנט נפרד)
• בדיקה אוטומטית פשוטה יותר - ככל שהאלמנט פשוט יותר, כך קל יותר לבדוק אותו
• הקומפוזיציה של הקוד מופיעה - ניתן להחליף DrinkUpOperation לניתוח בו שיכור שופך נוזל מתחת לשולחן. או להחליף את פעולת המזיגה בפעולה שבה מערבבים יין ומים או וודקה ובירה. בהתאם לדרישות העסקיות, אתה יכול לעשות הכל מבלי לגעת בקוד השיטה Tippler.Act.
• מפעולות אלו ניתן לקפל את הגרגרן (באמצעות רק TakeBitOperation), אלכוהולי (בשימוש בלבד DrinkUpOperation ישר מהבקבוק) ועומדים בדרישות עסקיות רבות אחרות.

(הו, נראה שזה כבר עיקרון OCP, והפרתי את האחריות של הפוסט הזה)

וכמובן, החסרונות:

• נצטרך ליצור עוד סוגים.
• שיכור שותה בפעם הראשונה כמה שעות מאוחר יותר ממה שאם לא כן.

הגדרה 2. שונות מאוחדת.

הרשו לי, רבותי! גם לשיעור השתייה יש אחריות אחת - הוא שותה! ובכלל, המילה "אחריות" היא מושג מעורפל ביותר. מישהו אחראי לגורל האנושות, ומישהו אחראי לגידול הפינגווינים שהתהפכו בקוטב.

הבה נשקול שני יישומים של המשקה. הראשון, שהוזכר לעיל, מכיל שלוש כיתות - למזוג, לשתות ולנשנש.

השני נכתב באמצעות מתודולוגיית "קדימה ורק קדימה" ומכיל את כל ההיגיון בשיטה לפעול:

//Не тратьте время  на изучение этого класса. Лучше съешьте печеньку
с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, LogBefore и OnError ניתן גם לשנות בנפרד, ובאנלוגיה לשלבים הקודמים, תיצור שלוש מחלקות: PourLoggerBefore, PourLoggerAfter и PourErrorLogger.

ולזכור שיש שלוש פעולות לשתיין, אנחנו מקבלים תשעה שיעורי עצים. כתוצאה מכך, כל מעגל השתייה מורכב מ-14 (!!!) שיעורים.

הִיפֵּרבּוֹלָה? בְּקוֹשִׁי! איש קוף עם רימון פירוק יפצל את ה"מזיגה" לקנקן, כוס, מפעילי מזיגה, שירות אספקת מים, מודל פיזי של התנגשות מולקולות, וברבעון הבא ינסה להתיר את התלות בלי משתנים גלובליים. ותאמין לי, הוא לא יפסיק.

בנקודה זו רבים מגיעים למסקנה ש-SRP הם אגדות מממלכות ורודות, והולכים לשחק נודלס...

... מבלי ללמוד אי פעם על קיומה של הגדרה שלישית של Srp:

"עקרון האחריות היחידה קובע זאת דברים שדומים לשינוי צריכים להיות מאוחסנים במקום אחד". או "את השינויים ביחד יש לשמור במקום אחד"

כלומר, אם נשנה רישום של פעולה, אז עלינו לשנות אותה במקום אחד.

זו נקודה מאוד חשובה - שכן כל ההסברים של SRP שהיו לעיל אמרו שצריך לרסק את הסוגים בזמן ריסוקם, כלומר הטילו "גבול עליון" לגודל החפץ, ועכשיו אנחנו כבר מדברים על "גבול תחתון". במילים אחרות, SRP לא רק דורש "ריסוק תוך כדי ריסוק", אלא גם לא להגזים - "אל תמעוך דברים שלובים". זהו הקרב הגדול בין התער של אוקאם לאיש הקוף!

כעת השותה אמור להרגיש טוב יותר. בנוסף לעובדה שאין צורך לפצל את לוגר 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) שאלו את עצמכם מה עושה הכיתה/שיטה/מודול/שירות זה. אתה חייב לענות על זה בהגדרה פשוטה. ( תודה ברייטורי )

הסברים

עם זאת, לפעמים קשה מאוד למצוא הגדרה פשוטה

2) תיקון באג או הוספת תכונה חדשה משפיעים על מספר מינימלי של קבצים/מחלקות. באופן אידיאלי - אחד.

הסברים

מאחר שהאחריות (על תכונה או באג) מובלעת בקובץ/מחלקה אחת, אתה יודע בדיוק איפה לחפש ומה לערוך. לדוגמא: התכונה של שינוי הפלט של פעולות הרישום יחייבו לשנות רק את הלוגר. אין צורך לרוץ על שאר הקוד.

דוגמה נוספת היא הוספת בקרת ממשק משתמש חדשה, בדומה לקודמות. אם זה מאלץ אותך להוסיף 10 ישויות שונות ו-15 ממירים שונים, נראה שאתה מגזים.

3) אם מספר מפתחים עובדים על מאפיינים שונים של הפרויקט שלך, אזי הסבירות להתנגשות מיזוג, כלומר, הסבירות שאותו קובץ/מחלקה ישתנה על ידי מספר מפתחים בו זמנית, היא מינימלית.

הסברים

אם, בעת הוספת פעולה חדשה "לשפוך וודקה מתחת לשולחן", אתה צריך להשפיע על הכורת, על פעולת השתייה והמזיגה, אז נראה שהאחריות מחולקת בצורה עקומה. כמובן שזה לא תמיד אפשרי, אבל כדאי לנסות להפחית את הנתון הזה.

4) כששואלים אותך שאלת הבהרה לגבי היגיון עסקי (ממפתח או מנהל), אתה נכנס אך ורק לכיתה/קובץ אחד ומקבל מידע רק משם.

הסברים

תכונות, כללים או אלגוריתמים נכתבים בצורה קומפקטית, כל אחד במקום אחד, ואינם מפוזרים בדגלים במרחב הקוד.

5) השם ברור.

הסברים

הכיתה או השיטה שלנו אחראית לדבר אחד, והאחריות באה לידי ביטוי בשמה

AllManagersManagerService - ככל הנראה שיעור אלוהים
LocalPayment - כנראה שלא

פורמליזם 3. מתודולוגיית הפיתוח הראשונה של Occam.

בתחילת העיצוב, איש הקופים אינו יודע ואינו מרגיש את כל הדקויות של הבעיה נפתרות ויכול לטעות. אתה יכול לעשות טעויות בדרכים שונות:

• הפוך חפצים גדולים מדי על ידי מיזוג תחומי אחריות שונים
• מסגור מחדש על ידי חלוקת אחריות יחידה להרבה סוגים שונים
• הגדירו באופן שגוי את גבולות האחריות

חשוב לזכור את הכלל: "עדיף לעשות טעות גדולה", או "אם אתה לא בטוח, אל תפצל את זה". אם, למשל, הכיתה שלך מכילה שתי תחומי אחריות, אז זה עדיין מובן וניתן לפצל לשניים עם שינויים מינימליים בקוד הלקוח. הרכבת זכוכית מרסיסי זכוכית היא בדרך כלל קשה יותר בשל הפזרת ההקשר על פני מספר קבצים והיעדר התלות הכרחית בקוד הלקוח.

הגיע הזמן לקרוא לזה יום

היקף SRP אינו מוגבל ל- OOP ו- SOLID. זה חל על שיטות, פונקציות, מחלקות, מודולים, מיקרו-שירותים ושירותים. זה תקף גם לפיתוח "figax-figax-and-prod" וגם לפיתוח "רקטות-science", מה שהופך את העולם לקצת טוב יותר בכל מקום. אם אתה חושב על זה, זה כמעט העיקרון הבסיסי של כל הנדסה. הנדסת מכונות, מערכות בקרה, ואכן כל המערכות המורכבות בנויות ממרכיבים, ו"תת-פרגמנטציה" מונעת מהמעצבים גמישות, "פרגמנטציה יתר" מונעת מהמעצבים יעילות, וגבולות לא נכונים שוללים מהם שכל ושקט נפשי.

SRP אינו הומצא על ידי הטבע ואינו חלק מהמדע המדויק. זה פורץ מהמגבלות הביולוגיות והפסיכולוגיות שלנו, זו רק דרך לשלוט ולפתח מערכות מורכבות באמצעות מוח קוף-אדם. הוא אומר לנו איך לפרק מערכת. הניסוח המקורי דרש מידה לא מבוטלת של טלפתיה, אבל אני מקווה שהמאמר הזה מנקה חלק ממסך העשן.

מקור: www.habr.com