หลักการความรับผิดชอบเดียว ไม่ง่ายอย่างที่คิด

หลักการความรับผิดชอบเดี่ยวหรือที่เรียกว่าหลักการความรับผิดชอบเดี่ยว
หรือที่เรียกว่าหลักการของความแปรปรวนของเครื่องแบบ - ผู้ชายที่เข้าใจยากและลื่นไหลอย่างยิ่งและเป็นคำถามที่น่ากังวลในการสัมภาษณ์โปรแกรมเมอร์

ความคุ้นเคยอย่างจริงจังครั้งแรกของฉันกับหลักการนี้เกิดขึ้นเมื่อต้นปีแรกเมื่อเด็กและตัวเขียวถูกนำไปที่ป่าเพื่อสร้างนักเรียนจากตัวอ่อน - นักเรียนที่แท้จริง

ในป่าเราแบ่งออกเป็นกลุ่ม ๆ ละ 8-9 คนและมีการแข่งขัน - กลุ่มใดจะดื่มวอดก้าหนึ่งขวดเร็วที่สุดโดยมีเงื่อนไขว่าคนแรกจากกลุ่มเทวอดก้าลงในแก้วคนที่สองดื่มมัน และคนที่สามมีของว่าง หน่วยที่ดำเนินการเสร็จแล้วจะย้ายไปยังจุดสิ้นสุดของคิวของกลุ่ม

กรณีที่ขนาดคิวเป็นผลคูณของสามถือเป็นการนำ SRP ไปใช้ที่ดี

คำจำกัดความ 1. ความรับผิดชอบเดี่ยว

คำจำกัดความอย่างเป็นทางการของหลักการความรับผิดชอบเดี่ยว (SRP) ระบุว่าแต่ละหน่วยงานมีความรับผิดชอบและเหตุผลในการดำรงอยู่ของตนเอง และมีหน้าที่รับผิดชอบเพียงประการเดียวเท่านั้น

พิจารณาวัตถุ “นักดื่ม” (คนทิปเปิ้ล).
เพื่อนำหลักการ SRP ไปปฏิบัติ เราจะแบ่งความรับผิดชอบออกเป็นสามส่วน:

• หนึ่งเท (เทOperation)
• เครื่องดื่มหนึ่งแก้ว (DrinkUpOperation)
• หนึ่งมีของว่าง (TakeBiteOperation)

ผู้เข้าร่วมแต่ละคนในกระบวนการมีหน้าที่รับผิดชอบองค์ประกอบหนึ่งของกระบวนการ กล่าวคือ มีหน้าที่รับผิดชอบด้านอะตอมมิกเดียว นั่นคือ การดื่ม เท หรือของว่าง

หลุมดื่มในทางกลับกันเป็นส่วนหน้าสำหรับการดำเนินการเหล่านี้:

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

ทำไม?

โปรแกรมเมอร์ที่เป็นมนุษย์เขียนโค้ดให้กับมนุษย์วานร และมนุษย์วานรนั้นไม่ตั้งใจ โง่เขลา และมักจะรีบร้อนอยู่เสมอ เขาสามารถถือและเข้าใจได้ประมาณ 3 - 7 คำศัพท์ในคราวเดียว
ในกรณีของคนขี้เมามีสามคำนี้ อย่างไรก็ตาม ถ้าเราเขียนโค้ดในแผ่นเดียว มันก็จะมีทั้งมือ แก้ว การต่อสู้ และข้อโต้แย้งเกี่ยวกับการเมืองไม่รู้จบ และทั้งหมดนี้ก็จะอยู่ในเนื้อความของวิธีเดียว ฉันแน่ใจว่าคุณเคยเห็นรหัสดังกล่าวในการปฏิบัติของคุณ ไม่ใช่การทดสอบจิตใจอย่างมีมนุษยธรรมที่สุด

ในทางกลับกัน มนุษย์วานรได้รับการออกแบบมาเพื่อจำลองวัตถุในโลกแห่งความเป็นจริงในหัวของเขา ในจินตนาการของเขา เขาสามารถดันพวกมันเข้าด้วยกัน ประกอบวัตถุใหม่ๆ จากพวกมัน และแยกพวกมันออกด้วยวิธีเดียวกัน ลองนึกภาพรถรุ่นเก่า ในจินตนาการของคุณคุณสามารถเปิดประตูคลายเกลียวขอบประตูแล้วดูกลไกการยกหน้าต่างซึ่งภายในจะมีเกียร์อยู่ แต่คุณไม่สามารถมองเห็นส่วนประกอบทั้งหมดของเครื่องพร้อมกันได้ใน "รายการ" เดียว อย่างน้อย “มนุษย์ลิง” ก็ทำไม่ได้

ดังนั้นโปรแกรมเมอร์ที่เป็นมนุษย์จึงแยกกลไกที่ซับซ้อนออกเป็นชุดขององค์ประกอบการทำงานที่ซับซ้อนน้อยกว่า อย่างไรก็ตาม มันสามารถสลายตัวได้หลายวิธี: ในรถยนต์เก่าหลายคัน ท่ออากาศจะเข้าไปในประตู และในรถยนต์สมัยใหม่ ความล้มเหลวในระบบอิเล็กทรอนิกส์สำหรับล็อคจะทำให้เครื่องยนต์สตาร์ทไม่ได้ ซึ่งอาจเป็นปัญหาได้ในระหว่างการซ่อมแซม

ดังนั้นที่นี่ SRP เป็นหลักการที่อธิบายวิธีการสลายตัว กล่าวคือ จะต้องลากเส้นแบ่งไปที่ใด.

เขาบอกว่าจำเป็นต้องย่อยสลายตามหลักการแบ่ง “ความรับผิดชอบ” กล่าวคือ ตามภารกิจของวัตถุบางอย่าง

กลับมาดื่มและข้อดีที่มนุษย์ลิงได้รับระหว่างการสลายตัว:

• รหัสมีความชัดเจนอย่างมากในทุกระดับ
• โปรแกรมเมอร์หลายคนสามารถเขียนโค้ดได้พร้อมกัน (แต่ละคนเขียนองค์ประกอบแยกกัน)
• การทดสอบอัตโนมัตินั้นง่ายขึ้น - ยิ่งองค์ประกอบเรียบง่ายเท่าไรก็ยิ่งทดสอบได้ง่ายขึ้นเท่านั้น
• องค์ประกอบของโค้ดปรากฏขึ้น - คุณสามารถแทนที่ได้ DrinkUpOperation ไปสู่ปฏิบัติการที่คนขี้เมาเทของเหลวไว้ใต้โต๊ะ หรือแทนที่การเทด้วยการดำเนินการที่คุณผสมไวน์กับน้ำหรือวอดก้าและเบียร์ คุณสามารถทำทุกอย่างได้โดยไม่ต้องแตะรหัสวิธีการ ทั้งนี้ขึ้นอยู่กับข้อกำหนดทางธุรกิจ Tippler.พระราชบัญญัติ.
• จากการดำเนินการเหล่านี้ คุณสามารถพับคนตะกละได้ (ใช้เฉพาะ 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 บรรทัด โดยมีคำสั่ง if-state มากกว่าที่กำหนดไว้สำหรับรัสเซียในการเข้าร่วม NATO

คำจำกัดความ 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}");
    }
}

ด้วยการห่อหุ้มมันไว้ เทOperationเราดำเนินการอย่างชาญฉลาดจากมุมมองของความรับผิดชอบและการห่อหุ้ม แต่ตอนนี้เราสับสนกับหลักการของความแปรปรวน นอกเหนือจากการดำเนินการซึ่งสามารถเปลี่ยนแปลงได้ การบันทึกเองก็สามารถเปลี่ยนแปลงได้เช่นกัน คุณจะต้องแยกและสร้างเครื่องบันทึกพิเศษสำหรับการดำเนินการเท:

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)
        }
    }
}

ผู้อ่านที่พิถีพิถันจะสังเกตเห็นว่า เข้าสู่ระบบหลังจาก, เข้าสู่ระบบก่อน и หนึ่งข้อผิดพลาด สามารถเปลี่ยนแปลงได้เป็นรายบุคคล และโดยการเปรียบเทียบกับขั้นตอนก่อนหน้า จะสร้างคลาสขึ้นมาสามคลาส: 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 โดยอัตโนมัติ และวิธี GOD ก็ปรากฏขึ้นสำหรับเนื้อหาที่คล้ายกัน 200 บรรทัด:

• ไปที่ 1C และสร้างบัญชี
• ด้วยบัญชีนี้ ให้ไปที่โมดูลการชำระเงินและสร้างมันขึ้นมาที่นั่น
• ตรวจสอบว่าไม่ได้สร้างบัญชีด้วยบัญชีดังกล่าวบนเซิร์ฟเวอร์หลัก
• สร้างบัญชีใหม่
• เพิ่มผลการลงทะเบียนในโมดูลการชำระเงินและหมายเลข 1c ไปยังบริการผลการลงทะเบียน
• เพิ่มข้อมูลบัญชีลงในตารางนี้
• สร้างหมายเลขจุดสำหรับลูกค้ารายนี้ในบริการจุด ส่งหมายเลขบัญชี 1c ของคุณไปที่บริการนี้

และมีการดำเนินธุรกิจอีกประมาณ 10 รายการในรายการนี้ซึ่งมีการเชื่อมต่อที่แย่มาก เกือบทุกคนต้องการวัตถุบัญชี จำเป็นต้องใช้ point ID และชื่อไคลเอนต์ในครึ่งหนึ่งของการโทร

หลังจากปรับโครงสร้างใหม่เป็นเวลาหนึ่งชั่วโมง เราก็สามารถแยกโค้ดโครงสร้างพื้นฐานและความแตกต่างบางประการของการทำงานกับบัญชีออกเป็นวิธีการ/คลาสที่แยกจากกัน วิธี God ทำให้ง่ายขึ้น แต่ยังเหลือโค้ดอีก 100 บรรทัดที่ไม่ต้องการให้แยกออก

หลังจากนั้นไม่กี่วันก็ชัดเจนว่าแก่นแท้ของวิธีการ "น้ำหนักเบา" นี้คืออัลกอริธึมทางธุรกิจ และคำอธิบายดั้งเดิมของข้อกำหนดทางเทคนิคนั้นค่อนข้างซับซ้อน และมันเป็นความพยายามที่จะแยกวิธีนี้ออกเป็นชิ้น ๆ ที่จะละเมิด SRP และไม่ใช่ในทางกลับกัน

ลัทธินอกรีต

ถึงเวลาที่จะทิ้งความเมาของเราไว้ตามลำพัง เช็ดน้ำตาของคุณ - สักวันหนึ่งเราจะกลับไปอย่างแน่นอน ตอนนี้เรามาทำความเข้าใจความรู้จากบทความนี้กัน

รูปแบบนิยม 1. คำจำกัดความของ SRP

1. แยกองค์ประกอบเพื่อให้แต่ละคนรับผิดชอบสิ่งเดียว
2. ความรับผิดชอบหมายถึง "เหตุผลในการเปลี่ยนแปลง" นั่นคือแต่ละองค์ประกอบมีเหตุผลเดียวในการเปลี่ยนแปลงในแง่ของตรรกะทางธุรกิจ
3. การเปลี่ยนแปลงที่อาจเกิดขึ้นกับตรรกะทางธุรกิจ จะต้องเป็นภาษาท้องถิ่น องค์ประกอบที่เปลี่ยนแปลงพร้อมกันจะต้องอยู่ใกล้ๆ

รูปแบบนิยม 2. เกณฑ์การทดสอบตัวเองที่จำเป็น

ฉันไม่เห็นเกณฑ์ที่เพียงพอสำหรับการปฏิบัติตาม SRP แต่มีเงื่อนไขที่จำเป็น:

1) ถามตัวเองว่าคลาส/เมธอด/โมดูล/บริการนี้ทำอะไร คุณต้องตอบด้วยคำจำกัดความง่ายๆ ( ขอบคุณ ไบรโทริ )

คำอธิบาย

อย่างไรก็ตาม บางครั้งการหาคำจำกัดความง่ายๆ ก็เป็นเรื่องยากมาก

2) การแก้ไขข้อบกพร่องหรือการเพิ่มฟีเจอร์ใหม่จะส่งผลต่อจำนวนไฟล์/คลาสขั้นต่ำ ตามหลักการแล้ว - หนึ่ง

คำอธิบาย

เนื่องจากความรับผิดชอบ (สำหรับฟีเจอร์หรือข้อบกพร่อง) ถูกรวมไว้ในไฟล์/คลาสเดียว คุณจึงรู้ได้อย่างชัดเจนว่าจะต้องดูที่ไหนและต้องแก้ไขอะไร ตัวอย่างเช่น: คุณสมบัติในการเปลี่ยนเอาต์พุตของการดำเนินการบันทึกจะต้องเปลี่ยนเฉพาะตัวบันทึกเท่านั้น ไม่จำเป็นต้องเรียกใช้โค้ดที่เหลือ

อีกตัวอย่างหนึ่งคือการเพิ่มการควบคุม UI ใหม่ ซึ่งคล้ายกับการควบคุมก่อนหน้านี้ หากสิ่งนี้บังคับให้คุณเพิ่มเอนทิตีที่แตกต่างกัน 10 รายการและตัวแปลงที่แตกต่างกัน 15 รายการ ดูเหมือนว่าคุณกำลังทำมากเกินไป

3) หากนักพัฒนาหลายรายกำลังทำงานในฟีเจอร์ที่แตกต่างกันของโปรเจ็กต์ของคุณ ความเป็นไปได้ของข้อขัดแย้งในการรวม นั่นคือ โอกาสที่ไฟล์/คลาสเดียวกันจะถูกเปลี่ยนแปลงโดยนักพัฒนาหลายคนในเวลาเดียวกันนั้นมีน้อยมาก

คำอธิบาย

หากเมื่อเพิ่มการดำเนินการใหม่ "เทวอดก้าใต้โต๊ะ" คุณต้องส่งผลกระทบต่อคนตัดไม้การทำงานของการดื่มและการเทดูเหมือนว่าความรับผิดชอบจะถูกแบ่งออกอย่างคดเคี้ยว แน่นอนว่านี่ไม่สามารถทำได้เสมอไป แต่เราควรพยายามลดตัวเลขนี้ลง

4) เมื่อถามคำถามที่ชัดเจนเกี่ยวกับตรรกะทางธุรกิจ (จากนักพัฒนาหรือผู้จัดการ) คุณจะเข้าสู่คลาส/ไฟล์เดียวอย่างเคร่งครัดและรับข้อมูลจากที่นั่นเท่านั้น

คำอธิบาย

คุณลักษณะ กฎ หรืออัลกอริธึมถูกเขียนอย่างกะทัดรัด แต่ละจุดอยู่ในที่เดียว และไม่กระจัดกระจายด้วยแฟล็กทั่วทั้งพื้นที่โค้ด

5) การตั้งชื่อมีความชัดเจน

คำอธิบาย

ชั้นเรียนหรือวิธีการของเรามีหน้าที่รับผิดชอบสิ่งหนึ่ง และความรับผิดชอบนั้นสะท้อนให้เห็นในชื่อของมัน

AllManagersManagerService - น่าจะเป็นคลาส God
LocalPayment - อาจจะไม่

รูปแบบนิยม 3. วิธีการพัฒนา Occam-first

ในช่วงเริ่มต้นของการออกแบบ มนุษย์ลิงไม่รู้และไม่รู้สึกถึงรายละเอียดปลีกย่อยของปัญหาที่ได้รับการแก้ไขและสามารถทำผิดพลาดได้ คุณสามารถทำผิดพลาดได้หลายวิธี:

• ทำให้วัตถุใหญ่เกินไปด้วยการรวมความรับผิดชอบที่แตกต่างกัน
• การตีกรอบใหม่โดยแบ่งความรับผิดชอบเดี่ยวๆ ออกเป็นหลายประเภท
• กำหนดขอบเขตความรับผิดชอบไม่ถูกต้อง

สิ่งสำคัญคือต้องจำกฎ: “เป็นการดีกว่าถ้าทำผิดพลาดครั้งใหญ่” หรือ “หากคุณไม่แน่ใจ ก็อย่าแตกแยก” ตัวอย่างเช่น หากชั้นเรียนของคุณมีความรับผิดชอบสองประการ ก็ยังสามารถเข้าใจได้และสามารถแบ่งออกเป็นสองส่วนโดยมีการเปลี่ยนแปลงโค้ดไคลเอ็นต์เพียงเล็กน้อย การประกอบกระจกจากเศษแก้วมักจะยากกว่า เนื่องจากบริบทถูกกระจายไปยังไฟล์หลายไฟล์ และไม่มีการพึ่งพาที่จำเป็นในโค้ดไคลเอ็นต์

ถึงเวลาที่จะเรียกมันว่าวัน

ขอบเขตของ SRP ไม่ได้จำกัดอยู่เพียง OOP และ SOLID โดยนำไปใช้กับวิธีการ ฟังก์ชัน คลาส โมดูล ไมโครเซอร์วิส และบริการ ใช้ได้กับทั้งการพัฒนา "figax-figax-and-prod" และ "วิทยาศาสตร์จรวด" ซึ่งทำให้โลกดีขึ้นเล็กน้อยในทุกที่ ถ้าคุณลองคิดดู นี่เป็นหลักการพื้นฐานของวิศวกรรมทั้งหมดเลย วิศวกรรมเครื่องกล ระบบควบคุม และระบบที่ซับซ้อนทั้งหมดถูกสร้างขึ้นจากส่วนประกอบต่างๆ และ "การแบ่งส่วนน้อยเกินไป" ทำให้นักออกแบบขาดความยืดหยุ่น "การแบ่งแยกส่วนมากเกินไป" ทำให้นักออกแบบขาดประสิทธิภาพ และขอบเขตที่ไม่ถูกต้องทำให้พวกเขาขาดเหตุผลและความอุ่นใจ

SRP ไม่ได้ถูกประดิษฐ์ขึ้นโดยธรรมชาติ และไม่ได้เป็นส่วนหนึ่งของวิทยาศาสตร์ที่แน่นอน มันหลุดพ้นจากข้อจำกัดทางชีววิทยาและจิตใจของเรา มันเป็นเพียงวิธีในการควบคุมและพัฒนาระบบที่ซับซ้อนโดยใช้สมองมนุษย์วานร เขาบอกเราว่าจะสลายระบบอย่างไร สูตรดั้งเดิมต้องใช้กระแสจิตพอสมควร แต่ฉันหวังว่าบทความนี้จะช่วยเคลียร์ควันบางส่วนได้

ที่มา: will.com