เกมค้าปลีกใช้ "การควบคุมแบบผกผัน" และ "การฉีดพึ่งพา" หรือไม่?

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

คุณเรียกมันว่า 'การพัฒนาซอฟต์แวร์ที่ขยันหมั่นเพียร' ฉันเรียกมันว่า นั่นไม่ได้หมายความว่าการผกผันของการควบคุมนั้นไม่ดี - ในความเป็นจริงแล้วคำจำกัดความพื้นฐานของมันก็ดี แต่การแพร่กระจายของกรอบงานและวิธีการทำงานทั้งหมดเพื่อให้บรรลุทั้งหมดนี้เป็นสิ่งที่ขาดสติน้อยโดยเฉพาะอย่างยิ่ง อินเทอร์เฟซที่ดีและสะอาดสมบูรณ์แบบเพื่อให้สามารถฉีดส่วนประกอบที่เปลี่ยนแทนกันได้ซึ่ง 99% ของเวลาที่คุณไม่เคยแลกเปลี่ยน มันเป็นสิ่งที่สามารถเกิดขึ้นได้จากสภาพแวดล้อมขององค์กร Java เท่านั้นและฉันดีใจที่มันไม่ได้ตั้งหลักอยู่ที่อื่น

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

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

รูปแบบกลยุทธ์ , องค์ประกอบ , การพึ่งพาการฉีดล้วนมีความสัมพันธ์กันอย่างใกล้ชิด

เนื่องจากรูปแบบกลยุทธ์เป็นรูปแบบของการฉีดขึ้นอยู่กับว่าถ้าคุณดูที่เครื่องยนต์เช่น Unity เช่นพวกเขาจะยึดตามหลักการนี้อย่างสมบูรณ์ การใช้ส่วนประกอบ (รูปแบบกลยุทธ์) ของพวกเขาฝังลึกลงในเครื่องมือทั้งหมดของพวกเขา

ประโยชน์หลักอย่างหนึ่งนอกเหนือจากการนำส่วนประกอบมาใช้ซ้ำคือการหลีกเลี่ยงลำดับชั้นระดับลึกที่หวั่นกลัว

นี่คือบทความของมิคเวสต์ที่พูดถึงวิธีที่เขาแนะนำระบบประเภทนี้ในซีรีย์เกมของTony Hawkโดย Neversoft

วิวัฒนาการลำดับขั้นของคุณ

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

ดูเหมือนจะมีความสับสนมากมายเกี่ยวกับรูปแบบการพลิกกลับของการควบคุม (IoC) ผู้คนจำนวนมากได้รับการบรรจุด้วยรูปแบบกลยุทธ์หรือแบบจำลองส่วนประกอบ แต่การเปรียบเทียบเหล่านี้ไม่ได้จับภาพสิ่งที่เป็นจริงเกี่ยวกับ IoC IoC เป็นจริงเกี่ยวกับวิธีการได้รับการพึ่งพา ผมขอยกตัวอย่าง:

class Game {
    void Load() {
        this.Sprite.Load(); // loads resource for drawing later
    }
}

class Sprite {
    void Load() {
        FileReader reader = new FileReader("path/to/resource.gif");
        // load image from file
    }
}

ในข้างต้นเป็นที่ชัดเจนว่ามีการพึ่งพาได้Sprite.Load FileReaderเมื่อคุณต้องการทดสอบวิธีที่คุณต้องการดังต่อไปนี้:

1. ระบบไฟล์ในสถานที่
2. ไฟล์ทดสอบที่จะโหลดจากระบบไฟล์
3. ความสามารถในการทริกเกอร์ข้อผิดพลาดของระบบไฟล์ทั่วไป

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

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

หากเราต้องเขียนSprite.Loadวิธีข้างต้นอีกครั้งเราอาจจะจบลงด้วย:

class Sprite {
    void Load(IReader reader) {
        // load image through reader
    }
}

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

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

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

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

ต้องเห็นด้วยกับ Kylotan ในอันนี้ "การฉีดพึ่งพา" เป็นวิธีแก้ปัญหา Java ที่น่าเกลียดสำหรับข้อบกพร่องเกี่ยวกับแนวคิด Java ที่น่าเกลียดและเหตุผลเดียวที่ทุกคนมองมันเป็นภาษาอื่น ๆ ก็คือเพราะ Java กลายเป็นภาษาแรกสำหรับคนจำนวนมากเมื่อไม่ควรทำ

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

นี่คือความคิดที่มีมาตั้งแต่ปี 1950 มันอยู่ในไลบรารี่มาตรฐาน C (qsort อยู่ในใจ) และมันอยู่ทั่วสถานที่ใน Delphi และ. NET (ตัวจัดการเหตุการณ์ / ผู้ได้รับมอบหมาย) มันเปิดใช้งานรหัสเก่าที่จะเรียกรหัสใหม่โดยไม่จำเป็นต้องคอมไพล์รหัสเก่าอีกครั้งและมันจะถูกใช้ตลอดเวลาในเอ็นจิ้นเกม

ไม่ได้อยู่ในประสบการณ์ของฉัน ซึ่งเป็นความอัปยศเนื่องจากรหัสเกมจะต้องปรับตัวได้มากและวิธีการเหล่านี้จะช่วยได้อย่างแน่นอน

อย่างไรก็ตามจะต้องมีการกล่าวว่าทั้งสองวิธีสามารถใน C ++ แนะนำตารางเสมือนที่ไม่เคยมีมาก่อนซึ่งจะนำไปสู่ประสิทธิภาพที่เหมาะสม

ฉันไม่ใช่นักพัฒนาเกมมืออาชีพและพยายามใช้ IoC ใน C ++ เพียงครั้งเดียวดังนั้นนี่จึงเป็นการคาดเดา

อย่างไรก็ตามฉันสงสัยว่าผู้พัฒนาเกมจะสงสัยเกี่ยวกับ IoC เพราะมันหมายถึง:

1 / ออกแบบอินเทอร์เฟซจำนวนมากและคลาสเล็ก ๆ จำนวนมาก

2 / มีการเรียกใช้ฟังก์ชันทุกครั้งที่ถูกผูกไว้เมื่อเร็ว ๆ นี้

ตอนนี้อาจเป็นเรื่องบังเอิญ แต่ทั้งคู่มีแนวโน้มที่จะซับซ้อนและ / หรือมีปัญหาเล็กน้อยสำหรับการแสดงใน C ++ (ซึ่งใช้กันอย่างแพร่หลายในเกมใช่ไหม?) มากกว่าใน Java ที่ IoC เริ่มแพร่หลาย (อาจเป็นไปได้ว่า เพราะมันค่อนข้างง่ายที่จะช่วยคนออกแบบลำดับชั้นของวัตถุ saner และเพราะบางคนเชื่อว่ามันสามารถเปลี่ยนการเขียนแอพพลิเคชั่นใน Java เป็นการเขียนแอพพลิเคชั่นใน XML แต่นั่นเป็นการอภิปรายอื่น: P)

ฉันสนใจในความคิดเห็นหากไม่ได้ทำให้รู้สึกใด ๆ เลย)