หลีกเลี่ยงกฎในพ่อมดและนักรบ

ในบทความบล็อกชุดนี้ Eric Lippert อธิบายถึงปัญหาในการออกแบบเชิงวัตถุโดยใช้พ่อมดและนักรบเป็นตัวอย่างโดยที่:

abstract class Weapon { }
sealed class Staff : Weapon { }
sealed class Sword : Weapon { }

abstract class Player 
{ 
  public Weapon Weapon { get; set; }
}
sealed class Wizard : Player { }
sealed class Warrior : Player { }

แล้วเพิ่มกฎสองสามข้อ:

• นักรบสามารถใช้ดาบได้เท่านั้น
• ตัวช่วยสร้างสามารถใช้พนักงานได้เท่านั้น

จากนั้นเขาก็จะแสดงให้เห็นถึงปัญหาที่คุณพบหากคุณพยายามบังคับใช้กฎเหล่านี้โดยใช้ระบบประเภท C # (เช่นทำให้Wizardชั้นเรียนมีความรับผิดชอบในการทำให้แน่ใจว่าตัวช่วยสร้างสามารถใช้พนักงานได้เท่านั้น) คุณละเมิดหลักการทดแทน Liskov, ความเสี่ยงข้อยกเว้นรันไทม์หรือจบลงด้วยรหัสที่ยากต่อการขยาย

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

player.Weapon = new Sword();

สถานะถูกแก้ไขโดยCommands และตามRules:

... เราทำให้Commandวัตถุที่เรียกWieldว่าใช้เวลาสองวัตถุเกมรัฐเป็นและPlayer Weaponเมื่อผู้ใช้ออกคำสั่งไปยังระบบ“ ตัวช่วยสร้างนี้ควรควงดาบนั้น” จากนั้นคำสั่งนั้นจะถูกประเมินในบริบทของชุดของRules ซึ่งสร้างลำดับของEffects เรามีสิ่งหนึ่งRuleที่บอกว่าเมื่อผู้เล่นพยายามควงอาวุธผลที่ได้คืออาวุธที่มีอยู่หากมีหนึ่งถูกทิ้งและอาวุธใหม่กลายเป็นอาวุธของผู้เล่น เรามีกฎอีกข้อหนึ่งที่เสริมความแข็งแกร่งให้กับกฎข้อแรกซึ่งระบุว่าเอฟเฟกต์ของกฎข้อแรกจะไม่นำมาใช้เมื่อวิซาร์ดพยายามใช้ดาบ

ฉันชอบแนวคิดนี้ในหลักการ แต่มีข้อกังวลเกี่ยวกับวิธีการใช้ในทางปฏิบัติ

ไม่มีอะไรน่าจะป้องกันไม่ให้นักพัฒนาจากหลีกเลี่ยงCommandsและRules โดยเพียงแค่การตั้งค่าบนWeapon คุณสมบัติความต้องการที่จะเข้าถึงได้โดยคำสั่งดังนั้นจึงไม่สามารถที่จะทำPlayerWeaponWieldprivate set

ดังนั้นสิ่งที่ทำให้นักพัฒนาไม่สามารถทำสิ่งนี้ได้? พวกเขาแค่จำไม่ได้ใช่ไหม

อาร์กิวเมนต์ทั้งหมดที่ชุดบทความบล็อกนำไปสู่อยู่ในส่วนที่ห้า :

เราไม่มีเหตุผลที่จะเชื่อว่าระบบประเภท C # ได้รับการออกแบบมาให้มีความเพียงพอในการเข้ารหัสกฎของ Dungeons & Dragons ดังนั้นทำไมเราถึงต้องลอง

เราได้แก้ไขปัญหาของ“ รหัสไปที่แสดงกฎของระบบที่ไหน?” มันไปในวัตถุที่แสดงถึงกฎของระบบไม่ใช่ในวัตถุที่แสดงถึงสถานะของเกม ความกังวลของวัตถุของรัฐคือการรักษาสถานะของพวกเขาสอดคล้องกันไม่ได้อยู่ในการประเมินกฎของเกม

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

หากนักพัฒนาต้องการสร้างระบบกฎข้อที่สองซึ่งทำสิ่งต่าง ๆ ด้วยตัวละครและอาวุธที่ระบบกฎข้อแรกไม่อนุญาตพวกเขาสามารถทำเช่นนั้นได้เพราะใน C # คุณไม่สามารถ (ไม่มีแฮ็กการสะท้อนกลับที่น่ารังเกียจ) หาวิธีโทรมา จาก.

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

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

ฉันจะเริ่มต้นด้วยการพยายามที่จะได้รับข้อกำหนดการทำงานจริง ตัวอย่างเช่น: "ผู้เล่นใด ๆ สามารถโจมตีผู้เล่นอื่น ... " ที่นี่:

interface Player {
    void Attack(Player enemy);
}

"ผู้เล่นสามารถควงอาวุธที่ใช้ในการโจมตีพ่อมดสามารถควงไม้เท้านักรบนักรบ":

public class Wizard: Player {
    ...
    public void Wield(Staff weapon) { ... }
    ...
}
public class Warrior: Player {
    ...
    public void Wield(Sword sword) { ... }
    ...
}

"อาวุธแต่ละชิ้นสร้างความเสียหายแก่ศัตรูที่ถูกโจมตี" ตกลงตอนนี้เราต้องมีอินเตอร์เฟสทั่วไปสำหรับ Weapon:

interface Weapon {
    void dealDamageTo(Player enemy);
}

และอื่น ๆ ... ทำไมไม่มีWield()ในPlayer? เพราะไม่มีข้อกำหนดที่ผู้เล่นสามารถใช้อาวุธใด ๆ ได้

ฉันสามารถอิมเมจว่าจะมีข้อกำหนดที่ระบุว่า: "ใด ๆPlayerอาจพยายามควง ๆWeapon" อย่างไรก็ตามนี่จะเป็นสิ่งที่แตกต่างอย่างสิ้นเชิง ฉันจะแบบมันบางทีด้วยวิธีนี้:

interface Player {
    void Attack(Player enemy);
    void TryWielding(Weapon weapon); // Throws UnwieldableException
}

สรุป: วางโมเดลข้อกำหนดและข้อกำหนดเท่านั้น อย่าสร้างแบบจำลองข้อมูลที่ไม่ใช่แบบจำลอง oo

วิธีการหนึ่งที่จะส่งคำสั่งไปยังWield Playerจากนั้นผู้เล่นจะดำเนินการWieldคำสั่งซึ่งตรวจสอบกฎที่เหมาะสมและส่งคืนค่าWeaponซึ่งPlayerจากนั้นตั้งค่าฟิลด์อาวุธของตนเองด้วย ด้วยวิธีนี้ฟิลด์อาวุธสามารถมีตัวตั้งค่าส่วนตัวและสามารถตั้งค่าได้ผ่านการส่งWieldคำสั่งไปยังผู้เล่นเท่านั้น

ไม่มีสิ่งใดป้องกันไม่ให้ผู้พัฒนาทำเช่นนั้น อันที่จริง Eric Lippert ลองใช้เทคนิคต่าง ๆ มากมาย แต่พวกเขาทั้งหมดมีจุดอ่อน นั่นคือประเด็นทั้งหมดของซีรีส์ที่หยุดไม่ให้ผู้พัฒนาทำเช่นนั้นไม่ใช่เรื่องง่ายและทุกสิ่งที่เขาพยายามมีข้อเสีย ในที่สุดเขาก็ตัดสินใจว่าการใช้Commandวัตถุที่มีกฎเป็นวิธีที่จะไป

ด้วยกฎคุณสามารถตั้งค่าWeaponคุณสมบัติของ a Wizardให้เป็นSwordแต่เมื่อคุณขอWizardให้ใช้อาวุธ (ดาบ) และการโจมตีมันจะไม่มีผลใด ๆ ดังนั้นจึงจะไม่เปลี่ยนสถานะใด ๆ ตามที่เขาพูดด้านล่าง:

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

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

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

ฉันคิดว่ามันเป็นทางออกที่ดี แม้ว่าในบางกรณีฉันจะไปกับรูปแบบลองตั้งเกินไป

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

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

โดยสรุปสิ่งเดียวที่สามารถป้องกันนักพัฒนาจากการทำผิดพลาดคือการมีชุดทดสอบ (หน่วย) ที่ตรวจสอบว่ากฎทั้งหมดได้รับการปฏิบัติตาม

ฉันอาจพลาดความละเอียดอ่อนที่นี่ แต่ฉันไม่แน่ใจว่าปัญหาเกิดขึ้นกับระบบพิมพ์ อาจจะมีการประชุมใน C #

ตัวอย่างเช่นคุณสามารถทำให้ประเภทนี้ปลอดภัยโดยการWeaponตั้งค่าตัวป้องกันPlayerไว้ จากนั้นเพิ่มsetSword(Sword)และsetStaff(Staff)ไปยังWarriorและWizardตามลำดับที่เรียกตัวตั้งค่าที่มีการป้องกัน

วิธีการที่การPlayer/ Weaponความสัมพันธ์แบบคงที่มีการตรวจสอบและรหัสที่ไม่สนใจก็สามารถใช้ที่จะได้รับPlayerWeapon

ดังนั้นสิ่งที่ทำให้นักพัฒนาไม่สามารถทำสิ่งนี้ได้? พวกเขาแค่จำไม่ได้ใช่ไหม

คำถามนี้มีประสิทธิภาพเช่นเดียวกันกับหัวข้อ Holy-war-ish ที่เรียกว่า " ตำแหน่งที่จะทำการตรวจสอบ " (ส่วนใหญ่อาจสังเกตววววววววว)

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

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