जावा में स्थिरांक को लागू करने का सबसे अच्छा तरीका क्या है? [बन्द है]

372

मैंने इस तरह के उदाहरण देखे हैं: 

public class MaxSeconds {
   public static final int MAX_SECONDS = 25;
}

और माना जाता है कि स्थिरांक को स्थिर करने की घोषणा करने के लिए मेरे पास एक कांस्टेंट वर्ग हो सकता है। मुझे पता है कि व्यावहारिक रूप से कोई जावा बिल्कुल नहीं है और मैं सोच रहा हूं कि क्या यह स्थिरांक बनाने का सबसे अच्छा तरीका है।

java  constants 
— mk।
स्रोत
1
सिर्फ जावा
— कॉन्स्टेंट
— बेसिल बोर्क

जवाबों:

403

यह पूरी तरह से स्वीकार्य है, शायद मानक भी।

(public/private) static final TYPE NAME = VALUE;

TYPEप्रकार कहां है, NAMEरिक्त स्थान के लिए अंडरस्कोर वाले सभी कैप्स में नाम है, और VALUEनिरंतर मूल्य है;

मैं अत्यधिक अपने कॉन्स्टेंट को अपनी कक्षाओं या इंटरफेस में न रखने की सलाह देता हूं।

एक साइड नोट के रूप में: चर जिन्हें अंतिम घोषित किया गया है और जो परिवर्तनशील हैं, उन्हें अभी भी बदला जा सकता है; हालाँकि, चर कभी भी एक अलग ऑब्जेक्ट पर इंगित नहीं कर सकता है।

उदाहरण के लिए:

public static final Point ORIGIN = new Point(0,0);

public static void main(String[] args){

    ORIGIN.x = 3;

}

यह कानूनी है और ORIGINफिर (3, 0) पर एक बिंदु होगा।

— jjnguy
स्रोत
19
आप 'स्थैतिक MaxSeconds.MAX_SECONDS आयात' भी कर सकते हैं इतना है कि आप इसे अधिकतम जादू करने की जरूरत नहीं है। MAX_SECONDS
— हारून Maenpaa
23
आयात स्थैतिक के बारे में पिछली टिप्पणी केवल जावा 5+ पर लागू होती है। कुछ लोगों को लगता है कि शॉर्टहैंड संभव भ्रम के लायक नहीं है, जहां से कॉन्स्टेंट आया था, जब लंबे कोड को पढ़ते हुए, MaxSeconds.MAX_SECONDS का पालन करना आसान हो सकता है फिर आयात करना और आयात को देखना।
— MetroidFan2002
5
चूँकि आप objetc को बदल सकते हैं जैसे कि jjnguy ने दिखाया है, सबसे अच्छा है अगर आपकी बाधाएं अपरिवर्तनीय वस्तुएं हैं या सिर्फ सादे आदिम / तार हैं।
— मार्कोस्पेरेरा
14
यदि आप इस प्रश्न को पढ़ रहे हैं, तो कृपया इस उत्तर को गंभीरता से लेने के बावजूद नीचे दिए गए अगले दो उत्तरों को पढ़ें, यदि यह गलत है तो यह विवादास्पद है।
— परिक्रमा
3
@jjnguy आप गलत नहीं हैं, लेकिन अगर मैं केवल प्रश्न और आपके उत्तर की पहली दो पंक्तियों को पढ़ता हूं, तो मैं इस धारणा के अधीन रहूंगा कि "एक कॉन्स्टेंट क्लास" "पूरी तरह से स्वीकार्य है, शायद मानक भी"। यही कारण है कि धारणा है गलत।
— ज़ैक लिसोबेई
235

मैं एक ही स्थिरांक वर्ग के खिलाफ अत्यधिक सलाह दूंगा। यह उस समय एक अच्छा विचार हो सकता है, लेकिन जब डेवलपर्स दस्तावेज़ स्थिरांक से इनकार करते हैं और वर्ग 500 स्थिरांक से ऊपर की ओर बढ़ता है, जो सभी एक दूसरे से संबंधित नहीं हैं (आवेदन के पूरी तरह से अलग पहलुओं से संबंधित होने के नाते), यह आम तौर पर स्थिरांक फ़ाइल में पूरी तरह से अपठनीय होने के रूप में बदल जाता है। बजाय:

  • यदि आपके पास जावा 5+ तक पहुंच है, तो एप्लिकेशन क्षेत्र के लिए अपने विशिष्ट स्थिरांक को परिभाषित करने के लिए एनम का उपयोग करें। आवेदन क्षेत्र के सभी हिस्सों को इन स्थिरांक के लिए, निरंतर मानों का उल्लेख नहीं करना चाहिए। आप जिस तरह से एक वर्ग की घोषणा करते हैं, आप उसी तरह एक एनम की घोषणा कर सकते हैं। Enums शायद जावा 5+ की सबसे (और, यकीनन, केवल) उपयोगी विशेषता है।
  • यदि आपके पास स्थिरांक हैं जो केवल एक विशेष वर्ग या उसके किसी उपवर्ग के लिए मान्य हैं, तो उन्हें या तो संरक्षित या सार्वजनिक घोषित करें और उन्हें शीर्ष श्रेणी में पदानुक्रम में रखें। इस तरह, उपवर्ग इन निरंतर मूल्यों तक पहुंच सकते हैं (और यदि अन्य वर्ग उन्हें सार्वजनिक रूप से एक्सेस करते हैं, तो स्थिरांक केवल एक विशेष वर्ग के लिए मान्य नहीं हैं ... जिसका अर्थ है कि इस निरंतर का उपयोग करने वाले बाहरी वर्ग बहुत कसकर युग्मित हो सकते हैं वर्ग जिसमें स्थिर है)
  • यदि आपके पास परिभाषित व्यवहार वाला इंटरफ़ेस है, लेकिन लौटाया गया मान या तर्क मान विशेष रूप से होना चाहिए, तो उस इंटरफ़ेस पर स्थिरांक को परिभाषित करना पूरी तरह से स्वीकार्य है ताकि अन्य कार्यान्वयनकर्ताओं तक उनकी पहुंच हो। हालांकि, केवल स्थिरांक रखने के लिए एक इंटरफ़ेस बनाने से बचें: यह सिर्फ उतना ही बुरा हो सकता है जितना कि एक वर्ग बस स्थिरांक बनाए।
— MetroidFan2002
स्रोत
12
पूरी तरह से सहमत ... यह बड़ी परियोजनाओं के लिए एक शास्त्रीय विरोधी पैटर्न के रूप में प्रलेखित किया जा सकता है।
— दास
30
विषय से बाहर, लेकिन ... जेनेरिक निश्चित रूप से परिपूर्ण नहीं हैं, लेकिन मुझे लगता है कि आप उनके लिए जावा 5 की एक उपयोगी विशेषता के लिए एक बहुत अच्छा मामला बना सकते हैं :)
— मार्टिन मैकएनकेन
3
@ ŁukaszL। यह प्रश्न वास्तव में राय आधारित है (जब भी "सर्वश्रेष्ठ" उत्पन्न होता है, तो यह आम तौर पर राय का विषय होता है), इसलिए उत्तर इस प्रश्न का एक मान्य उत्तर है। मैंने एक उत्तर दिया है कि क्या (हाँ, मुझे विश्वास है, इसलिए हाँ यह एक राय है, क्योंकि समय के साथ फिर से "सबसे अच्छा" परिवर्तन होता है और आम तौर पर राय आधारित होता है) जावा में स्थिरांक को लागू करने का सबसे अच्छा तरीका है।
— MetroidFan2002
1
उपरोक्त विकल्पों में से कोई भी आपको एक सच्चा वैश्विक चर नहीं देता है। क्या होगा अगर मेरे पास ऐसा कुछ है जो हर जगह उपयोग किया जाता है, लेकिन एक एनम नहीं है? क्या मैं सिर्फ एक चीज की एक कल्पना करता हूं?
— markthegrea
1
यदि आपको एक वैश्विक स्थिरांक की आवश्यकता है जो सभी मॉड्यूलों को फैलाता है, तो संभवतः आपकी डिजाइन रणनीति में कुछ गड़बड़ है। यदि आपको वास्तव में एक वैश्विक स्थिरांक की आवश्यकता है, तो शीर्ष स्तर के पैकेज में इसके लिए एक सार्वजनिक अंतिम वर्ग बनाएं और इसे वहां चिपका दें। फिर इसे हटा दें जैसे ही आपको पता चलता है कि आपकी सभी कक्षाओं को वास्तव में उस स्थिरांक की आवश्यकता नहीं है, और इसे उस पैकेज में स्थानांतरित करें जो इसे सबसे अधिक संदर्भित करता है। आप पैकेजों में एक निरंतरता साझा कर सकते हैं, लेकिन यह एक वैश्विक गंध की आवश्यकता के लिए एक कोड गंध है जो कि एक एन्यूमरेटेड प्रकार नहीं है, क्योंकि एन्यूमरेटेड प्रकारों में व्यवहार हो सकता है, लेकिन एक स्ट्रिंग एक स्ट्रिंग है, एक इंट एक int है, आदि
— Metroidxan2002
120

यह केवल स्थिरांक ( जोश बलोच द्वारा निरंतर इंटरफ़ेस पैटर्न नाम) को पकड़ने के लिए इंटरफेस का उपयोग करने के लिए एक बुरा अभ्यास है । यहाँ जोश की सलाह है:

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

उदाहरण:

// Constant utility class
package com.effectivejava.science;
public class PhysicalConstants {
    private PhysicalConstants() { }  // Prevents instantiation

    public static final double AVOGADROS_NUMBER   = 6.02214199e23;
    public static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
    public static final double ELECTRON_MASS      = 9.10938188e-31;
}

नामकरण सम्मेलन के बारे में:

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

— मार्सिओ अगुइर
स्रोत
23
यदि आप कुछ बुरा अभ्यास करने जा रहे हैं, तो शायद आपको यह समझाना चाहिए कि आप ऐसा क्यों सोचते हैं?
— ग्लेनस
14
यह एक पुरानी पोस्ट है, लेकिन abstractनिजी कंस्ट्रक्टर के बजाय क्लास के लिए नोटेशन का उपयोग करना बेहतर है ।
— Xtreme बाइकर
5
मैट, जबकि बाइकर की सिफारिश झूठी नहीं है, मैं अमूर्त कक्षाओं के बजाय अंतिम वर्गों की वकालत करूंगा। यह कहने में बाइकर की बात यह थी कि आप यह सुनिश्चित करना चाहते हैं कि आपका स्थिरांक वर्ग परिवर्तनशील नहीं है। इसलिए, इसे अंतिम रूप में चिह्नित करके, आप इसे उप-वर्गीकृत या त्वरित करने की अनुमति नहीं दे रहे हैं। यह अपनी स्थैतिक कार्यक्षमता को घेरने में भी मदद करता है और अन्य डेवलपर्स को इसे उप-वर्ग करने की अनुमति नहीं देता है और यह उन चीजों को करने देता है जो इसे करने के लिए डिज़ाइन नहीं किया गया था।
— liltitus27 15
7
@XtremeBiker abstractएक निजी कंस्ट्रक्टर के बजाय कक्षा को चिह्नित करना पूरी तरह से तात्कालिकता को नहीं रोकता है, क्योंकि कोई इसे उप-वर्ग में बदल सकता है और उपवर्ग को तात्कालिक कर सकता है (ऐसा नहीं है कि ऐसा करना एक अच्छा विचार है, लेकिन यह संभव है)। @ToolmakerSteve आप किसी क्लास को किसी प्राइवेट कंस्ट्रक्टर के साथ नहीं कर सकते (कम से कम बिना किसी बड़ी हैक के), क्योंकि सबक्लास के कंस्ट्रक्टर को अपने सुपरक्लास के कंस्ट्रक्टर (अब प्राइवेट) को कॉल करना होगा। इसलिए, इसे चिह्नित करना finalअनावश्यक है (लेकिन शायद अधिक स्पष्ट है)।
— इस
3
केवल स्थिरांक रखने के लिए कक्षा का उपयोग करना और भी बदतर है। यदि आप कभी भी उस वर्ग की वस्तु नहीं बनाना चाहते हैं तो आप पहली कक्षा में नियमित कक्षा का उपयोग क्यों करते हैं ?
— मैक्सजूम
36

प्रभावी जावा (द्वितीय संस्करण) में, यह अनुशंसा की जाती है कि आप स्थिरांक के लिए स्थैतिक ints के बजाय enums का उपयोग करें।

यहाँ जावा में enums पर एक अच्छा राइटअप है: http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html

ध्यान दें कि उस लेख के अंत में प्रश्न प्रस्तुत है:

तो आपको एनम का उपयोग कब करना चाहिए?

के उत्तर के साथ:

किसी भी समय आपको स्थिरांक का एक निश्चित सेट चाहिए

— shelfoo
स्रोत
21

बस एक इंटरफ़ेस का उपयोग करने से बचें:

public interface MyConstants {
    String CONSTANT_ONE = "foo";
}

public class NeddsConstant implements MyConstants {

}

यह लुभावना है, लेकिन इनकैप्सुलेशन का उल्लंघन करता है और वर्ग परिभाषाओं के भेद को धुंधला करता है।

1
वास्तव में स्थैतिक आयात बहुत बेहतर हैं।
— हारून मेनापा
1
यह अभ्यास इंटरफेस का एक अजीब उपयोग है, जिसका उद्देश्य एक वर्ग द्वारा प्रदान की गई सेवाओं को बताना है।
— राफा रोमेरो
1
मैं स्थिरांक के लिए इंटरफ़ेस के उपयोग से बचने से असहमत नहीं हूं, लेकिन आपका उदाहरण मुझे लगता है कि भ्रामक है। आपको इंटरफ़ेस तक पहुँच प्राप्त करने के लिए इंटरफ़ेस को लागू करने की आवश्यकता नहीं है क्योंकि इसके निहित स्थिर, सार्वजनिक और अंतिम हैं। तो, आपके द्वारा वर्णित यहाँ की तुलना में सरल है।
— djangofan
यह सच है ... यह इनकैप्सुलेशन का उल्लंघन कर रहा है, मैं अंतिम कॉन्स्टेंट वर्ग का उपयोग करना पसंद करता हूं जो कि अधिक वस्तु को उन्मुख रूप से देखता है और इंटरफ़ेस या एनम पर बेहतर होता है । नोट: Android की जरूरत नहीं है के मामले में Enum से बचा जा सकता है।
— CoDe
19

मैं निम्नलिखित दृष्टिकोण का उपयोग करता हूं:

public final class Constants {
  public final class File {
    public static final int MIN_ROWS = 1;
    public static final int MAX_ROWS = 1000;

    private File() {}
  }

  public final class DB {
    public static final String name = "oups";

    public final class Connection {
      public static final String URL = "jdbc:tra-ta-ta";
      public static final String USER = "testUser";
      public static final String PASSWORD = "testPassword";

      private Connection() {}
    }

    private DB() {}
  }

  private Constants() {}
}

उदाहरण के लिए, मैं Constants.DB.Connection.URLनिरंतर प्राप्त करने के लिए उपयोग करता हूं । यह मेरे लिए और अधिक "ऑब्जेक्ट ओरिएंटेड" दिखता है।

— albus.ua
स्रोत
4
दिलचस्प है, लेकिन बोझिल। इसके बजाय आप क्लास में स्थिरांक पैदा नहीं करेंगे, क्योंकि वे दूसरों के साथ मिलकर अनुशंसित हैं? उदाहरण के लिए, आपके DB कोड में कहीं और आपके कनेक्शन के लिए आधार वर्ग है? उदाहरण के लिए "ConnectionBase"। फिर आप वहां स्थिरांक लगा सकते हैं। कोई भी कोड जो कनेक्शन के साथ काम कर रहा है, उसके पास पहले से ही एक आयात की संभावना होगी, जो कि "कॉन्स्टैंट्स.बीडी.कॉन्ने.उर्ल" के बजाय "ConnectionBase.URL" कह सकते हैं।
— टूलमेकरसेव जूल 22'14
3
@ToolmakerSteve लेकिन उन सामान्य स्थिरांक के बारे में जो कई वर्गों का उपयोग कर सकते हैं? उदाहरण के लिए, शैलियों, वेब सेवाओं के यूआरएल, आदि ...?
— डेनियल गोमेज़ रिको
सभी स्थिरांक को एक कक्षा में रखने से एक फायदा होता है - रखरखाव। आपको हमेशा पता है कि स्थिरांक कहां खोजना है। मैं यह नहीं कह रहा हूं कि यह तकनीक बेहतर है, मैं सिर्फ एक लाभ प्रदान कर रहा हूं। और @ अल्बस्यू ने जो किया है, उसके स्थिरांक को वर्गीकृत किया गया है, जो कि एक बहुत अच्छा विचार है, खासकर यदि स्थिरांक वर्ग में कई निरंतर मूल्य हैं। यह तकनीक कक्षा को प्रबंधनीय रखने में मदद करेगी और स्थिरांक के उद्देश्य का बेहतर वर्णन करने में मदद करेगी।
— नेल्दा.टेकस्पैरेसी
17

एक अलग वर्ग में स्थिर अंतिम स्थिरांक बनाना आपको परेशानी में डाल सकता है। जावा कंपाइलर वास्तव में इसे ऑप्टिमाइज़ करेगा और निरंतर के वास्तविक मूल्य को किसी भी वर्ग में रखेगा जो इसे संदर्भित करता है।

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

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

— केविन डे
स्रोत
इस उत्कृष्ट चेतावनी के लिए +1। (यदि आप इसकी स्थायी गारंटी नहीं दे सकते हैं, तो इसके बजाय एक गेट्टर पर विचार करें, जैसे कि big_peanut_horse उल्लेख।) यही बात C # में कास्ट के साथ लागू होती है, वैसे: msdn.microsoft.com/en-us/library/6w8fe1b.aspx
— जॉन Coombs
13

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

इसके बजाय, स्थिरांक को कक्षा में जाना चाहिए जो उन्हें "मालिक" करता है। क्या आपके पास एक स्थिर समय कहा जाता है? यह शायद आपके संचार () या कनेक्शन () वर्ग में जाना चाहिए। MAX_BAD_LOGINS_PER_HOUR? उपयोगकर्ता में जाता है ()। इत्यादि इत्यादि।

अन्य संभावित उपयोग जावा है। जब फाइल "स्थिरांक" को रन-टाइम पर परिभाषित किया जा सकता है, लेकिन आसानी से उपयोगकर्ता परिवर्तनशील नहीं होता है। आप इन्हें अपने .jars में पैकेज कर सकते हैं और उन्हें क्लास रिसोर्सलॉडर के साथ संदर्भ दे सकते हैं।

— यान रमान
स्रोत
और निश्चित रूप से, आप कभी भी एक से अधिक वर्ग से एक का उपयोग नहीं करना चाहते हैं, या एक वर्ग के शीर्ष पर अव्यवस्था से बचना चाहते हैं।
— ऑर्बफ़िश
6

यही सही रास्ता है।

आम तौर पर कॉन्स्टेंट को अलग "कॉन्स्टेंट" वर्गों में नहीं रखा जाता है क्योंकि वे खोज योग्य नहीं होते हैं। यदि निरंतर वर्तमान वर्ग के लिए प्रासंगिक है, तो उन्हें वहां रखने से अगले डेवलपर को मदद मिलती है।

— जेसन कोहेन
स्रोत
5

मैं स्थिरांक के बजाय गेटर्स का उपयोग करना पसंद करता हूं। वे गेटर्स निरंतर मानों को वापस कर सकते हैं, उदाहरण के लिए public int getMaxConnections() {return 10;}, लेकिन कुछ भी जो निरंतर की आवश्यकता है, एक गेटर के माध्यम से जाएगा।

एक लाभ यह है कि यदि आपका प्रोग्राम स्थिरांक को बढ़ाता है - आप पाते हैं कि इसे कॉन्फ़िगर करने की आवश्यकता है - आप बस यह बदल सकते हैं कि कैसे प्राप्तकर्ता स्थिर लौटे।

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

— big_peanut_horse
स्रोत
5
अच्छी तरह से रेफरेंसिंग क्लासेस को फिर से शुरू करना 21 वीं सदी में शायद ही बोझ हो। और आपको सदस्य चर की पहुंच और परिवर्तन के अलावा अन्य चीजों के लिए एक्सेसर / म्यूटेटर (गेट्टर / सेटर) मॉडल का उपयोग कभी नहीं करना चाहिए । कॉन्सेप्ट्स का तात्पर्य प्रकृति में तात्कालिक रूप से होना है, जबकि गेटटर / सेटर राज्य को संभालने के लिए हैं । इसके अलावा, आप केवल भ्रम के लिए पूछ रहे हैं: लोगों को केवल एक स्थिर उपज के लिए एक गटर की उम्मीद नहीं होगी।
5

मैं सहमत हूं कि इंटरफ़ेस का उपयोग करना जाने का तरीका नहीं है। बलोच के इफेक्टिव जावा में भी इस पैटर्न से बचने का अपना खुद का आइटम (# 18) है ।

एक तर्क बलोच निरंतर इंटरफेस पैटर्न के खिलाफ बनाता है कि स्थिरांक का उपयोग एक कार्यान्वयन विवरण है, लेकिन उनका उपयोग करने के लिए एक इंटरफ़ेस को लागू करना आपके निर्यात एपीआई में उस कार्यान्वयन विस्तार को उजागर करता है।

public|private static final TYPE NAME = VALUE;पैटर्न एक निरंतर घोषित करने का एक अच्छा तरीका है। व्यक्तिगत रूप से, मुझे लगता है कि आपके सभी स्थिरांक को अलग करने के लिए एक अलग वर्ग बनाने से बचना बेहतर है, लेकिन मैंने ऐसा कभी नहीं किया है, यह व्यक्तिगत पसंद और शैली के अलावा नहीं है।

अपने स्थिरांक एक गणन के रूप में अच्छी तरह से तैयार किया जा सकता है, तो विचार करना enum संरचना 1.5 या बाद में उपलब्ध है।

यदि आप 1.5 से पहले के संस्करण का उपयोग कर रहे हैं, तो आप अभी भी सामान्य जावा कक्षाओं का उपयोग करके टाइपफोर एन्यूमरेशन्स को खींच सकते हैं। ( इस साइट को उस पर और देखें )।

— रोब डिकसन
स्रोत
API को कॉल करने के लिए कुछ स्थिरांक का उपयोग किया जा सकता है। उदाहरण के लिए, देखें इंटरफ़ेस org.springframework.transaction.TransactionDefinition। इसमें int PROPAGATION_REQUIRED = 0 जैसे स्थिरांक की सूची है;
— बोरबाज
मुझे पता है कि यह पुराना है, लेकिन बलोच के इफेक्टिव जावा का लिंक टूट गया है। क्या आप कोई अन्य या कोई अन्य संदर्भ प्रदान कर सकते हैं जो "कृपया इंटरफ़ेस का उपयोग करने का तरीका नहीं है"?
— नेल्दा.टेकस्पैरेसी
4

उपरोक्त टिप्पणियों के आधार पर मुझे लगता है कि यह पुराने ज़माने की वैश्विक स्थिर श्रेणी (सार्वजनिक स्थिर अंतिम चर वाले) को अपने एनम-जैसे समकक्ष के रूप में बदलने का एक अच्छा तरीका है:

public class Constants {

    private Constants() {
        throw new AssertionError();
    }

    public interface ConstantType {}

    public enum StringConstant implements ConstantType {
        DB_HOST("localhost");
        // other String constants come here

        private String value;
        private StringConstant(String value) {
            this.value = value;
        }
        public String value() {
            return value;
        }
    }

    public enum IntConstant implements ConstantType {
        DB_PORT(3128), 
        MAX_PAGE_SIZE(100);
        // other int constants come here

        private int value;
        private IntConstant(int value) {
            this.value = value;
        }
        public int value() {
            return value;
        }
    }

    public enum SimpleConstant implements ConstantType {
        STATE_INIT,
        STATE_START,
        STATE_END;
    }

}

तो फिर मैं उन्हें पसंद करने के लिए उल्लेख कर सकता हूं:

Constants.StringConstant.DB_HOST
— लोरैंड बेंडिग
स्रोत
4
क्यों? वह सुधार कैसे है? हर संदर्भ अब बोझिल है (कांस्टेंट। सिटिंगकॉन्स्टेंट.शोवर)। IMHO, आप यहाँ एक ऊबड़ सड़क नीचे जा रहे हैं।
— टूलमेकरसेव जुले
3

एक अच्छी वस्तु उन्मुख डिजाइन को कई सार्वजनिक रूप से उपलब्ध स्थिरांक की आवश्यकता नहीं होनी चाहिए। अधिकांश कॉन्स्टेंटों को उस वर्ग में एनकैप्सुलेट किया जाना चाहिए जो उन्हें अपना काम करने की आवश्यकता है।

— ब्रैडली हैरिस
स्रोत
1
या कंस्ट्रक्टर के माध्यम से उस वर्ग में इंजेक्ट किया जाता है।
— डब्ल्यूडब्ल्यू।
2

इसका उत्तर देने के लिए एक निश्चित राशि है। शुरुआत करने के लिए, जावा में स्थिरांक को आम तौर पर सार्वजनिक, स्थिर और अंतिम घोषित किया जाता है। नीचे कारण हैं:

public, so that they are accessible from everywhere
static, so that they can be accessed without any instance. Since they are constants it
  makes little sense to duplicate them for every object.
final, since they should not be allowed to change

मैं कभी भी किसी CONSTANTS एक्सेसर / ऑब्जेक्ट के लिए इंटरफ़ेस का उपयोग नहीं करूंगा क्योंकि इंटरफेस आमतौर पर लागू होने की उम्मीद है। यह हास्यास्पद नहीं लगेगा:

String myConstant = IMyInterface.CONSTANTX;

इसके बजाय मैं कुछ छोटे व्यापारों के आधार पर कुछ अलग तरीकों के बीच चयन करूंगा, और इसलिए यह इस पर निर्भर करता है कि आपको क्या चाहिए:

1.  Use a regular enum with a default/private constructor. Most people would define 
     constants this way, IMHO.
  - drawback: cannot effectively Javadoc each constant member
  - advantage: var members are implicitly public, static, and final
  - advantage: type-safe
  - provides "a limited constructor" in a special way that only takes args which match
     predefined 'public static final' keys, thus limiting what you can pass to the
     constructor

2.  Use a altered enum WITHOUT a constructor, having all variables defined with 
     prefixed 'public static final' .
  - looks funny just having a floating semi-colon in the code
  - advantage: you can JavaDoc each variable with an explanation
  - drawback: you still have to put explicit 'public static final' before each variable
  - drawback: not type-safe
  - no 'limited constructor'

3.  Use a Class with a private constructor:
  - advantage: you can JavaDoc each variable with an explanation
  - drawback: you have to put explicit 'public static final' before each variable
  - you have the option of having a constructor to create an instance
     of the class if you want to provide additional functions related
     to your constants 
     (or just keep the constructor private)
  - drawback: not type-safe

4. Using interface:
  - advantage: you can JavaDoc each variable with an explanation
  - advantage: var members are implicitly 'public static final'
  - you are able to define default interface methods if you want to provide additional
     functions related to your constants (only if you implement the interface)
  - drawback: not type-safe
— djangofan
स्रोत
2

जावा में स्थिरांक को लागू करने का सबसे अच्छा तरीका क्या है?

एक दृष्टिकोण जो हमें वास्तव में बचना चाहिए : स्थिरांक को परिभाषित करने के लिए इंटरफेस का उपयोग करना।

स्थिरांक घोषित करने के लिए विशेष रूप से एक इंटरफ़ेस बनाना वास्तव में सबसे खराब बात है: यह इस कारण को पराजित करता है कि इंटरफेस क्यों डिज़ाइन किए गए थे: परिभाषित करने का तरीका (s) अनुबंध।

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

सरल बनाने के लिए, हमारे पास मोटे तौर पर 4 वैध दृष्टिकोण हैं ।

static final String/Integerफ़ील्ड के साथ :

  • 1) एक ऐसे वर्ग का उपयोग करना जो अंदर ही नहीं बल्कि स्थिरांक की भी घोषणा करता है।
  • 1 प्रकार) केवल स्थिर घोषित करने के लिए समर्पित एक वर्ग बना रहा है।

के साथ Java 5 enum:

  • 2) संबंधित उद्देश्य वर्ग (इसलिए एक नेस्टेड वर्ग) में एनम की घोषणा करना।
  • 2 वैरिएंट) एक स्टैंडअलोन क्लास के रूप में एनम का निर्माण करना (इसलिए इसकी अपनी क्लास फाइल में परिभाषित किया गया है)।

TLDR: जो सबसे अच्छा तरीका है और जहां स्थिरांक का पता लगाता है?

अधिकांश मामलों में, enum तरह से शायद की तुलना में बेहतर है static final String/Integerजिस तरह से और व्यक्तिगत रूप से मुझे लगता है कि static final String/Integerजिस तरह से इस्तेमाल किया जाना चाहिए केवल अगर हम अच्छे कारणों enums का उपयोग नहीं किया है।
और जहां हमें निरंतर मूल्यों की घोषणा करनी चाहिए, इस बारे में विचार करना है कि क्या एक एकल मौजूदा वर्ग है जो निरंतर मूल्यों के साथ एक विशिष्ट और मजबूत कार्यात्मक सामंजस्य रखता है। यदि हमें ऐसा कोई वर्ग मिल जाता है, तो हमें इसे स्थिरांक धारक के रूप में उपयोग करना चाहिए । अन्यथा, स्थिरांक किसी एक विशेष वर्ग से जुड़ा होना चाहिए।

static final String/ static final Integerबनामenum

Enums का उपयोग वास्तव में दृढ़ता से विचार करने का एक तरीका है।
एनमों को अधिक Stringया Integerनिरंतर क्षेत्र में बहुत फायदा होता है ।
उन्होंने एक मजबूत संकलन बाधा निर्धारित की। यदि आप एक ऐसी विधि को परिभाषित करते हैं जो एनम को पैरामीटर के रूप में लेती है, तो आप केवल एनम क्लास (या अशक्त) में परिभाषित एनम मान पारित कर सकते हैं।
स्ट्रिंग और इंटेगर के साथ आप उन्हें संगत प्रकार के किसी भी मान के साथ स्थानापन्न कर सकते हैं और यदि मूल्य static final String/ static final Integerक्षेत्रों में परिभाषित स्थिरांक नहीं है तो भी संकलन ठीक रहेगा ।

उदाहरण के लिए, एक वर्ग के रूप में परिभाषित दो स्थिरांक नीचे static final Stringखेतों में:

public class MyClass{

   public static final String ONE_CONSTANT = "value";
   public static final String ANOTHER_CONSTANT = "other value";
   . . .
}

यहाँ एक विधि है जो पैरामीटर के रूप में इनमें से एक स्थिरांक की अपेक्षा करती है:

public void process(String constantExpected){
    ...    
}

आप इसे इस तरह से लागू कर सकते हैं:

process(MyClass.ONE_CONSTANT);

या 

process(MyClass.ANOTHER_CONSTANT);

लेकिन कोई भी संकलन बाधा आपको इस तरह से आने से रोकता है:

process("a not defined constant value");

आपके पास केवल रनटाइम पर त्रुटि होगी और यदि आप एक समय में संचरित मूल्य पर एक चेक करते हैं।

Enum के साथ, चेकों की आवश्यकता नहीं होती है क्योंकि ग्राहक केवल एक enum पैरामीटर में एक enum मान पारित कर सकता है।

उदाहरण के लिए, यहाँ एक एनम वर्ग में परिभाषित दो मान (इसलिए बॉक्स से बाहर):

public enum MyEnum {

    ONE_CONSTANT("value"), ANOTHER_CONSTANT(" another value");

    private String value;

    MyEnum(String value) {
       this.value = value;
    }
         ...
}

यहाँ एक विधि है जो पैरामीटर के रूप में इन एनम मानों में से एक होने की उम्मीद करती है:

public void process(MyEnum myEnum){
    ...    
}

आप इसे इस तरह से लागू कर सकते हैं:

process(MyEnum.ONE_CONSTANT);

या 

process(MyEnum.ANOTHER_CONSTANT);

लेकिन संकलन कभी भी आपको इस तरह से आमंत्रित करने की अनुमति नहीं देगा:

process("a not defined constant value");

हमें स्थिरांक की घोषणा कहां करनी चाहिए?

यदि आपके आवेदन में एकल मौजूदा वर्ग है जो निरंतर मूल्यों के साथ एक विशिष्ट और मजबूत कार्यात्मक सामंजस्य रखता है, तो 1) और 2) बहुत सहज दिखाई देते हैं।
आमतौर पर, यह स्थिरांक के उपयोग को आसान बनाता है अगर ये मुख्य वर्ग में घोषित किए जाते हैं जो उन्हें हेरफेर करता है या जिसका नाम यह अनुमान लगाने के लिए बहुत स्वाभाविक है कि हम इसे अंदर पाएंगे।

उदाहरण के लिए, JDK लाइब्रेरी में, घातीय और पाई निरंतर मान एक वर्ग में घोषित किए जाते हैं जो न केवल निरंतर घोषणाएं ( java.lang.Math) घोषित करते हैं ।

   public final class Math {
          ...
       public static final double E = 2.7182818284590452354;
       public static final double PI = 3.14159265358979323846;
         ...
   }

गणित कार्यों का उपयोग करने वाले ग्राहक अक्सर Mathकक्षा पर भरोसा करते हैं । इसलिए, वे आसानी से पर्याप्त रूप से स्थिरांक पा सकते हैं और यह भी याद रख सकते हैं कि कहां Eऔर PIकिस तरह से प्राकृतिक तरीके से परिभाषित किए गए हैं।

यदि आपके आवेदन में एक मौजूदा वर्ग नहीं है जिसमें स्थिर मूल्यों, 1 संस्करण) और 2 संस्करण) के साथ बहुत विशिष्ट और मजबूत कार्यात्मक सामंजस्य है, तो वे अधिक सहज दिखाई देते हैं।
आमतौर पर, यह स्थिरांक के उपयोग को कम नहीं करता है यदि ये एक वर्ग में घोषित किए जाते हैं जो उन्हें हेरफेर करता है जबकि हमारे पास 3 या 4 अन्य वर्ग भी हैं जो उन्हें अधिक से अधिक जोड़तोड़ करते हैं और इनमें से कोई भी वर्ग दूसरों की तुलना में अधिक प्राकृतिक नहीं लगता है निरंतर मूल्यों की मेजबानी करें।
यहां, एक कस्टम वर्ग को केवल स्थिर मान रखने के लिए परिभाषित करना समझ में आता है।
उदाहरण के लिए, JDK लाइब्रेरी में, java.util.concurrent.TimeUnitएनम को एक विशिष्ट वर्ग में घोषित नहीं किया गया है क्योंकि वास्तव में एक और केवल एक JDK विशिष्ट वर्ग नहीं है जो इसे धारण करने के लिए सबसे अधिक सहज है।

public enum TimeUnit {
    NANOSECONDS {
      .....
    },
    MICROSECONDS {
      .....
    },
    MILLISECONDS {
      .....
    },
    SECONDS {
      .....
    },
      .....
}

कई कक्षाओं में घोषित java.util.concurrentउपयोग उन्हें: BlockingQueue, ArrayBlockingQueue<E>, CompletableFuture, ExecutorService, ... और वास्तव में उनमें से कोई भी और अधिक उपयुक्त enum पकड़ रहा है।

— davidxxx
स्रोत
1

किसी भी प्रकार का एक निरंतर, एक अचल संपत्ति बनाकर घोषित किया जा सकता है कि एक वर्ग के भीतर (जो finalसंशोधक के साथ एक सदस्य चर है )। आमतौर पर staticऔर publicसंशोधक भी प्रदान किए जाते हैं।

public class OfficePrinter {
    public static final String STATE = "Ready";  
}

ऐसे कई अनुप्रयोग हैं जहां एक स्थिर मान n-tuple (जैसे गणन ) विकल्पों में से चयन को इंगित करता है । हमारे उदाहरण में, हम एक एन्यूमरेटेड प्रकार को परिभाषित करना चुन सकते हैं जो संभव असाइन किए गए मानों (यानी बेहतर प्रकार-सुरक्षा ) को प्रतिबंधित करेगा :

public class OfficePrinter {
    public enum PrinterState { Ready, PCLoadLetter, OutOfToner, Offline };
    public static final PrinterState STATE = PrinterState.Ready;
}
— रेयान डेलूची
स्रोत
1

एक एकल, सामान्य स्थिरांक वर्ग एक बुरा विचार है। स्थिरांक को उस वर्ग के साथ समूहबद्ध किया जाना चाहिए जिसका वे तार्किक रूप से संबंधित हैं।

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

1

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

— टिम हावलैंड
स्रोत
1

अंतर क्या है

1।

public interface MyGlobalConstants {
    public static final int TIMEOUT_IN_SECS = 25;
}

2।

public class MyGlobalConstants {
    private MyGlobalConstants () {} // Prevents instantiation
    public static final int TIMEOUT_IN_SECS = 25;
}

और MyGlobalConstants.TIMEOUT_IN_SECSजहाँ कहीं भी हमें इस स्थिरांक की आवश्यकता हो, का उपयोग करना । मुझे लगता है कि दोनों एक ही हैं।

— chandrayya
स्रोत
1
यह अनिवार्य रूप से दिए गए जवाब के जवाब में एक टिप्पणी प्रतीत होता है। मुझे लगता है कि वे बहुत ही समान व्यवहार करते हैं, लेकिन बिंकोब की बात यह थी कि वे किसी भी तरह से एक इंटरफ़ेस को परिभाषित नहीं करते हैं। और सुझाव था कि स्थिरांक को वास्तविक वर्गों में जोड़ा जाए, न कि MyGlobalConstants कंकाल वर्ग बनाया जाए। (हालांकि यह कभी-कभी समझ में आता है; तात्कालिक रोक को रोकने के लिए स्थिर स्थिरांक और एक निजी निर्माणकर्ता द्वारा "स्थिर वर्ग" का उपयोग करें; java.lang.math देखें।) एनम का उपयोग करने पर विचार करें।
— जॉन Coombs
वर्ग की घोषणा में "अंतिम" डालने से उपवर्ग को रोका जा सकेगा। (सी # में आप "स्टैटिक" कर सकते हैं, जिसका अर्थ है "अंतिम सार", इसलिए स्पष्ट निजी कंस्ट्रक्टरों की कोई आवश्यकता नहीं है।)
— जॉन कॉम्स ने
हां, @JonCoombs लेकिन "फाइनल" यह सीधे तात्कालिकता को नहीं रोकता है। और जावा कक्षाओं के लिए एक साथ आने के लिए अंतिम और सार दोनों को नापसंद करता है, इसलिए दोनों तात्कालिकता और उपवर्ग को रोकने के लिए निजी रूप से दिखाई देने वाले अंतहीन हैं। मुझे नहीं पता कि "अंतिम सार" क्यों अस्वीकृत है, पहली नज़र में इसके अलावा यह कैसे पढ़ता है में विरोधाभासी लगता है: "आप उपवर्ग नहीं कर सकते हैं लेकिन इस वर्ग को उपवर्गित किया जाना है"।
0

मैं कक्षा को एक ही (आवरण से अलग) स्थिर नहीं कहूंगा ... मेरे पास "सेटिंग", या "मान", या "स्थिरांक" की एक न्यूनतम कक्षा होगी, जहां सभी स्थिरांक जीवित रहेंगे। यदि मेरे पास उनकी बड़ी संख्या है, तो मैं उन्हें तार्किक निरंतर कक्षाओं (UserSettings, AppSettings, आदि) में समूहित करूंगा।

— जोएल मार्टिनेज
स्रोत
कॉन्स्टेंट्स नामक एक क्लास होने के नाते मैंने जो करने की योजना बनाई थी, वह सिर्फ एक छोटा सा उदाहरण था जो मुझे मिला।
— एमके।
0

इसे एक कदम आगे ले जाने के लिए, आप एक इंटरफ़ेस में वैश्विक रूप से उपयोग किए जाने वाले स्थिरांक रख सकते हैं ताकि उनका उपयोग सिस्टम चौड़ा किया जा सके। उदाहरण के लिए

public interface MyGlobalConstants {
    public static final int TIMEOUT_IN_SECS = 25;
}

लेकिन तब इसे लागू न करें। पूरी तरह से योग्य क्लासनाम के माध्यम से सीधे कोड में उन्हें देखें।

— एंड्रयू हरमेल-लॉ
स्रोत
उन्हें एक इंटरफ़ेस में घोषित करने (और इसे लागू नहीं करने) के बारे में यह है कि आप "सार्वजनिक स्थिर फाइनल" को याद कर सकते हैं।
— टॉम हॉकिन -
9
इंटरफेस एक व्यवहार अनुबंध को परिभाषित करने के लिए हैं, न कि स्थिरांक रखने के लिए एक सुविधा तंत्र।
— जॉन टोपले
@ जॉनहोपली हाँ, लेकिन यह काम करता है। ;)
— 1
0

स्थिरांक के लिए, Enum एक बेहतर विकल्प IMHO है। यहाँ एक उदाहरण है

सार्वजनिक वर्ग myClass {

public enum myEnum {
    Option1("String1", 2), 
    Option2("String2", 2) 
    ;
    String str;
            int i;

            myEnum(String str1, int i1) { this.str = str1 ; this.i1 = i }


}
— mmansoor
स्रोत
0

जिस तरह से मैं यह करता हूं वह निरंतर मूल्यों के साथ एक 'ग्लोबल' क्लास बनाकर है और उन कक्षाओं में एक स्थिर आयात करते हैं, जिन्हें निरंतर उपयोग की आवश्यकता होती है।

— Javamann
स्रोत
0

static finalमेरी प्राथमिकता है, मैं केवल तभी उपयोग करूंगा enumयदि आइटम वास्तव में बहुत ही उपयोगी था।

— wulfgarpro
स्रोत
0

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

Enums मूल्यों की एक श्रृंखला का प्रतिनिधित्व करने के लिए एक अच्छा विकल्प है, लेकिन अगर आप पूर्ण मूल्य पर जोर देने के साथ स्टैंडअलोन स्थिरांक स्टोर कर रहे हैं (जैसे। TIMEOUT = 100 ms) तो आप सिर्फ static finalदृष्टिकोण के लिए जा सकते हैं ।

— bincob
स्रोत
0

मैं सहमत हूं कि अधिकांश क्या कह रहे हैं, स्थिरांक का उपयोग करना सबसे अच्छा है जब स्थिरांक का संग्रह होता है। हालांकि, अगर आप एंड्रॉइड में प्रोग्रामिंग कर रहे हैं तो एक बेहतर उपाय है: इंटीडीफ एनोटेशन ।

@Retention(SOURCE)
@IntDef({NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST,NAVIGATION_MODE_TABS})
public @interface NavigationMode {}
public static final int NAVIGATION_MODE_STANDARD = 0;
public static final int NAVIGATION_MODE_LIST = 1;
public static final int NAVIGATION_MODE_TABS = 2;
...
public abstract void setNavigationMode(@NavigationMode int mode);
@NavigationMode
public abstract int getNavigationMode();

IntDef एनोटेशन एक सरल तरीके से एनम से बेहतर है, यह काफी कम जगह लेता है क्योंकि यह बस एक संकलन-समय मार्कर है। यह एक वर्ग नहीं है, न ही इसके पास स्वचालित स्ट्रिंग-रूपांतरण संपत्ति है।

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

यह बीएडी की आदत है और बहुत ही भयानक अभ्यास है -शून्य कट्टरवाद को समझे बिना यहोशू बलोच को उद्धृत करने की है।

मैंने जोशुआ बलोच को कुछ भी नहीं पढ़ा है, इसलिए या तो

  • वह एक भयानक प्रोग्रामर है
  • या अब तक जिन लोगों को मैं उन्हें उद्धृत करता हूं (जोशुआ एक लड़के का नाम है जिसे मैं मानता हूं) केवल अपनी सामग्री का उपयोग धार्मिक लिपियों के रूप में कर रहे हैं ताकि उनके सॉफ़्टवेयर धार्मिक भोगों को सही ठहराया जा सके।

जैसा कि बाइबल के कट्टरवाद में है, बाइबल के सभी कानूनों को पूरा किया जा सकता है

  • अपने पूरे दिल और पूरे दिमाग के साथ मौलिक पहचान से प्यार करें
  • अपने पड़ोसी से खुद की तरह प्यार करें

और इसी तरह सॉफ्टवेयर इंजीनियरिंग कट्टरवाद द्वारा अभिव्यक्त किया जा सकता है

  • अपने सभी प्रोग्रामिंग और दिमाग के साथ खुद को ग्राउंड-जीरो फंडामेंटल में समर्पित करें
  • और अपने साथी-प्रोग्रामरों की उत्कृष्टता के लिए समर्पित करें जैसा कि आप स्वयं के लिए करेंगे।

इसके अलावा, बाइबिल के कट्टरपंथी हलकों के बीच एक मजबूत और उचित कोरोलरी तैयार की गई है

  • पहले अपने आप से प्यार करो। क्योंकि यदि आप खुद से बहुत प्यार नहीं करते हैं, तो यह अवधारणा "अपने पड़ोसी से खुद को प्यार करें" ज्यादा वजन नहीं उठाती है, क्योंकि "आप खुद से कितना प्यार करते हैं" वह डेटम लाइन है जिसके ऊपर आप दूसरों को पसंद करेंगे।

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

सॉफ्टवेयर प्रोग्रामिंग के मौलिक नियम

  • आलस्य एक अच्छे प्रोग्रामर का गुण है
  • आप अपने प्रोग्रामिंग जीवन को जितना हो सके, आलसी बना सकते हैं और इसलिए जितना संभव हो उतना प्रभावी
  • आप अपने प्रोग्रामिंग के परिणामों और एंट्रेस को आसान बनाने के लिए, आलसी के रूप में और इसलिए अपने neigbour- प्रोग्रामर जो आपके साथ काम करते हैं और अपनी प्रोग्रामिंग एंट्रेस को उठाते हैं, के लिए यथासंभव प्रभावी हैं।

इंटरफ़ेस-पैटर्न स्थिरांक एक बुरी आदत है ???

मौलिक रूप से प्रभावी और जिम्मेदार प्रोग्रामिंग के कौन से कानून के तहत यह धार्मिक निर्णय होता है?

बस इंटरफ़ेस-पैटर्न स्थिरांक ( https://en.wikipedia.org/wiki/Constant_interface ) पर विकिपीडिया लेख पढ़ें , और मूर्खतापूर्ण बहाने यह इंटरफ़ेस-पैटर्न स्थिरांक के खिलाफ बताता है।

  • व्हाट-नो आईडीई? सॉफ्टवेयर प्रोग्रामर के रूप में पृथ्वी पर कौन आईडीई का उपयोग नहीं करेगा? हम में से अधिकांश ऐसे प्रोग्रामर हैं जो आईडीई के उपयोग से बचने के लिए माचो एसेसेटिक सर्वाइवलिज्म थ्रो को साबित नहीं करना चाहते हैं।

    • इसके अलावा - एक आईडीई की जरूरत नहीं के साधन के रूप में सूक्ष्म कार्यात्मक प्रोग्रामिंग के एक दूसरे समर्थकों की प्रतीक्षा करें। प्रतीक्षा करें जब तक आप डेटा-मॉडल सामान्यीकरण पर मेरी व्याख्या नहीं पढ़ते।

  • मौजूदा दायरे के भीतर उपयोग किए जाने वाले चरों के नाम स्थान को प्रदूषित करता है? यह इस मत के समर्थक हो सकते हैं

    • के बारे में पता नहीं है, और की जरूरत है, डेटा-मॉडल सामान्यीकरण

  • स्थिरांक को लागू करने के लिए इंटरफेस का उपयोग करना इंटरफेस का दुरुपयोग है। ऐसे के समर्थकों की बुरी आदत है

    • यह नहीं देखना कि "स्थिरांक" को अनुबंध के रूप में माना जाना चाहिए। और इंटरफेस एक अनुबंध के अनुपालन को लागू करने या पेश करने के लिए उपयोग किया जाता है।

  • भविष्य में कार्यान्वित कक्षाओं में इंटरफेस को परिवर्तित करना असंभव नहीं है। हह .... हम्म्म ... ???

    • आप अपनी लगातार आजीविका के रूप में प्रोग्रामिंग के ऐसे पैटर्न में क्यों उलझना चाहेंगे? IOW, अपने आप को ऐसी AMBIVALENT और खराब प्रोग्रामिंग आदत के लिए समर्पित क्यों करें?

चाहे जो भी बहाना हो, कोई वैध EXCUSE नहीं है, जब यह फ़ंडामेंटली इफ़ेक्टिव सॉफ़्टवेयर इंजीनियरिंग की बात आती है, जो इंटरफ़ेस स्थिरांक के उपयोग को कम करने या आम तौर पर हतोत्साहित करने के लिए है।

इससे कोई फर्क नहीं पड़ता कि संयुक्त राज्य अमेरिका के संविधान को बनाने वाले संस्थापक पिताओं के मूल इरादे और मानसिक स्थिति क्या थे। हम संस्थापक पिता के मूल इरादों पर बहस कर सकते हैं, लेकिन मुझे ध्यान है कि अमेरिकी संविधान के लिखित कथन हैं। और यह हर अमेरिकी नागरिक की जिम्मेदारी है कि वह अमेरिकी संविधान के लिखित साहित्यिक-कट्टरपंथ का शोषण करे, अलिखित संस्थापक-इरादों का नहीं।

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

मौलिक डेटा-मॉडल सामान्यीकरण है

इससे कोई फर्क नहीं पड़ता कि आपका डेटा-मॉडल होस्ट या ट्रांसमिटेड कैसे है। यदि आप डेटा-मॉडल के सामान्यीकरण की आवश्यकता और प्रक्रिया को नहीं समझते हैं, तो आप इंटरफेस या एनम या जोनोट्स, रिलेशनल या नो-एसक्यूएल का उपयोग करते हैं।

हमें पहले प्रक्रियाओं के सेट के डेटा-मॉडल को परिभाषित और सामान्य करना होगा। और जब हमारे पास एक सुसंगत डेटा-मॉडल होता है, तभी हम कार्यात्मक व्यवहार को परिभाषित करने के लिए इसके घटकों के प्रक्रिया प्रवाह का उपयोग कर सकते हैं और प्रक्रिया एक क्षेत्र या अनुप्रयोगों के दायरे को अवरुद्ध कर सकती है। और उसके बाद ही हम प्रत्येक कार्यात्मक प्रक्रिया के एपीआई को परिभाषित कर सकते हैं।

यहां तक ​​कि EF Codd द्वारा प्रस्तावित डेटा सामान्यीकरण के पहलुओं को अब गंभीर रूप से चुनौती दी गई है और गंभीर रूप से चुनौती दी गई है। जैसे 1NF पर उनके बयान की अस्पष्ट, गलत और अधिक सरलीकृत के रूप में आलोचना की गई है, जैसा कि उनके बाकी बयानों में विशेष रूप से आधुनिक डेटा सेवाओं, रेपो-प्रौद्योगिकी और ट्रांसमिशन के आगमन में है। IMO, EF Codd स्टेटमेंट्स को पूरी तरह से ड्रॉ किया जाना चाहिए और अधिक गणितीय रूप से प्रशंसनीय स्टेटमेंट्स के नए सेट को डिज़ाइन किया जाना चाहिए।

EF Codd का एक भयावह दोष और प्रभावी मानव समझ के लिए इसके मिसलिग्न्मेंट का कारण उनका विश्वास है कि मानवीय रूप से बहु-आयामी, परिवर्तनशील-आयाम डेटा को कुशलता से टुकड़ा 2-आयामी मैपिंग का एक सेट माना जा सकता है।

डेटा सामान्यीकरण का मूल आधार

क्या EF Codd व्यक्त करने में विफल रहा।

प्रत्येक सुसंगत डेटा-मॉडल के भीतर, ये प्राप्त करने के लिए डेटा-मॉडल सुसंगतता का क्रमिक स्नातक क्रम हैं।

  1. डेटा इंस्टेंस की एकता और पहचान।
    • प्रत्येक डेटा घटक की ग्रैन्युलैरिटी को डिज़ाइन करें, जिससे उनकी ग्रैन्युलैरिटी एक ऐसे स्तर पर हो जहाँ एक घटक के प्रत्येक उदाहरण को विशिष्ट रूप से पहचाना और प्राप्त किया जा सके।
    • उदाहरण की अनुपस्थिति। यानी, कोई साधन मौजूद नहीं है जिससे एक पहचान एक घटक के एक से अधिक उदाहरण का उत्पादन करती है।
  2. उदाहरण क्रॉस्टल की अनुपस्थिति। किसी घटक के एक या अधिक उदाहरणों का उपयोग करने के लिए किसी घटक के उदाहरण की पहचान करने के लिए योगदान की आवश्यकता नहीं होती है।
  3. डेटा घटकों / आयामों की एकता और पहचान।
    • घटक डी-अलियासिंग की उपस्थिति। वहाँ एक परिभाषा मौजूद होनी चाहिए जिससे एक घटक / आयाम विशिष्ट रूप से पहचाना जा सके। जो एक घटक की प्राथमिक परिभाषा है;
    • जहां प्राथमिक परिभाषा उप-आयामों या सदस्य-घटकों को उजागर करने का परिणाम नहीं देगी जो कि किसी इच्छित घटक का हिस्सा नहीं हैं;
  4. घटक डीलिंग का अनूठा साधन। इसमें एक और केवल एक ही होना चाहिए, एक घटक के लिए इस तरह के घटक डी-अलियासिंग परिभाषा।
  5. घटकों के पदानुक्रमित संबंध में मूल घटक की पहचान करने के लिए एक, और केवल एक, परिभाषा इंटरफ़ेस या अनुबंध मौजूद है।
  6. घटक क्रोस्टॉक की अनुपस्थिति। किसी घटक की निश्चित पहचान में योगदान करने के लिए किसी अन्य घटक के सदस्य का उपयोग करने की आवश्यकता मौजूद नहीं है।
    • ऐसे माता-पिता-बच्चे के संबंध में, माता-पिता की पहचान की परिभाषा बच्चे के सदस्य घटकों के सेट के हिस्से पर निर्भर नहीं होनी चाहिए। माता-पिता की पहचान का एक सदस्य घटक एक बच्चे के किसी भी या सभी बच्चों को संदर्भित करने का सहारा लिए बिना पूरी बच्चे की पहचान होना चाहिए।
  7. डेटा-मॉडल के द्वि-मोडल या बहु-मोडल दिखावे को रोकना।
    • जब किसी घटक की दो उम्मीदवार परिभाषाएँ मौजूद होती हैं, तो यह एक स्पष्ट संकेत है कि दो अलग-अलग डेटा-मॉडल मौजूद होते हैं, जिन्हें एक के रूप में मिलाया जाता है। इसका मतलब है कि डेटा-मॉडल स्तर या क्षेत्र स्तर पर असंगति है।
    • अनुप्रयोगों के एक क्षेत्र को एक और केवल एक डेटा-मॉडल का उपयोग करना चाहिए, सुसंगत रूप से।
  8. घटक उत्परिवर्तन का पता लगाएं और पहचानें। जब तक आपने विशाल डेटा के सांख्यिकीय घटक विश्लेषण का प्रदर्शन नहीं किया है, तो आप संभवतः इलाज नहीं करते हैं, या घटक उत्परिवर्तन की आवश्यकता को देखते हैं।
    • डेटा-मॉडल में इसके कुछ घटक चक्रवात या धीरे-धीरे हो सकते हैं।
    • मोड सदस्य-रोटेशन या ट्रांसपोजिशन-रोटेशन हो सकता है।
    • सदस्य-रोटेशन उत्परिवर्तन घटकों के बीच बच्चे के घटकों की विशिष्ट अदला-बदली हो सकती है। या जहां पूरी तरह से नए घटकों को परिभाषित करना होगा।
    • ट्रांसपोज़ल म्यूटेशन एक आयामी सदस्य के रूप में एक विशेषता में उत्परिवर्तित होता है, इसके विपरीत।
    • प्रत्येक उत्परिवर्तन चक्र को एक अलग डेटा-मोडल के रूप में पहचाना जाना चाहिए।
  9. प्रत्येक म्यूटेशन का संस्करण करें। ऐसा है कि आप डेटा मॉडल के पिछले संस्करण को बाहर निकाल सकते हैं, जब डेटा मॉडल के 8 साल पुराने उत्परिवर्तन के इलाज के लिए शायद आवश्यकता होती है।

अंतर-सर्विसिंग घटक-अनुप्रयोगों के क्षेत्र या ग्रिड में, एक और केवल एक सुसंगत डेटा-मॉडल होना चाहिए या स्वयं को पहचानने के लिए डेटा-मॉडल / संस्करण के लिए एक साधन मौजूद होना चाहिए।

क्या हम अभी भी पूछ रहे हैं कि क्या हम इंटरफ़ेस कॉन्स्टेंट का उपयोग कर सकते हैं? वास्तव में ?

इस सांसारिक प्रश्न की तुलना में अधिक परिणामी होने पर डेटा-सामान्यीकरण मुद्दे हैं। यदि आप उन मुद्दों को हल नहीं करते हैं, तो आपको भ्रम है कि इंटरफ़ेस स्थिरांक कारण तुलनात्मक रूप से कुछ भी नहीं है। कुछ भी नहीं।

डेटा-मॉडल के सामान्यीकरण से फिर आप घटकों को कॉन्ट्रैक्ट इंटरफ़ेस कॉन्स्टेंट के रूप में चर के रूप में निर्धारित करते हैं।

फिर आप यह निर्धारित करते हैं कि कौन सा मूल्य इंजेक्शन, संपत्ति कॉन्फ़िगरेशन प्लेसहोल्डिंग, इंटरफेस, अंतिम तार, आदि में जाता है।

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

शायद आप डेटा-मॉडल को vcs रिलीज़ में संकलित करना चाहते हैं। कि आप डेटा-मॉडल के विशिष्ट पहचान योग्य संस्करण को बाहर निकाल सकते हैं।

इंटरफेस में परिभाषित मूल्य पूरी तरह से गैर-परस्पर होने का आश्वासन दिया जाता है। और साझा करने योग्य है। अपनी कक्षा में अंतिम तार के एक सेट को दूसरी कक्षा से क्यों लोड करें जब आपको आवश्यकता होती है स्थिरांक का वह सेट ??

तो क्यों नहीं यह एक डेटा-मॉडल अनुबंध प्रकाशित करने के लिए? मेरा मतलब है कि अगर आप इसे सुसंगत रूप से प्रबंधित और सामान्य कर सकते हैं, तो क्यों नहीं? ...

public interface CustomerService {
  public interface Label{
    char AssignmentCharacter = ':';
    public interface Address{
      String Street = "Street";
      String Unit= "Unit/Suite";
      String Municipal = "City";
      String County = "County";
      String Provincial = "State";
      String PostalCode = "Zip"
    }

    public interface Person {
      public interface NameParts{
        String Given = "First/Given name"
        String Auxiliary = "Middle initial"
        String Family = "Last name"
      }
    }
  }
}

अब मैं अपने ऐप्स के अनुबंधित लेबलों को इस तरह से संदर्भित कर सकता हूं

CustomerService.Label.Address.Street
CustomerService.Label.Person.NameParts.Family

यह जार फ़ाइल की सामग्री को भ्रमित करता है? एक जावा प्रोग्रामर के रूप में मैं जार की संरचना के बारे में परवाह नहीं करता हूं।

यह ओस्गी-प्रेरित रनटाइम स्वैपिंग के लिए जटिलता प्रस्तुत करता है? Osgi प्रोग्रामर्स को उनकी बुरी आदतों को जारी रखने की अनुमति देने के लिए एक अत्यंत कुशल साधन है। ओस्गी की तुलना में बेहतर विकल्प हैं।

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

public class PurchaseRequest {
  private interface Constants{
    String INTERESTINGName = "Interesting Name";
    String OFFICIALLanguage = "Official Language"
    int MAXNames = 9;
  }
}

शायद यह भी:

public interface PurchaseOrderConstants {
  public interface Properties{
    default String InterestingName(){
       return something();
    }
    String OFFICIALLanguage = "Official Language"
    int MAXNames = 9;
  }
}

जब इंटरफ़ेस लागू किया जाता है, तो विचार करने लायक इंटरफेस स्थिरांक के साथ एकमात्र मुद्दा।

यह इंटरफेस का "मूल इरादा" नहीं है? जैसे मैं अमेरिकी संविधान को बनाने में संस्थापक पिता के "मूल इरादे" की परवाह करता हूं, बजाय इसके कि सुप्रीम कोर्ट अमेरिकी संविधान के लिखित पत्रों की व्याख्या कैसे करेगा ???

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

— धन्य गीक
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.