มันเป็นการปฏิบัติที่ไม่ถูกต้องหรือไม่ที่จะรวม enums ทั้งหมดไว้ในไฟล์เดียวและใช้มันในหลาย ๆ คลาส?

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

สมมติว่าฉันมีไฟล์ชื่อenumList.hฉันประกาศทั้งหมด enums ที่ฉันต้องการใช้ในเกมของฉัน:

// enumList.h

enum materials_t { WOOD, STONE, ETC };
enum entity_t { PLAYER, MONSTER };
enum map_t { 2D, 3D };
// and so on.

// Tile.h
#include "enumList.h"
#include <vector>

class tile
{
    // stuff
};

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

นี่เป็นวิธีปฏิบัติที่ไม่ดีและมีผลต่อประสิทธิภาพในทางใดทางหนึ่งหรือไม่

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

ฉันจะมีไฟล์เดียวต่อ enum เพื่อค้นหาได้อย่างรวดเร็วและจัดกลุ่มด้วยรหัสพฤติกรรมของการทำงานเฉพาะ (เช่นวัสดุ enum ในโฟลเดอร์ที่มีพฤติกรรมของวัสดุ ฯลฯ );

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

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

ใช่มันเป็นการปฏิบัติที่ไม่ดีไม่ใช่เพราะประสิทธิภาพ แต่เป็นเพราะการบำรุงรักษา

มันทำให้สิ่งต่าง ๆ "สะอาด" เฉพาะใน OCD "รวบรวมสิ่งที่คล้ายกันเข้าด้วยกัน" แต่ที่จริงแล้วไม่ใช่ "ความสะอาด" ที่มีประโยชน์และดี

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

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

เป็นไปไม่ได้ที่ธรรมดาที่การรวมดังกล่าวสามารถเพิ่มรอบการดำเนินงานของคุณได้มากขึ้นเนื่องจากไม่มีรหัสพฤติกรรม / ขั้นตอนการดำเนินการภายใน (ไม่มีลูปไม่มีไอเอฟ ฯลฯ )

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

IMHO ข้อดีที่คุณได้รับจากไฟล์เดียว (รหัสที่อ่านง่ายและจัดการได้มากขึ้น) ส่วนใหญ่จะมีข้อเสียมากกว่า

สำหรับฉันทุกอย่างขึ้นอยู่กับขอบเขตของโครงการของคุณ หากมีไฟล์หนึ่งไฟล์ที่มีโครงสร้างบอกว่า 10 ไฟล์และเป็นไฟล์เดียวที่เคยใช้งานฉันจะรู้สึกสบายใจที่จะมีไฟล์. h ไฟล์เดียว หากคุณมีฟังก์ชั่นการใช้งานหลายประเภทพูดหน่วยเศรษฐกิจสิ่งปลูกสร้าง ฯลฯ ฉันจะแบ่งสิ่งต่าง ๆ อย่างแน่นอน สร้าง units.h ที่ structs ทั้งหมดที่จัดการกับหน่วยอยู่ หากคุณต้องการทำบางสิ่งบางอย่างกับหน่วยงานบางแห่งคุณต้องรวม units.h แน่นอน แต่มันก็เป็น "ตัวระบุ" ที่ดีซึ่งอาจมีบางสิ่งบางอย่างกับหน่วยในไฟล์นี้

ดูด้วยวิธีนี้คุณไม่ได้ซื้อซุปเปอร์มาร์เก็ตเพราะคุณต้องการกระป๋องโค้ก;)

ฉันไม่ใช่ C ++ dev ดังนั้นคำตอบนี้จะเป็นคำทั่วไปสำหรับ OOA & D:

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

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

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

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

สิ่งนี้กลายเป็นปัญหาเมื่อคุณมีนักพัฒนาซอฟต์แวร์หลายคนทำงานบนรหัสเดียวกัน

ฉันได้เห็นไฟล์ทั่วโลกที่คล้ายกันอย่างแน่นอนกลายเป็น Nexus สำหรับการชนกันของการรวมและทุกประเภทของความเศร้าโศกในโครงการ (ใหญ่กว่า)

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

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

ใช่มันเป็นวิธีปฏิบัติที่ไม่ดีในการทำโครงการขนาดใหญ่ จูบ.

ผู้ร่วมงานอายุน้อยได้เปลี่ยนชื่อตัวแปรอย่างง่ายในไฟล์ core .h และวิศวกร 100 คนรอเวลา 45 นาทีเพื่อให้ไฟล์ทั้งหมดของพวกเขาสร้างใหม่ซึ่งส่งผลต่อประสิทธิภาพของทุกคน ;)

โครงการทั้งหมดเริ่มต้นเล็ก ๆ บอลลูนในช่วงหลายปีที่ผ่านมาและเราสาปแช่งผู้ที่ใช้ทางลัดในช่วงต้นสำหรับการสร้างหนี้ทางเทคนิค แนวปฏิบัติที่ดีที่สุดรักษาเนื้อหา. h ทั่วโลกไว้เฉพาะในระดับโลก

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

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

การระบุการแจกแจงทั้งหมดของคุณในไฟล์เดียวกันจะรวมเข้าด้วยกันและโดยส่วนขยายจะทำให้โค้ดใด ๆ ที่ขึ้นอยู่กับ enums หนึ่งอันหรือมากกว่านั้นขึ้นอยู่กับ enums ทั้งหมดโดยไม่คำนึงว่ารหัสนั้นใช้จริงๆ หรือไม่

#include "enumList.h"

// Draw map texture.  Requires map_t.
// Not responsible for rendering entities, so doesn't require other enums.
// Introduces two unnecessary couplings.
void renderMap(map_t, mapIndex);

renderMap()ค่อนข้างจะรู้เพียงเท่านั้นmap_tเพราะมิฉะนั้นการเปลี่ยนแปลงใด ๆ กับผู้อื่นจะส่งผลกระทบต่อแม้ว่าจะไม่ได้โต้ตอบกับผู้อื่น

#include "mapEnum.h" // Theoretical file defining map_t.

void renderMap(map_t, mapIndex);

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

#include "entityEnum.h"    // Theoretical file defining entity_t.
#include "materialsEnum.h" // Theoretical file defining materials_t.

// Can entity break the specified material?
bool canBreakMaterial(entity_t, materials_t);

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

// File: "actionEnums.h"

enum action_t { ATTACK, DEFEND, SKILL, ITEM };               // Action type.
enum skill_t  { DAMAGE, HEAL, BUFF, DEBUFF, INFLICT, NONE }; // Skill subtype.

// -----

#include "actionTypes.h" // Provides action_t & skill_t from "actionEnums.h", and class Action (which couples them).
#include "entityEnum.h"  // Theoretical file defining entity_t.

// Assume ActFlags is or acts as a table of flags indicating what is and isn't allowable, based on entity_t and Action.
ImplementationDetail ActFlags;

// Indicate whether a given type of entity can perform the specified action type.
// Assume class Action provides members type() and subtype(), corresponding to action_t and skill_t respectively.
// Is only slightly aware of the coupling; knows type() and subtype() are coupled, but not how or why they're coupled.
bool canAct(entity_t e, const Action& act) {
    return ActFlags[e][act.type()][act.subtype()];
}

แต่อนิจจา ... แม้ว่าสอง enums จะอยู่คู่กันภายในแม้ว่ามันจะมีความแข็งแกร่งพอ ๆ กับ "enum ที่สองให้หมวดหมู่ย่อยสำหรับ Enum แรก" อาจมีเวลาที่จำเป็นต้องใช้ enums เพียงตัวเดียว

#include "actionEnums.h"

// Indicates whether a skill can be used from the menu screen, based on the skill's type.
// Isn't concerned with other action types, thus doesn't need to be coupled to them.
bool skillUsableOnMenu(skill_t);

// -----
// Or...
// -----

#include "actionEnums.h"
#include "gameModeEnum.h" // Defines enum gameMode_t, which includes MENU, CUTSCENE, FIELD, and BATTLE.

// Used to grey out blocked actions types, and render them unselectable.
// All actions are blocked in cutscene, or allowed in battle/on field.
// Skill and item usage is allowed in menu.  Individual skills will be checked on attempted use.
// Isn't concerned with specific types of skills, only with broad categories.
bool actionBlockedByGameMode(gameMode_t mode, action_t act) {
    if (mode == CUTSCENE) { return true; }
    if (mode == MENU) { return (act == SKILL || act == ITEM); }

    //assert(mode == BATTLE || mode == FIELD);
    return false;
}

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

// File: "materialsEnum.h"
enum materials_t { WOOD, STONE, ETC };

// -----

// File: "entityEnum.h"
enum entity_t { PLAYER, MONSTER };

// -----

// File: "mapEnum.h"
enum map_t { 2D, 3D };

// -----

// File: "actionTypesEnum.h"
enum action_t { ATTACK, DEFEND, SKILL, ITEM };

// -----

// File: "skillTypesEnum.h"
enum skill_t  { DAMAGE, HEAL, BUFF, DEBUFF, INFLICT, NONE };

// -----

// File: "actionEnums.h"
#include "actionTypesEnum.h"
#include "skillTypesEnum.h"