ฉันจะหลีกเลี่ยงการเขียนคลาส Manager ได้อย่างไร

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

นี่เป็นรูปแบบที่ไม่ดีที่จะติดตามหรือไม่ ถ้าเป็นเช่นนั้นทางเลือกคืออะไร?

คลาส "ผู้จัดการ" อาจมีปัญหาได้จากหลายสาเหตุ เหตุผลสำคัญสองข้อที่มักจะเป็น:

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

บ่อยครั้งที่หนึ่งในเหตุผลเหล่านั้นทำให้เกิดหรือนัยอื่น ๆ

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

ปกติแล้วมันง่ายที่จะแยก "ผู้จัดการ" ออกเป็นสองส่วน:

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

• ส่วนที่ประมวลผลวัตถุจริงและทำงานบางอย่างกับพวกเขา มันอาจอัปเดตวัตถุเหล่านั้น (จากนั้นเป็น "updater" หรือ "จำลอง") หรืออาจวาดวัตถุเหล่านั้น (จากนั้นก็เป็น "drawer" หรือ "renderer") หรืออาจทำอย่างอื่นกับพวกเขา; สิ่งสำคัญคือการตั้งชื่อตามวัตถุประสงค์หลักของมัน โดยทั่วไปคุณจะให้อินสแตนซ์ของประเภทนี้เป็นอินสแตนซ์ของหรืออ้างอิงถึงอินสแตนซ์ของชนิดแรก (อันที่เพิ่งจัดการอายุการใช้งานของวัตถุ)

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

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

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

• เมื่อมันควบคุมกลศาสตร์เกมของ foobars FoobarControllerคุณสามารถตั้งชื่อ
• เมื่อมัน instantiates foobars แต่แล้วผู้ได้รับมอบหมายควบคุมอย่างอื่นก็เป็นหรือFoobarFactoryFoobarBuilder
• เมื่อมันดึง foobars FoobarRendererไปที่หน้าจอมันเป็น
• เมื่อฟังเหตุการณ์ที่สร้างโดย foobars FoobarEventHandlerมันเป็น
• เมื่อมันรอสำหรับสิ่งที่จะเกิดขึ้นกับ foobars FoobarObserverที่มันเป็น
• เมื่อมันเป็นเพียงแค่ผู้ถือข้อมูลใบ้สำหรับคอลเลกชันของ foobars โดยไม่มีตรรกะใด ๆ Foobarsที่ทุกท่านเพียงแค่ชื่อมัน

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