क्या कक्षा में हार्डकोड सेटिंग्स के लिए यह बुरा है?

Question

मेरे पास कॉन्फ़िगरेशन की एक सरणी है कि जब वे भविष्य में संभवतः बदल सकते हैं, तो संभावना है कि उन्हें कभी भी बदला नहीं जाना पड़ेगा।

यदि कोई गुम या गलत है तो मेरे सिस्टम की एक निश्चित विशेषता सही ढंग से काम नहीं करेगी।

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

मैंने इस पर अधिक समय से मन बदलते हुए बिताया है।

Answer 1

डिज़ाइनर को बदलने की आवश्यकता की संभावना की संभावना का अनुमान निर्णय लेने के लिए एक विश्वसनीय मानदंड नहीं है, क्योंकि हमारे कार्यक्रमों के वास्तविक दुनिया के उपयोग में हमें गलत साबित करने के अनोखे तरीके हैं।

खुद से पूछने के बजाय "कुछ बदलने की संभावना क्या है?", खुद से पूछें "क्या यह अंत उपयोगकर्ता को बदलाव करने के लिए समझ में आता है?" अगर उत्तर "हां" है, तो इसे उपयोगकर्ता-परिवर्तनीय बनाएं; अन्यथा, इसे केवल अपने कोड के माध्यम से बदलने योग्य बनाएं।

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

Answer 2

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

Answer 3

सर्वोत्तम अभ्यास किसी भी तरह की कॉन्फ़िगरेशन या गुण फ़ाइल का उपयोग करना है और फ़ाइल को क्षतिग्रस्त/गायब होने पर डिफ़ॉल्ट मानों और विफलता का उपयोग करना है। ये दृष्टिकोण निम्न लाभ हैं:

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

नुकसान जटिलता है बिना मूलभूत मूल्यों के साथ काम करता है।

Answer 4

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

हालांकि, यदि ये सेटिंग्स उपयोगकर्ता कॉन्फ़िगर करने योग्य हैं, तो उन्हें हार्ड कोड नहीं किया जा सकता है, लेकिन इसके बजाय बाहरी स्रोत से पढ़ने की आवश्यकता है, और जहां आप इसे करते हैं, डिजाइन, जटिलता और सुरक्षा का विषय है।

सादा पाठ फ़ाइलें एक छोटे से आवेदन के लिए अच्छी हैं, जहां सुरक्षा ढीला है और चीजें सादा पाठ हैं। SublimeText संपादक और नोटपैड ++ संपादक अपनी थीम सेटिंग्स के लिए ऐसा करते हैं और यह अच्छी तरह से काम करता है। (मुझे विश्वास है कि यह सादा पाठ था, शायद वे अब एक्सएमएल में चले गए हैं)

एक बेहतर विकल्प एक्सएमएल है, क्योंकि यह संरचित है, पढ़ने/पार्स/लिखना आसान है। कई परियोजनाएं इसे एक विकल्प के रूप में उपयोग करती हैं। यदि कोई उपयोगकर्ता प्रोग्राम को बंद कर देता है या JVM किसी भी कारण से यादृच्छिक रूप से बाहर निकलता है, तो उन्हें पढ़ने/लिखने के दौरान भ्रष्ट फाइलें देखने की एक बात है। आप बफर जैसे चीजों को देखना चाह सकते हैं। और यदि फ़ाइल/xml फ़ाइल गुम है, तो FileNotFoundExceptions से भी निपटें।

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

Answer 5

कभी भी हार्ड कोड चीजें कभी नहीं "अगर" बदल सकती हैं, या आप बाद में खेद हो सकते हैं और दूसरों को पागल बना सकते हैं (बड़ी या/और ओपन सोर्स प्रोजेक्ट्स में बहुत अधिक संभावना है)। अगर कॉन्फ़िगर कभी नहीं बदलेगा, तो यह कॉन्फ़िगर नहीं है बल्कि स्थिर है।

कोड के साथ प्रयोग करते समय केवल हार्ड कोडिंग का उपयोग करें।

यदि आप सरल मानों को सहेजना चाहते हैं, तो आप उपयोगकर्ता जावा गुणों को कर सकते हैं।

उदाहरण के लिए HERE देखें।

शुभकामनाएं।

Answer 6

हां, यह निश्चित रूप से उन्हें कठिन कोड देने का एक बुरा विचार है; यदि कुछ और नहीं है, तो यह परीक्षण (चाहे स्वचालित या मैन्युअल) हो सकता है, उससे कहीं अधिक कठिन हो सकता है। सामान्य जार के साथ अपने जार में .properties फ़ाइल को शामिल करना आसान है, और भविष्य में उन्हें बदलने के लिए उन्हें रनटाइम पर ओवरराइड करने की आवश्यकता होगी। यदि आपके पास व्यवस्थित करने की लचीलापन है तो निर्भरता इंजेक्शन आमतौर पर एक बेहतर विकल्प होता है।

Answer 7

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

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