इस मामले में, मैं कहूंगा कि आदर्श जवाब यह है कि यह कैसे 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);
हालांकि, उस मामले में जहां घटकों को पहले से ही एक साथ युग्मित किया जाता है, एक ही पैकेज में कई एनम प्रदान करने से आसानी से अतिरिक्त स्पष्टता और सरलता प्रदान की जा सकती है, बशर्ते कि एंमों के युग्मित होने का एक स्पष्ट तार्किक कारण हो, उन एनमों का उपयोग भी युग्मित है। और जो उन्हें प्रदान करता है वह किसी अतिरिक्त कपलिंग का परिचय नहीं देता है।
#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);
इस मामले में, इकाई प्रकार और सामग्री प्रकार के बीच कोई प्रत्यक्ष, तार्किक संबंध नहीं है (यह मानते हुए कि इकाइयां परिभाषित सामग्रियों में से एक नहीं हैं)। यदि, हालांकि, हमारे पास एक मामला था, उदाहरण के लिए, एक एनम स्पष्ट रूप से दूसरे पर निर्भर है, तो यह सभी युग्मित एनमों (साथ ही किसी अन्य युग्मित घटकों) के साथ एक एकल पैकेज प्रदान करने के लिए समझ में आता है, ताकि युग्मन हो सके जितना संभव हो उतना उस पैकेज को अलग किया जाए।
// 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;
}
इसलिए, जब से हम दोनों जानते हैं कि हमेशा ऐसी स्थितियां हो सकती हैं जहां एक ही फाइल में कई एन्यूमरेशन्स को परिभाषित करना अनावश्यक युग्मन जोड़ सकता है, और यह कि एकल पैकेज में युग्मित एनम प्रदान करना, इच्छित उपयोग को स्पष्ट कर सकता है और हमें वास्तविक युग्मन कोड को स्वयं के रूप में अलग करने की अनुमति देता है। जितना संभव हो, आदर्श समाधान प्रत्येक एन्यूमरेशन को अलग-अलग परिभाषित करना है, और किसी भी ऐसे एनम के लिए संयुक्त पैकेज प्रदान करना है जो अक्सर एक साथ उपयोग करने का इरादा रखते हैं। एक ही फ़ाइल में परिभाषित केवल वे ही होंगे जो आंतरिक रूप से एक साथ जुड़े होते हैं, जैसे कि एक का उपयोग दूसरे के उपयोग की भी आवश्यकता होती है।
// 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"