รูปแบบของรัฐละเมิดหลักการทดแทน Liskov หรือไม่?

ภาพนี้นำมาจากการใช้การออกแบบและรูปแบบที่ใช้โดเมนขับเคลื่อน: พร้อมตัวอย่างใน C # และ. NET

นี่คือแผนภาพคลาสสำหรับรูปแบบสถานะที่ a SalesOrderสามารถมีสถานะต่างกันในช่วงเวลาของชีวิต อนุญาตให้ช่วงการเปลี่ยนภาพบางอย่างระหว่างรัฐที่แตกต่างกัน

ตอนนี้OrderStateคลาสเป็นabstractคลาสและวิธีการทั้งหมดได้รับการสืบทอดไปยังคลาสย่อย หากเราพิจารณาคลาสย่อยCancelledซึ่งเป็นสถานะสุดท้ายที่ไม่อนุญาตให้มีการเปลี่ยนสถานะเป็นสถานะอื่นเราจะต้องoverrideใช้วิธีการทั้งหมดในคลาสนี้เพื่อโยนข้อยกเว้น

ตอนนี้ไม่ได้เป็นการละเมิดหลักการทดแทนของ Liskov เนื่องจาก sublcass ไม่ควรเปลี่ยนพฤติกรรมของผู้ปกครองหรือไม่ การเปลี่ยนคลาสนามธรรมเป็นอินเตอร์เฟสแก้ไขสิ่งนี้หรือไม่?
จะแก้ไขได้อย่างไร?

การใช้งานเฉพาะนี้ใช่ หากคุณสร้างคลาสที่เป็นรูปธรรมมากกว่าที่จะใช้นามธรรมคุณจะได้รับจากสิ่งนี้

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

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

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

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

แต่ ณ จุดว่ามันเป็นศิลปะมากกว่าวิศวกรรมและดังนั้นจึงเป็นที่แน่นอนอัตนัยวิธีการของคุณกับบางส่วนของสิ่งเหล่านั้นที่กล่าวว่าหลักการที่เป็นคำแนะนำที่ดีและใช่การดำเนินรายการคือการละเมิด LSP แต่อาจได้รับการแก้ไขจะไม่เป็น เพียงระมัดระวังเกี่ยวกับ SRP เมื่อใช้รูปแบบใด ๆ ของลักษณะนี้และคุณน่าจะปลอดภัย

sublcass ไม่ควรเปลี่ยนพฤติกรรมของผู้ปกครองหรือไม่

นั่นเป็นการตีความที่ผิดพลาดทั่วไปของ LSP คลาสย่อยสามารถเปลี่ยนพฤติกรรมของพาเรนต์ได้ตราบใดที่มันยังคงเป็นจริงกับประเภทพาเรนต์

มีคำอธิบายที่ดีเกี่ยวกับWikipediaซึ่งแนะนำสิ่งต่าง ๆ ที่จะเป็นการละเมิด LSP:

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

• เงื่อนไขเบื้องต้นไม่สามารถเสริมความแข็งแกร่งในประเภทย่อย
• Postconditions ไม่สามารถลดลงได้ในประเภทย่อย
• ค่าคงที่ของซูเปอร์ไทป์จะต้องเก็บรักษาไว้ในประเภทย่อย
• ข้อ จำกัด ประวัติ ("กฎประวัติศาสตร์") วัตถุนั้นได้รับการยกย่องว่าสามารถปรับเปลี่ยนได้ด้วยวิธีการของพวกเขาเท่านั้น (encapsulation) เนื่องจากชนิดย่อยอาจแนะนำวิธีการที่ไม่ปรากฏใน supertype การแนะนำวิธีการเหล่านี้อาจอนุญาตให้มีการเปลี่ยนแปลงสถานะในชนิดย่อยที่ไม่อนุญาตใน supertype ข้อ จำกัด ประวัติห้ามสิ่งนี้ มันเป็นองค์ประกอบใหม่ที่ได้รับการแนะนำโดย Liskov และ Wing การละเมิดข้อ จำกัด นี้สามารถเป็นตัวอย่างได้โดยการกำหนด MutablePoint เป็นประเภทย่อยของ ImmutablePoint นี่เป็นการละเมิดข้อ จำกัด ด้านประวัติเพราะในประวัติศาสตร์ของจุดที่ไม่เปลี่ยนรูปแบบรัฐจะเหมือนเดิมเสมอหลังจากการสร้างดังนั้นจึงไม่สามารถรวมประวัติของ MutablePoint โดยทั่วไปได้ อย่างไรก็ตามฟิลด์ที่ถูกเพิ่มลงในชนิดย่อยอาจถูกปรับเปลี่ยนได้อย่างปลอดภัยเนื่องจากไม่สามารถสังเกตเห็นได้ด้วยวิธีการของ supertype

โดยส่วนตัวแล้วฉันคิดว่ามันง่ายกว่าที่จะจำสิ่งนี้: ถ้าฉันดูพารามิเตอร์ในวิธีที่มีประเภท A คนที่จะผ่านประเภทย่อย B จะทำให้ฉันประหลาดใจบ้างไหม? หากพวกเขาจะมีการละเมิด LSP

การขว้างข้อยกเว้นแปลกใจหรือไม่? ไม่ได้จริงๆ เป็นสิ่งที่สามารถเกิดขึ้นได้ตลอดเวลาไม่ว่าฉันจะเรียกใช้วิธีการจัดส่งบน OrderState หรือ Granted หรือ Shipped ดังนั้นฉันต้องคำนึงถึงมันและไม่ใช่การละเมิด LSP จริงๆ

ที่กล่าวว่าฉันคิดว่ามีวิธีที่ดีกว่าในการจัดการสถานการณ์นี้ ถ้าฉันเขียนสิ่งนี้ใน C # ฉันจะใช้ส่วนต่อประสานและตรวจสอบการใช้งานส่วนต่อประสานก่อนที่จะเรียกใช้เมธอด ตัวอย่างเช่นถ้า OrderState ปัจจุบันไม่ได้ใช้ IShippable อย่าเรียกใช้วิธีการจัดส่ง

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

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

(นี่เขียนจากมุมมองของ C # ดังนั้นจึงไม่มีข้อยกเว้นที่ตรวจสอบแล้ว)

ตามบทความ Wikipedia เกี่ยวกับ LSPหนึ่งในเงื่อนไขของ LSP คือ:

ไม่ควรมีข้อยกเว้นใหม่โดยวิธีการของชนิดย่อยยกเว้นในกรณีที่ข้อยกเว้นเหล่านั้นเป็นชนิดย่อยของข้อยกเว้นที่ถูกโยนโดยวิธีการของประเภทย่อย

คุณควรเข้าใจเรื่องนี้อย่างไร? อะไรคือ“ ข้อยกเว้นที่ถูกโยนโดยวิธีการของ supertype” เมื่อวิธีของ supertype นั้นเป็นนามธรรม? ฉันคิดว่าสิ่งเหล่านั้นเป็นข้อยกเว้นที่บันทึกไว้เป็นข้อยกเว้นที่สามารถโยนโดยวิธีการของ supertype

สิ่งนี้หมายความว่าหากOrderState.Ship()มีการบันทึกไว้เป็นสิ่งที่ชอบ“ โยนInvalidOperationExceptionถ้าการดำเนินการนี้ไม่ได้รับการสนับสนุนโดยสถานะปัจจุบัน” จากนั้นฉันคิดว่าการออกแบบนี้ไม่ทำลาย LSP ในทางกลับกันหากวิธีการพิมพ์ supertype ไม่ได้จัดทำเอกสารด้วยวิธีนี้ LSP จะถูกละเมิด

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