स्थिरांक का आयोजन करने के लिए नेस्टेड सार्वजनिक वर्गों का उपयोग करना

Question

मैं कई स्थिरांक के साथ एक आवेदन पर काम कर रहा हूँ। अंतिम कोड समीक्षा में यह सामने आया कि स्थिरांक बहुत अधिक बिखरे हुए हैं और सभी को एक एकल "मास्टर" स्थिरांक फ़ाइल में व्यवस्थित किया जाना चाहिए। असहमति उन्हें व्यवस्थित करने के तरीके के बारे में है। बहुसंख्यक महसूस करते हैं कि निरंतर नाम का उपयोग करना काफी अच्छा होना चाहिए, लेकिन इससे कोड इस तरह दिखाई देगा:

public static final String CREDITCARD_ACTION_SUBMITDATA = "6767";
public static final String CREDITCARD_UIFIELDID_CARDHOLDER_NAME = "3959854";
public static final String CREDITCARD_UIFIELDID_EXPIRY_MONTH = "3524";
public static final String CREDITCARD_UIFIELDID_ACCOUNT_ID = "3524";
...
public static final String BANKPAYMENT_UIFIELDID_ACCOUNT_ID = "9987";

मुझे इस प्रकार के नामकरण सम्मेलन बोझिल लगते हैं। मुझे लगा कि पब्लिक नेस्टेड क्लास का उपयोग करना आसान हो सकता है, और ऐसा कुछ हो सकता है:

public class IntegrationSystemConstants
{
    public class CreditCard
    {
        public static final String UI_EXPIRY_MONTH = "3524";
        public static final String UI_ACCOUNT_ID = "3524";
        ...
    }
    public class BankAccount
    {
        public static final String UI_ACCOUNT_ID = "9987";
        ...
    }
}

यह विचार स्वागत नहीं किया गया है क्योंकि यह था "बहुत जटिल" (मैं करने के लिए अधिक से अधिक विवरण नहीं मिला क्यों यह भी जटिल हो सकता है)। मुझे लगता है कि यह संबंधित स्थिरांक के समूहों के बीच एक बेहतर विभाजन बनाता है और ऑटो-कम्प्लीट के साथ-साथ इन्हें ढूंढना आसान हो जाता है। हालांकि मैंने ऐसा कभी नहीं देखा है, इसलिए मैं सोच रहा हूं कि क्या यह एक स्वीकृत अभ्यास है या यदि बेहतर कारण हैं कि ऐसा नहीं किया जाना चाहिए।

Comments

मुझे विचार पसंद है। मैंने खुद को C ++ में कुछ ऐसा ही करते हुए पाया जब मैं चाहता था कि C # -स्टाइल एनुम-जैसे स्कूपिंग और व्यवहार, लेकिन सार्थक मूल्यों के साथ (मुझे लगता है कि यह विचार उत्पन्न हुआ क्योंकि मुझे स्कैला में एनम की जगह केस क्लासेस का उपयोग करने की आदत है)। दी, यह मनोरंजन के लिए एक व्यक्तिगत परियोजना थी, न कि टीम प्रयास।

— KChaloux

Answer 1

मैं दोनों में से किसी भी प्रस्ताव से सहमत नहीं हूं।

स्थिरांक उनके उचित वर्गों में होना चाहिए , प्रस्तावित दो रूपों में से किसी में भी सभी-स्थिर वर्ग में नहीं ।

स्थिरांक केवल वर्ग / इंटरफेस नहीं होना चाहिए।

एक वर्ग CreditCard(एक आंतरिक वर्ग नहीं) मौजूद होना चाहिए। इस वर्ग / इंटरफ़ेस में क्रेडिट कार्ड के साथ-साथ स्थिरांक के सापेक्ष तरीके हैं UI_EXPIRY_MONTHऔर UI_ACCOUNT_ID।

एक वर्ग / इंटरफ़ेस BankAccount(एक आंतरिक वर्ग नहीं) मौजूद होना चाहिए । इस वर्ग / इंटरफ़ेस में बैंक खातों के साथ-साथ निरंतर के तरीके भी हैं UI_ACCOUNT_ID।

उदाहरण के लिए जावा एपीआई में प्रत्येक वर्ग / इंटरफ़ेस में इसके स्थिरांक होते हैं। वे सैकड़ों स्थिरांक वाले एक कॉन्स्टेंट वर्ग / इंटरफ़ेस में नहीं हैं, या तो आंतरिक कक्षाओं में वर्गीकृत हैं या नहीं।

उदाहरण के लिए, इन स्थिरांक परिणाम सेट के लिए प्रासंगिक इंटरफ़ेस में हैं ResultSet:

static int  CLOSE_CURSORS_AT_COMMIT 
static int  CONCUR_READ_ONLY 
static int  CONCUR_UPDATABLE 
static int  FETCH_FORWARD 
static int  FETCH_REVERSE 
static int  FETCH_UNKNOWN 
static int  HOLD_CURSORS_OVER_COMMIT 
static int  TYPE_FORWARD_ONLY 
static int  TYPE_SCROLL_INSENSITIVE 
static int  TYPE_SCROLL_SENSITIVE 

इस इंटरफ़ेस में परिणाम सेट के सापेक्ष विधि हस्ताक्षर हैं, और कक्षाएं उस व्यवहार को लागू करती हैं। वे निरंतर-धारक नहीं हैं।

यूआई कार्यों के लिए निरंतर ये इंटरफ़ेस में हैं javax.swing.Action:

static String   ACCELERATOR_KEY 
static String   ACTION_COMMAND_KEY 
static String   DEFAULT 
static String   LONG_DESCRIPTION 
static String   MNEMONIC_KEY 
static String   NAME 
static String   SHORT_DESCRIPTION 
static String   SMALL_ICON 

कार्यान्वयन कक्षाओं में UI क्रियाओं के सापेक्ष व्यवहार होता है, वे निरंतर धारक नहीं होते हैं।

मुझे पता है कि कम से कम एक "स्थिरांक" इंटरफ़ेस ( SwingConstants) बिना किसी विधि के है, लेकिन इसमें सैकड़ों स्थिरांक नहीं हैं, बस कुछ हैं, और वे सभी यूआई तत्वों की दिशाओं और पदों से संबंधित हैं:

static int  BOTTOM 
static int  CENTER 
static int  EAST 
static int  HORIZONTAL 
static int  LEADING 
static int  LEFT 
static int  NEXT 
static int  NORTH 
static int  NORTH_EAST 
static int  NORTH_WEST 
static int  PREVIOUS 
static int  RIGHT 
static int  SOUTH 
static int  SOUTH_EAST 
static int  SOUTH_WEST 
static int  TOP 
static int  TRAILING 
static int  VERTICAL 
static int  WEST 

मुझे लगता है कि केवल कक्षा ही ओओ डिजाइन अच्छा नहीं है।

Comments

जबकि मैं मानता हूं कि केवल कांस्टेंट ही ज्यादातर मामलों में खराब डिजाइन का संकेत होते हैं, इसके वैध उपयोग हैं। उदाहरण के लिए, स्थिरांक हमेशा किसी विशेष वर्ग के लिए "संबंधित" नहीं होता है। एंड्रॉइड प्रोग्रामिंग में इंटेंट एक्स्ट्रा के लिए कुंजी एक ऐसा ही ठोस उदाहरण है।

— क्युरीटैक्शनेजन

+1, लेकिन यूआई कॉन्स्टेंट शायद BankAccount जैसे बिजनेस मॉडल में नहीं होना चाहिए। वे कुछ यूआई वर्ग के हैं।

— केविन क्लाइन

Answer 2

यह सामने आया कि स्थिरांक बहुत अधिक बिखरे हुए हैं और सभी को एक "मास्टर" स्थिरांक फ़ाइल में व्यवस्थित किया जाना चाहिए।

यह स्थिरांक की समस्या का 100% गलत समाधान है "खोजने में कठिन"। यह एक मूलभूत त्रुटि है (दुर्भाग्यवश सभी आमतौर पर प्रोग्रामर द्वारा स्थायी), तकनीकी मानदंडों जैसे स्थिरांक, गणन या इंटरफेस द्वारा चीजों को समूहित करना।

लेयर आर्किटेक्चर को छोड़कर, चीजों को उनके डोमेन द्वारा समूहीकृत किया जाना चाहिए , और सभी को अधिक स्थिर करना चाहिए क्योंकि वे बहुत निम्न स्तर के तत्व हैं। लगातार उन वर्गों या इंटरफेस का हिस्सा होना चाहिए जो उन्हें अपने एपीआई के हिस्से के रूप में उपयोग करते हैं। यदि आपको उनके रहने के लिए प्राकृतिक जगह नहीं मिल रही है, तो आपको अपने एपीआई डिजाइन को साफ करना होगा।

इसके अतिरिक्त, एक बहुत बड़ी स्थिरांक फ़ाइल जावा में विकास की गति को मार देती है क्योंकि स्थिरांक उन कक्षाओं में अंतर्निर्मित होते हैं जो उन्हें संकलन समय पर उपयोग करते हैं, इसलिए कोई भी परिवर्तन उन सभी फ़ाइलों और उन पर निर्भर सभी के पुनर्संयोजन को मजबूर करता है। यदि आपके पास हर जगह उपयोग किए जाने वाले स्थिरांक के साथ एक फ़ाइल है, तो आप बड़े पैमाने पर वृद्धिशील संकलन का लाभ खो देते हैं: ग्रहण को 15 मिनट तक लॉक करके देखें क्योंकि यह उस फ़ाइल में हर परिवर्तन के लिए आपकी पूरी परियोजना को फिर से खोलता है। और चूंकि उस फ़ाइल में कहीं भी उपयोग किए जाने वाले सभी स्थिरांक हैं, आप इसे अक्सर बदलते रहेंगे। हां, मैं निजी अनुभव से बोल रहा हूं।

Comments

मुझे विकास के पर्यावरण पर संभावित प्रभाव के बारे में पता नहीं था, और मुझे लगता है कि नेस्टेड क्लास दृष्टिकोण उस के साथ बहुत मदद नहीं करेगा, है ना?

— FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner: यह इस बात पर निर्भर करता है कि वृद्धिशील संकलन तंत्र लेखन क्षमता पर कितना प्रयास करता है।

— माइकल बोर्गवर्ड

Answer 3

तुम सही हो। आपका सुझाव एक प्रोग्रामर को अनुमति देता हैimport static Constants.BankAccount.* 'BANKACCOUNT_' के अनगिनत पुनरावृत्तियों को समाप्त । कॉनकटेशन वास्तविक स्कूपिंग के लिए एक खराब विकल्प है। उन्होंने कहा, मैं टीम की संस्कृति को बदलने के लिए आपसे बहुत अधिक आशा नहीं रखता। उनके पास उचित प्रथाओं की धारणा है, और यदि आप उन्हें 100 विशेषज्ञों को दिखाते हैं, तो भी वे बदलने की संभावना नहीं रखते हैं।

मैं यह भी सोच रहा हूं कि आपके पास एक ही 'कॉन्स्टैंट' फाइल क्यों है। यह बहुत बुरा अभ्यास है, जब तक कि ये स्थिरांक किसी भी तरह से संबंधित नहीं हैं और बहुत स्थिर हैं। आम तौर पर यह एक तरह का किचन-सिंक क्लास बन जाता है जो लगातार बदलता रहता है और हर चीज पर निर्भर होता है।

Comments

हमारे पास वर्तमान में एक कॉन्स्टेंट फ़ाइल है जिसमें अधिकांश UI- फ़ील्ड आईडी कॉन्स्टेंट हैं, और कुछ अन्य कॉन्स्टेंट फाइल हैं जो सबप्रोजेक्ट-विशिष्ट हैं। लेकिन अब, सबप्रोजेक्ट-विशिष्ट स्थिरांक को अन्य संबंधित उपप्रोजेक्ट द्वारा उपयोग करने की आवश्यकता होती है, ताकि यही विचार उन सभी को एक "मास्टर" स्थिरांक फ़ाइल में विलय करने के लिए प्रेरित करे। जो अब से बेहतर है क्योंकि कभी-कभी मुझे यह भी नहीं पता होता है कि कौन से स्थिरांक एक मान के लिए संदर्भ देने के लिए फाइल करते हैं, और किसी अन्य व्यक्ति ने एक स्थिरांक की डुप्लिकेट बनाई क्योंकि वे इसे एक अलग उपप्रोजेक्ट के स्थिरांक फ़ाइल में नहीं ढूंढ सकते हैं।

— FrustratedWithFormsDesigner 20

एक स्थिरांक वर्ग जो लगातार बदल रहा है ... वहाँ कुछ ज़ेन है, अगर आप पर्याप्त रूप से खुदाई करते हैं।

— KChaloux

@FrustratedWithFormsDesigner: UI- फ़ील्ड आईडी? पता नहीं कहाँ एक मूल्य खोजने के लिए? डब्ल्यूटीएफ के विशाल ढेर की तरह लगता है। आपको मेरी सहानुभूति है।

— केविन क्लाइन

Answer 4

दोनों दृष्टिकोण काम करते हैं, और यही दिन के अंत में महत्वपूर्ण है।

उस ने कहा, आपके दृष्टिकोण को एक पैटर्न माना जाना काफी आम है, या निरंतर इंटरफ़ेस विरोधी पैटर्न पर अधिक सटीक रूप से एक अच्छा पर्याप्त सुधार है । मैं नहीं देखता कि इसके बारे में क्या जटिल है, लेकिन यह एक चर्चा है जो आपको अपनी टीम के साथ होनी चाहिए।

Comments

स्थिरांक की एक लंबी पर्याप्त सूची के लिए, मैं उन सभी को एक ही कक्षा में रखने के लिए लगातार इंटरफेस पसंद करूंगा। ऑटो से गलत को चुनना खतरनाक रूप से संभव है। बेशक, यह इस बात पर निर्भर करता है कि कब तक पर्याप्त है :)

— गोरान जोविक

@GoranJovic हर विरोधी पैटर्न किसी न किसी तरह से उपयोगी है (या कम से कम सुविधाजनक), अगर यह नहीं था तो यह एक पैटर्न नहीं बनेगा।

— यानि

Answer 5

स्थिरांक की लंबी सूची के साथ चुनौतियों में से एक का उपयोग करने के लिए "सही" निरंतर मिल रहा है। वास्तव में, कोई व्यक्ति इसे उस समूह से जोड़ने के बजाय पंक्ति के अंत में एक स्थिर बनाता है।

जो आपकी टीम के साथ चर्चा करने के लिए एक और बिंदु लाता है - पहले से ही उनके नामों के माध्यम से स्थिरांक का एक वास्तविक वर्गीकरण है। तो यह वास्तव में वर्तमान स्थिति से उनके लिए एक बड़ी पारी नहीं होनी चाहिए जो आप प्रस्तावित कर रहे हैं। ऑटो-कम्प्लीट का उपयोग लगातार लुक-अप को और भी आसान बनाता है।

यदि कुछ भी हो, तो आपका सुझाव "गलत" निरंतर का उपयोग करके हतोत्साहित करने में मदद करता है, भले ही वह किसी विशेष स्थिति में फिट हो। एक प्रतिनिधि वर्ग के भीतर स्थिरांक को लपेटकर, यह डेवलपर्स को यह सोचने के लिए प्रोत्साहित करेगा कि क्या वे इसका उपयोग कर रहे हैं। उदाहरण के लिए, अगर मैं CreditCard.SomeConstantसामान्य उपयोग के लिए खींचता हूं, तो मुझे वास्तव में आश्चर्य होना चाहिए कि General.SomeConstantइसके बजाय उस स्थिति के लिए क्यों नहीं है ।

मैं स्थिरांक की राक्षस मात्रा के साथ परियोजनाओं पर रहा हूं, और मैं उस विधि को पसंद करना चाहता हूं जो आप सुझा रहे हैं। यह क्लीनर, अधिक प्रत्यक्ष है, और यह अनजाने उपयोग से बचने में मदद करता है।

Answer 6

मैं यह कभी-कभार (C # में) करता हूं, खासकर अगर मुझे एक प्रसिद्ध और निश्चित एक्सएमएल संरचना के खिलाफ / पार्स के खिलाफ कार्यक्रम करने की आवश्यकता है या कुछ इसी तरह से नेस्टेड और स्ट्रिंग भारी ... उदाहरण के लिए एक कस्टम कॉन्फ़िगरेशन ब्लॉक पार्सर।

मैं एक नेस्टेड वर्ग संरचना का निर्माण करता हूं, जो XML w / श्रेणी के नामों की पदानुक्रमित संरचना से मेल खाता है, जो एक कॉन्स्टेंट स्ट्रिंग "ElementName" संपत्ति से संबंधित तत्वों और प्रत्येक गुण (यदि कोई हो) के अनुरूप एक समान संपत्ति है।

इससे संबंधित Xml के खिलाफ प्रोग्राम करना बहुत आसान हो जाता है।