जावा सिंगलटन क्लास

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

जावा में सिंगलटन क्या है?

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

1. यह गारंटी देता है कि कक्षा का केवल एक ही उदाहरण होगा।

2. यह उस उदाहरण के लिए वैश्विक पहुंच का एकल बिंदु प्रदान करता है।

इसलिए, दो विशेषताएं हैं जो सिंगलटन पैटर्न के लगभग हर कार्यान्वयन की विशेषता हैं:

1. एक निजी निर्माता। यह कक्षा के बाहर ही कक्षा की वस्तुओं को बनाने की क्षमता को सीमित करता है।

2. एक सार्वजनिक स्थैतिक विधि जो कक्षा का उदाहरण लौटाती है। इस विधि को getInstance कहा जाता है । यह वर्ग उदाहरण के लिए वैश्विक पहुँच का बिंदु है।

कार्यान्वयन के विकल्प

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

• आलसी आरंभीकरण: उदाहरण तब तक नहीं बनाया जाता जब तक इसकी आवश्यकता न हो।

• सरल और पारदर्शी कोड: यह मीट्रिक, निश्चित रूप से व्यक्तिपरक है, लेकिन यह महत्वपूर्ण है।

• थ्रेड सुरक्षा: बहु-थ्रेडेड वातावरण में सही संचालन।

• बहु-थ्रेडेड वातावरण में उच्च प्रदर्शन: संसाधन साझा करते समय बहुत कम या कोई थ्रेड ब्लॉकिंग नहीं।

अब विपक्ष। हम उन कारकों को सूचीबद्ध करेंगे जो कार्यान्वयन को खराब रोशनी में डालते हैं:

• कोई आलसी प्रारंभिकरण नहीं: जब आवेदन शुरू होने पर कक्षा लोड हो जाती है, भले ही इसकी आवश्यकता हो या नहीं (विरोधाभासी रूप से, आईटी दुनिया में आलसी होना बेहतर है)

• जटिल और पढ़ने में मुश्किल कोड। यह मीट्रिक भी व्यक्तिपरक है। अगर आपकी आंखों से खून बहना शुरू हो जाता है, तो हम मान लेंगे कि कार्यान्वयन सबसे अच्छा नहीं है।

• थ्रेड सुरक्षा का अभाव। दूसरे शब्दों में, "थ्रेड डेंजर"। बहु-थ्रेडेड वातावरण में गलत संचालन।

• बहु-थ्रेडेड वातावरण में खराब प्रदर्शन: संसाधन साझा करते समय थ्रेड्स एक-दूसरे को हर समय या अक्सर ब्लॉक करते हैं।

कोड

अब हम कार्यान्वयन के विभिन्न विकल्पों पर विचार करने के लिए तैयार हैं और पेशेवरों और विपक्षों को इंगित करते हैं:

सरल

public class Singleton {
    private static final Singleton INSTANCE = new Singleton();
    
    private Singleton() {
    }
    
    public static Singleton getInstance() {
        return INSTANCE;
    }
}

सबसे सरल कार्यान्वयन। पेशेवरों:

• सरल और पारदर्शी कोड

• थ्रेड सुरक्षा

• बहु-थ्रेडेड वातावरण में उच्च प्रदर्शन

दोष:

• कोई आलसी आरंभीकरण नहीं।

पिछली कमी को ठीक करने के प्रयास में, हमें कार्यान्वयन संख्या दो मिलती है:

आलसी आरंभीकरण

public class Singleton {
  private static final Singleton INSTANCE;

  private Singleton() {}

  public static Singleton getInstance() {
    if (INSTANCE == null) {
      INSTANCE = new Singleton();
    }
    return INSTANCE;
  }
}

पेशेवरों:

• आलसी आरंभीकरण।

दोष:

• धागा सुरक्षित नहीं

यह क्रियान्वयन दिलचस्प है। हम आलस्य से प्रारंभ कर सकते हैं, लेकिन हमने थ्रेड सुरक्षा खो दी है। कोई चिंता नहीं — हम कार्यान्वयन संख्या तीन में सब कुछ सिंक्रनाइज़ करते हैं।

सिंक्रोनाइज़्ड एक्सेस

public class Singleton {
  private static final Singleton INSTANCE;

  private Singleton() {
  }

  public static synchronized Singleton getInstance() {
    if (INSTANCE == null) {
      INSTANCE = new Singleton();
    }
    return INSTANCE;
  }
}

पेशेवरों:

• आलसी आरंभीकरण।

• थ्रेड सुरक्षा

दोष:

• खराब मल्टीथ्रेडेड प्रदर्शन

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

डबल-चेक लॉकिंग

public class Singleton {
    private static final Singleton INSTANCE;

  private Singleton() {
  }

    public static Singleton getInstance() {
        if (INSTANCE == null) {
            synchronized (Singleton.class) {
                if (INSTANCE == null) {
                    INSTANCE = new Singleton();
                }
            }
        }
        return INSTANCE;
    }
}

पेशेवरों:

• आलसी आरंभीकरण।

• थ्रेड सुरक्षा

• बहु-थ्रेडेड वातावरण में उच्च प्रदर्शन

दोष:

• 1.5 से नीचे जावा के पुराने संस्करणों में समर्थित नहीं है (अस्थिर कीवर्ड का उपयोग 1.5 संस्करण के बाद से तय है)

ध्यान दें कि इस कार्यान्वयन विकल्प के सही ढंग से काम करने के लिए, दो शर्तों में से एक का पूरा होना आवश्यक है। INSTANCE चर अंतिम या अस्थिर होना चाहिए । अंतिम कार्यान्वयन जिस पर हम आज चर्चा करेंगे वह वर्ग धारक सिंगलटन है ।

वर्ग धारक

public class Singleton {

   private Singleton() {
   }

   private static class SingletonHolder {
       public static final Singleton HOLDER_INSTANCE = new Singleton();
   }

   public static Singleton getInstance() {
       return SingletonHolder.HOLDER_INSTANCE;
   }
}

पेशेवरों:

• आलसी आरंभीकरण।

• थ्रेड सुरक्षा।

• बहु-थ्रेडेड वातावरण में उच्च प्रदर्शन।

दोष:

• सही संचालन के लिए एक गारंटी की आवश्यकता होती है कि सिंगलटन ऑब्जेक्ट बिना किसी त्रुटि के प्रारंभ हो। अन्यथा, getInstance विधि के लिए पहली कॉल के परिणामस्वरूप ExceptionInInitializerError होगा, और बाद की सभी कॉल NoClassDefFoundError उत्पन्न करेंगी ।

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

सिंगलटन पैटर्न के पक्ष और विपक्ष

सामान्य तौर पर, एक सिंगलटन वही करता है जिसकी उससे अपेक्षा की जाती है:

1. यह गारंटी देता है कि कक्षा का केवल एक ही उदाहरण होगा।

2. यह उस उदाहरण के लिए वैश्विक पहुंच का एकल बिंदु प्रदान करता है।

हालाँकि, इस पैटर्न में कमियाँ हैं:

1. एक सिंगलटन एकल उत्तरदायित्व सिद्धांत का उल्लंघन करता है: अपने प्रत्यक्ष कर्तव्यों के अतिरिक्त, सिंगलटन वर्ग उदाहरणों की संख्या को भी नियंत्रित करता है।

2. एक सिंगलटन पर सामान्य वर्ग की निर्भरता वर्ग के सार्वजनिक अनुबंध में दिखाई नहीं दे रही है।

3. वैश्विक चर खराब हैं। अंततः, एक सिंगलटन एक विशाल वैश्विक चर में बदल जाता है।

4. एक सिंगलटन की उपस्थिति समग्र रूप से एप्लिकेशन की टेस्टेबिलिटी को कम कर देती है और विशेष रूप से सिंगलटन का उपयोग करने वाली कक्षाएं।

और बस! :) हमने आपके साथ जावा सिंगलटन क्लास की खोज की है। अब, अपने शेष जीवन के लिए, अपने प्रोग्रामर दोस्तों के साथ बातचीत करते समय, आप न केवल यह उल्लेख कर सकते हैं कि पैटर्न कितना अच्छा है, बल्कि कुछ शब्द जो इसे खराब करते हैं, के बारे में भी बता सकते हैं। इस नए ज्ञान में महारत हासिल करने के लिए शुभकामनाएँ।

अतिरिक्त पढ़ना:

• जावा में पैटर्न और सिंगलटन
• इनिशियलाइज़ेशन-ऑन-डिमांड होल्डर मुहावरा
• सिंगलटन डिज़ाइन पैटर्न को लागू करने और उपयोग करने के प्रभावी तरीके