जनरेटिव पैटर्न, भाग 2

4.1 बिल्डर

बिल्डर एक जनरेटिव डिज़ाइन पैटर्न है जो एक समग्र वस्तु बनाने का एक तरीका प्रदान करता है।

एक जटिल वस्तु के निर्माण को उसके प्रतिनिधित्व से अलग करता है ताकि एक ही निर्माण प्रक्रिया के परिणामस्वरूप अलग-अलग प्रतिनिधित्व हो सकें।

ताकत:

• आपको उत्पाद के आंतरिक प्रतिनिधित्व को बदलने की अनुमति देता है;
• निर्माण और प्रस्तुति को लागू करने वाले कोड को अलग करता है;
• डिजाइन प्रक्रिया पर बेहतर नियंत्रण देता है।

कमजोर पक्ष:

• एक जटिल वस्तु बनाने के लिए एल्गोरिथ्म इस बात पर निर्भर नहीं होना चाहिए कि वस्तु में कौन से भाग हैं और वे एक साथ कैसे फिट होते हैं;
• निर्माण प्रक्रिया को निर्माण की जा रही वस्तु के विभिन्न प्रतिनिधित्व प्रदान करने चाहिए।

एक अच्छा उदाहरण HttpRequest वर्ग है, जिसमें एक उपवर्ग HttpRequest.Builder है जिसका उपयोग HttpRequest वर्ग के उदाहरण बनाने और यह सुनिश्चित करने के लिए किया जा सकता है कि वे मान्य हैं।

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

लेज़ी इनिशियलाइज़ेशन एक प्रोग्रामिंग तकनीक है जब कुछ संसाधन-गहन ऑपरेशन (वस्तु निर्माण, मूल्य गणना) इसके परिणाम का उपयोग करने से ठीक पहले किया जाता है।

इस प्रकार, आरंभीकरण "मांग पर" किया जाता है, और अग्रिम में नहीं। एक समान विचार विभिन्न क्षेत्रों में आवेदन पाता है: उदाहरण के लिए, ऑन-द-फ्लाई संकलन और जस्ट-इन-टाइम लॉजिस्टिक्स अवधारणा।

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

ताकत:

• इनिशियलाइज़ेशन तभी किया जाता है जब वास्तव में इसकी आवश्यकता होती है;
• एप्लिकेशन का प्रारंभिक आरंभीकरण त्वरित है: जो कुछ भी स्थगित किया जा सकता है वह स्थगित है।

कमजोर पक्ष:

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

याद रखें कि web.xml लिखते समय आप सर्वलेट्स के प्रारंभ क्रम को कैसे निर्दिष्ट कर सकते हैं? यह आलसी लोडिंग का नतीजा है। पहली बार एक्सेस किए जाने पर टॉमकैट सर्वलेट ऑब्जेक्ट बनाएगा।

4.3 ऑब्जेक्ट पूल

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

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

एक ऑब्जेक्ट पूल तब उपयोगी होता है जब कोई ऑब्जेक्ट मेमोरी के अलावा अन्य संसाधनों का मालिक होता है, जैसे कि नेटवर्क सॉकेट। या यदि वस्तुओं का संग्रह कंप्यूटर की मेमोरी का एक महत्वपूर्ण हिस्सा लेता है और बहुत सारे "कचरा" बन जाता है।

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