मेरे पास एक ऐसा एप्लिकेशन है जिसके लिए कई अलग-अलग गणनाओं की आवश्यकता होती है। आवेदन विभिन्न परतों में devided किया जा सकता है। उदाहरण के लिए चलिए तीन परतें मानते हैं: एक तृतीय पक्ष एनालिटिक्स लाइब्रेरी, एप्लिकेशन व्यवसाय तर्क और यूआई/प्रस्तुति तर्क।एकाधिक अनुप्रयोग परतों में बहुत सारे एम्स प्रबंधित करना
कई मामलों में सभी परतों को एक ही अवधारणा का प्रतिनिधित्व करने वाले enum की आवश्यकता हो सकती है। उदाहरण के लिए भुगतान आवृत्ति लेते हैं। (उदाहरण के लिए वार्षिक, अर्ध-वार्षिक, तिमाही आदि ...)। तृतीय पक्ष लाइब्रेरी अपने स्वयं के enum प्रदान करता है, व्यापार तर्क परत में विभिन्न वर्गों को एक समान enum की आवश्यकता होगी, और अंत में यूआई परत को ड्रॉपडाउन आदि में विभिन्न विकल्पों को प्रस्तुत करने के लिए इसकी आवश्यकता हो सकती है ...
अब, सामान्यतः मैं परत की सार्वजनिक इंटरफेस में आंतरिक निर्भरताओं के प्रकारों को उजागर न करके प्रत्येक परत के उपयोगकर्ता को अपनी आंतरिक निर्भरताओं और कार्यान्वयन विवरण से ढालना पसंद है। इसका मतलब यह है कि भले ही तीसरे पक्ष के lib के साथ बातचीत की अपनी "आवृत्ति" enum के उपयोग की आवश्यकता हो, फिर भी मुझे व्यापार परत के लिए समकक्ष "फ्रीक्वेंसी" enum बनाने की आवश्यकता होगी और यूआई परत के लिए एक दूसरे के रूप में ...
इसमें से सभी को अतिरिक्त मैपर वर्गों के साथ-साथ बहुत सारे मैपिंग की आवश्यकता होती है। दूसरी ओर adventage कि प्रत्येक परत के बाद से मैं enums के बहुत से निपटने के लिए enum का अपना संस्करण से मूल्यों को इसकी जरूरत नहीं है या समर्थन बाहर करने के लिए ...
अब फैसला कर सकता है, है मैं क्या यह सोच रहा था कि क्या यह आम तौर पर करने के लिए एक अच्छी बात है, या मैं सिर्फ चीजों को खत्म कर रहा हूं?
यह एक अच्छा सुझाव नहीं है। उन इकाइयों के करीब enums होना बेहतर है जो उनका उपयोग करेंगे। उदाहरण के लिए, 'ऑर्डर' में 'ऑर्डर टाइप' एनम हो सकता है, जो उन्हें प्रोजेक्ट के एक फ़ोल्डर में रखने के लिए समझ में आता है। इससे उन्हें व्यवसाय तर्क के अनुसार बदलना आसान हो जाता है। यह एक 'आम' जगह में ऐसे विभिन्न enums पूल पूल करने के लिए अपील नहीं कर रहा है। –
@ मसूसोखारी अलग-अलग पुस्तकालयों में enums को विभाजित करने से कोड डुप्लिकेशन के बिना बीएलएल और यूआई परतों के ढीले युग्मन की अनुमति मिलती है - यह एक बिल्कुल अच्छा सुझाव है। दो चीजों को एक फ़ोल्डर में रखना * एक अच्छा विचार है, जब तक कि उन चीजों को बारीकी से जोड़ना है, जो इस उदाहरण में नहीं है (और इस उदाहरण में वास्तव में समाधान के भीतर चिंताओं को अलग करने से नुकसान होगा)।आपकी आलोचना वास्तव में मान्य नहीं है। –