हा लेख अशा प्रत्येकासाठी आहे ज्याला, पहिल्यांदाच, डिझाइन पॅटर्नची संकल्पना येत आहे, सिंगलटन हा शब्द ऐकला आहे , किंवा कसा तरी सिंगलटन पॅटर्न लागू केला आहे परंतु काय होत आहे ते समजले नाही. स्वागत आहे! कोडजिमच्या विद्यार्थ्यांना लेव्हल 15 वर पहिल्यांदाच डिझाइन पॅटर्नचा सामना करावा लागतो, जेव्हा कॅप्टन अनपेक्षितपणे त्यांना जावा सिंगलटन पॅटर्नची आळशी अंमलबजावणी करून त्यांची समज "मजबूत" करण्यास सांगतो. सिंगलटन पॅटर्नबद्दल प्रथमच ऐकणाऱ्या विद्यार्थ्यांच्या मनात बरेच प्रश्न असतात: जगात डिझाइन पॅटर्न म्हणजे काय? आम्हाला त्याची गरज का आहे? सिंगलटन म्हणजे काय ? आणि शेवटी, आळशी अंमलबजावणी म्हणजे काय? चला या प्रश्नांची क्रमाने उत्तरे देऊ.

जगात डिझाइन पॅटर्न म्हणजे काय?

माझा असा विश्वास आहे की या प्रश्नाचे उत्तर सर्वोत्तम समजून घेण्यासाठी थोडासा इतिहास आहे. चार प्रसिद्ध प्रोग्रामिंग लेखक आहेत (एरिच गामा, जॉन व्लिसिड्स, राल्फ जॉन्सन आणि रिचर्ड हेल्म) ज्यांनी एक मनोरंजक कल्पना मांडली. त्यांच्या लक्षात आले की सॉफ्टवेअर डेव्हलपमेंटसाठी त्यांना अंदाजे समान समस्या सोडवणे आणि त्याच प्रकारे संरचित कोड लिहिणे आवश्यक आहे. म्हणून त्यांनी ठराविक नमुन्यांचे वर्णन करण्याचे ठरविले ज्यांचा वापर ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंगमध्ये करणे आवश्यक आहे. त्यांचे पुस्तक 1994 मध्ये डिझाइन पॅटर्न: एलिमेंट्स ऑफ रीयुजेबल ऑब्जेक्ट-ओरिएंटेड सॉफ्टवेअर या शीर्षकाखाली प्रकाशित झाले. पुस्तकाचे नाव खूप मोठे झाले आणि लोक त्याला फक्त गँग ऑफ फोरचे पुस्तक म्हणू लागले. पहिल्या आवृत्तीत 23 नमुने समाविष्ट होते. त्यानंतर, इतर डझनभर नमुने सापडले.
डिझाईन पॅटर्न हा सामान्य समस्येचे प्रमाणित उपाय आहे.
आणि सिंगलटन पॅटर्न त्यापैकी फक्त एक आहे.

आम्हाला डिझाइन नमुन्यांची आवश्यकता का आहे?

तुम्ही नमुने जाणून घेतल्याशिवाय प्रोग्राम करू शकता: शेवटी, लेव्हल 15 पर्यंत, तुम्ही कोडजिमवर शेकडो मिनी-प्रोग्रॅम आधीच लिहिले आहेत की ते अस्तित्वात आहेत हे माहीत नसतानाही. हे सूचित करते की डिझाइन पॅटर्न हे एक प्रकारचे साधन आहे ज्याचा वापर मास्टरला हौशीपासून वेगळे करतो: डिझाइन नमुने विशिष्ट समस्येचे योग्यरित्या निराकरण कसे करावे याचे वर्णन करतात. याचा अर्थ असा की नमुने जाणून घेतल्याने तुमचा वेळ वाचतो. अशा प्रकारे, ते अल्गोरिदमसारखेच आहेत. उदाहरणार्थ, तुम्ही ब्लॅकजॅक आणि संख्यांसह तुमचा स्वतःचा वर्गीकरण अल्गोरिदम तयार करू शकताआणि असे करण्यात बराच वेळ घालवा, किंवा आपण बर्याच काळापासून समजलेले आणि वर्णन केलेले एक अंमलात आणू शकता. डिझाईन नमुन्यांमध्येही असेच आहे. याव्यतिरिक्त, डिझाइन पॅटर्नसह, कोड अधिक मानक बनतो आणि योग्य पॅटर्न वापरताना, तुमच्याकडून चुका होण्याची शक्यता कमी असते, कारण पॅटर्नचे सामान्य नुकसान ओळखले गेले होते आणि ते फार पूर्वीपासून दूर केले गेले होते. इतर सर्व गोष्टींवर, नमुन्यांचे ज्ञान प्रोग्रामरना एकमेकांना चांगल्या प्रकारे समजून घेण्यास मदत करते. तुमच्या सहकारी प्रोग्रामरना एक लांबलचक स्पष्टीकरण देण्याचा प्रयत्न करण्याऐवजी तुम्ही फक्त पॅटर्नचे नाव सांगू शकता. सारांश, डिझाइन नमुने तुम्हाला मदत करतात:
  • चाक पुन्हा शोधू नका, परंतु त्याऐवजी मानक उपाय वापरा;
  • मानक कोड;
  • शब्दावली प्रमाणित करा;
या विभागाचा निष्कर्ष काढण्यासाठी, आम्ही लक्षात घेतो की डिझाइन नमुन्यांची संपूर्ण मुख्य भाग तीन मोठ्या गटांमध्ये विभागली जाऊ शकते: पॅटर्न आणि सिंगलटन - प्रथमच त्यांना भेटणाऱ्या प्रत्येकासाठी - 2

शेवटी, सिंगलटन नमुना

सिंगलटन हा एक सर्जनशील नमुना आहे . हा नमुना वर्गाचा एकच प्रसंग असल्याची खात्री करतो आणि या ऑब्जेक्टसाठी जागतिक प्रवेश बिंदू प्रदान करतो. वर्णनावरून, हे स्पष्ट झाले पाहिजे की हा नमुना दोन प्रकरणांमध्ये लागू केला जावा:
  1. जेव्हा तुमच्या प्रोग्रामला विशिष्ट वर्गाचे एकापेक्षा जास्त ऑब्जेक्ट तयार केले जाऊ नयेत. उदाहरणार्थ, संगणक गेममध्ये हिरो वर्ग असू शकतो आणि गेममधील एकमेव नायकाचे वर्णन करणारा फक्त एक हिरो ऑब्जेक्ट असू शकतो.

  2. जेव्हा आपल्याला ऑब्जेक्टवर जागतिक प्रवेशासाठी एक बिंदू प्रदान करण्याची आवश्यकता असते. दुसऱ्या शब्दांत, तुम्हाला प्रोग्राममध्ये कुठूनही ऑब्जेक्ट उपलब्ध करून देणे आवश्यक आहे. अरेरे, केवळ ग्लोबल व्हेरिएबल तयार करणे पुरेसे नाही, कारण ते लेखन-संरक्षित नाही: कोणीही व्हेरिएबलचे मूल्य बदलू शकतो, त्यामुळे ऑब्जेक्टचा ग्लोबल ऍक्सेस पॉइंट गमावला जाऊ शकतो. सिंगलटनचे हे गुणधर्म आवश्यक असतात, उदाहरणार्थ, जेव्हा तुमच्याकडे डेटाबेससह कार्य करणारी एखादी वस्तू असते आणि तुम्हाला प्रोग्रामच्या वेगवेगळ्या भागांमधून डेटाबेसमध्ये प्रवेश करणे आवश्यक असते. सिंगलटन हे सुनिश्चित करेल की पूर्वी तयार केलेल्या उदाहरणाची जागा घेणारा कोड कोणीही लिहित नाही.
त्यामुळे सिंगलटनने या दोन गरजा पूर्ण केल्या: प्रोग्राममध्ये विशिष्ट प्रकारची एकच वस्तू असली पाहिजे आणि त्यात जागतिक प्रवेश असणे आवश्यक आहे. लेव्हल 15 वरील उदाहरणामध्ये, कॅप्टन तुम्हाला खालील कार्यासाठी हा पॅटर्न लागू करण्यास सांगतो:
  1. आळशी प्रारंभासह सिंगलटनचे उदाहरण शोधा .

  2. समान तत्त्व वापरून तीन सिंगलटन वर्ग तयार करा — सूर्य, चंद्र, पृथ्वी — स्वतंत्र फाइल्समध्ये.

  3. अंमलात आणाग्रहसूर्य , चंद्र आणि पृथ्वी वर्गांमध्ये इंटरफेस .

  4. सोल्यूशन क्लासच्या स्थिर ब्लॉकमध्ये कॉल कराreadKeyFromConsoleAndInitPlanetपद्धत

  5. ची अंमलबजावणी कराreadKeyFromConsoleAndInitPlanetपद्धत कार्यक्षमता:

    • ५.१. कन्सोलमधून एक स्ट्रिंग पॅरामीटर वाचा

    • ५.२. जर पॅरामीटर एकाच्या समान असेलग्रहइंटरफेसचे स्थिरांक, योग्य प्लॅनेट ऑब्जेक्ट तयार करा.

कार्य परिस्थिती काळजीपूर्वक वाचल्यानंतर, येथे सिंगलटन का आवश्यक आहे हे आम्ही स्पष्टपणे पाहू शकतो. खरंच, आम्हाला खालीलपैकी प्रत्येक वर्गाचे उदाहरण तयार करण्यास सांगितले आहे: सूर्य , चंद्र , पृथ्वी . आपण एकापेक्षा जास्त सूर्य/चंद्र/पृथ्वी निर्माण करू नये असे गृहीत धरण्यात अर्थ आहे. अन्यथा, तुम्ही स्टार वॉर्सची तुमची आवृत्ती लिहिल्याशिवाय, आम्ही एक मूर्खपणाच्या परिस्थितीत येऊ. जावामध्ये सिंगलटन पॅटर्न तीन चरणांमध्ये लागू करणे Java मध्ये, सिंगलटन वर्तन सामान्य कन्स्ट्रक्टर वापरून लागू केले जाऊ शकत नाही, कारण कन्स्ट्रक्टर नेहमी नवीन ऑब्जेक्ट परत करतो. म्हणून, सिंगलटनची सर्व अंमलबजावणीकन्स्ट्रक्टर लपवण्यासाठी, एक सार्वजनिक स्थिर पद्धत तयार करा जी सिंगलटन ऑब्जेक्टच्या जीवनकाळावर नियंत्रण ठेवते आणि नवीन दिसणार्‍या सर्व वस्तू "नाश" करते. सिंगलटनमध्ये प्रवेश केला असल्यास , त्याने एकतर नवीन ऑब्जेक्ट तयार केला पाहिजे (जर प्रोग्राममध्ये आधीपासूनच अस्तित्वात नसेल तर), किंवा विद्यमान एक परत करा. हे पूर्ण करण्यासाठी:
  1. तुम्हाला वर्गाला एक खाजगी स्थिर फील्ड देणे आवश्यक आहे जे एकल ऑब्जेक्ट संग्रहित करते:

    
    public class LazyInitializedSingleton {
    	private static LazyInitializedSingleton instance; // #1
    }
    
  2. (डीफॉल्ट) कन्स्ट्रक्टर खाजगी करा. याचा अर्थ असा आहे की वर्गाबाहेर प्रवेश केला जाऊ शकत नाही आणि नवीन वस्तू परत करू शकणार नाही:

    
    public class LazyInitializedSingleton {
    	private static LazyInitializedSingleton instance;
    private LazyInitializedSingleton(){} // #2
    } 
    
  3. एक स्थिर निर्मिती पद्धत घोषित करा जी सिंगलटन मिळविण्यासाठी वापरली जाईल:

    
    public class LazyInitializedSingleton {
        private static LazyInitializedSingleton instance;
            private LazyInitializedSingleton() {}
            public static LazyInitializedSingleton getInstance() { // #3
            if (instance == null) { // If the object has not yet been created
                instance = new LazyInitializedSingleton(); // Create a new object
            }
            return instance; // Return the previously created object
        }
    }
    
वरील उदाहरण काहीसे अनाड़ी आहे, कारण आम्ही फक्त कन्स्ट्रक्टर लपवतो आणि मानक कन्स्ट्रक्टरऐवजी आमची स्वतःची पद्धत देतो. कोडजिमचे विद्यार्थी या पॅटर्नच्या (आणि सर्वसाधारणपणे डिझाइन पॅटर्न) संपर्कात येतात याची खात्री करणे हा या लेखाचा उद्देश असल्याने, अधिक जटिल सिंगलटन अंमलबजावणीच्या बारकावे येथे वर्णन केल्या जाणार नाहीत. आम्ही फक्त हे लक्षात घेतो की, प्रोग्रामच्या जटिलतेनुसार, या पॅटर्नला आणखी परिष्कृत करण्याची आवश्यकता असू शकते. उदाहरणार्थ, मल्टीथ्रेडेड वातावरणात (थ्रेड्सबद्दलचे लेख पहा), अनेक भिन्न थ्रेड्स सिंगलटन पद्धतीमध्ये एकाच वेळी प्रवेश करू शकतात आणि वर वर्णन केलेला कोड कार्य करणे थांबवेल, कारण प्रत्येक स्वतंत्र थ्रेड वर्गाचे उदाहरण तयार करू शकतो. परिणामी, योग्य थ्रेड-सेफ सिंगलटन तयार करण्यासाठी अजूनही अनेक भिन्न पध्दती आहेत. पण ती दुसरी कथा आहे =)

आणि शेवटी... कर्णधाराने विचारलेल्या या आळशी सुरुवातीचे काय आहे?

आळशी इनिशिएलायझेशनला डिफर्ड इनिशिएलायझेशन असेही म्हणतात. ही प्रोग्रामिंग युक्ती आहे जिथे संसाधन-केंद्रित ऑपरेशन (आणि ऑब्जेक्ट तयार करणे हे संसाधन-केंद्रित ऑपरेशन आहे) आगाऊ ऐवजी मागणीनुसार केले जाते. तर आमच्या सिंगलटन जावा कोडमध्ये प्रत्यक्षात काय होते ? दुस-या शब्दात सांगायचे तर, आमचा ऑब्जेक्ट ज्या वेळेस प्रवेश केला जातो त्या वेळेस तयार होतो, आगाऊ नाही. तुम्ही असे गृहीत धरू नये की आळशी आरंभ हे सिंगलटन पॅटर्नशी कसे तरी कठोरपणे जोडलेले आहे. प्रॉक्सी आणि फॅक्टरी मेथड सारख्या इतर सृजनात्मक डिझाइन नमुन्यांमध्ये आळशी आरंभीकरण देखील वापरले जाते, परंतु ही देखील दुसरी कथा आहे =)