การสืบทอดหลายรายการละเมิดหลักการความรับผิดชอบแบบเดี่ยวหรือไม่?

หากคุณมีคลาสที่สืบทอดมาจากคลาสที่แตกต่างกันสองคลาสนี่หมายความว่าคลาสย่อยของคุณทำสิ่งต่าง ๆ โดยอัตโนมัติ (อย่างน้อย) 2 อย่างสิ่งหนึ่งจากคลาสซุปเปอร์แต่ละอัน?

ฉันเชื่อว่าไม่มีความแตกต่างหากคุณมีการสืบทอดหลายอินเตอร์เฟส

แก้ไข: เพื่อความชัดเจนฉันเชื่อว่าหากคลาสย่อยหลายคลาสละเมิด SRP จากนั้นใช้หลายอินเทอร์เฟซ (ไม่ใช่ตัวทำเครื่องหมายหรืออินเทอร์เฟซพื้นฐาน (เช่นที่เปรียบเทียบได้)) ละเมิด SRP ด้วย

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

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

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

class BillingCycleInvoice : public BillingCycle, public Invoice {
};

มันไม่ดี: คุณBillingCycleInvoiceมีความรับผิดชอบที่หลากหลายเนื่องจากเกี่ยวข้องกับความซับซ้อนที่สำคัญของระบบ

ในทางกลับกันถ้าคุณสืบทอดเช่นนี้

class PersistentInvoice : public Invoice, public PersistentObject {
};

ชั้นเรียนของคุณนั้นโอเค: โดยทางเทคนิคแล้วมันให้บริการข้อกังวลสองข้อพร้อมกัน แต่เนื่องจากมีเพียงสิ่งเดียวเท่านั้นที่มีความสำคัญคุณจึงสามารถเขียนการสืบทอดสิ่งที่เกิดขึ้นโดยบังเอิญเป็น "ต้นทุนในการทำธุรกิจ"

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

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

ค่อนข้าง. ให้ความสำคัญกับหลักการหลักของ SRP:

คลาสควรมีเหตุผลเดียวเท่านั้นที่จะเปลี่ยน

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

สถานที่ที่การสืบทอดหลายอย่างไม่ละเมิด SRP คือเมื่อทั้งหมด แต่หนึ่งในประเภทฐานไม่ใช่สิ่งที่ชั้นกำลังดำเนินการอยู่ แต่ทำหน้าที่เป็นลักษณะที่ชั้นเรียนเกิดขึ้น พิจารณาIDisposableใน C # สิ่งที่ทิ้งแล้วไม่มีความรับผิดชอบสองอย่างอินเทอร์เฟซเพียงทำหน้าที่เป็นมุมมองในชั้นเรียนที่ใช้คุณลักษณะ แต่มีความรับผิดชอบที่แตกต่างกันอย่างแน่นอน

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

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

ไม่ใช่เลย. ใน Java คุณสามารถมีอินเทอร์เฟซที่แสดงถึงชนิดของวัตถุโดเมน - Foo ตัวอย่างเช่น มันอาจจำเป็นต้องนำไปเปรียบเทียบกับวัตถุอื่น ๆ ของ Foo และดังนั้นจึงใช้การเปรียบเทียบ (กับตรรกะการเปรียบเทียบถูกทำให้เป็นภายนอกในคลาส Comparator); อาจเป็นไปได้ว่าวัตถุนี้ยังต้องต่อเนื่องกันได้เพื่อให้สามารถขนส่งผ่านเครือข่ายได้ และอาจจำเป็นต้อง Cloneable ดังนั้นคลาสใช้อินเทอร์เฟซสามตัว แต่ไม่มีตรรกะใด ๆ ภายในเพื่อสนับสนุนเกินกว่าที่ Foo สนับสนุน

ที่กล่าวว่ามันโง่ที่จะใช้ SRP เพื่อสุดขั้ว หากคลาสกำหนดมากกว่าหนึ่งวิธีมันจะละเมิด SRP หรือไม่? วัตถุ Java ทั้งหมดมีวิธีการ toString () และวิธีการเท่ากับ (วัตถุ) ซึ่งหมายความว่าวัตถุทุกคนใน Java มีความรับผิดชอบทั้งความเท่าเทียมกันและการเป็นตัวแทนของตัวเอง นั่นเป็นสิ่งที่ไม่ดีเหรอ?

ฉันเดาว่ามันขึ้นอยู่กับว่าคุณกำหนดความรับผิดชอบอย่างไร ในตัวอย่าง iostream คลาสสิคจะไม่ละเมิด SRP IOstream รับผิดชอบการจัดการสตรีมแบบสองทิศทางหนึ่งสตรีม

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