इंजीनियरिंग सॉफ्टवेयर डिजाइन में सिंगलटन, फैक्टरी और प्रोटोटाइप पैटर्न के बीच कैसे चुनें

तीन कोर क्रिएशनल पैटर्न को समझना

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

सिंगलटन पैटर्न: एक इंस्टेंस टू रूल्स थम ऑल

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

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

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

public class DatabaseConnectionPool {
 private static DatabaseConnectionPool instance;
 private DatabaseConnectionPool() { /* initialization */ }
 public static synchronized DatabaseConnectionPool getInstance() {
 if (instance == null) {
 instance = new DatabaseConnectionPool();
 }
 return instance;
 }
}

जब सिंगलटन शाइन

]] एक कनेक्शन पूल, एक लॉगिंग सेवा, या एक विन्यास प्रबंधक एक ही बिंदु से समन्वय लाभ.
Global state:] जब एक आवेदन-व्यापी कैश या रजिस्ट्री को लगातार पहुंच की आवश्यकता होती है।
]हार्डवेयर या ओएस स्तर के संसाधनों: फ़ाइल सिस्टम, प्रिंटर स्पूलर, या विंडो मैनेजर आम तौर पर केवल एक ही उदाहरण की अनुमति देते हैं।

आम नुकसान से बचने के लिए

Overuse: हर चीज के लिए सिंगलटन का उपयोग करने से छिपे हुए निर्भरता की ओर जाता है और यूनिट परीक्षण को कठिन बना देता है क्योंकि आप आसानी से इस तरह के मजाक के साथ बदल नहीं सकते।
]Thread-safety ओवरहेड: क्लासिक सिंक्रनाइज़ विधि एक bottleneck बन सकता है। उत्सुक प्रारंभिककरण या डबल चेक लॉकिंग (ज्वलनशील के साथ) जैसे विकल्प कंटेंटियन को कम करते हैं।
Tight युग्मन: क्योंकि वैश्विक पहुंच बिंदु हार्ड-कोडित है, ग्राहक निर्भरता उलटा सिद्धांत का उल्लंघन करते हुए कंक्रीट सिंगलटन कक्षा में जुड़ जाते हैं।

इन कमियों के बावजूद, सिंगलटन उपयोगी रहता है जब आपको वास्तव में एक, वैश्विक रूप से सुलभ वस्तु की आवश्यकता होती है। गहरी समझ के लिए, देखें Reactoring Guru's Singleton गाइड.

फैक्टरी पैटर्न: ऑब्जेक्ट क्रिएशन को प्रतिनिधि करना

फैक्टरी पैटर्न ऑब्जेक्ट इंस्टेंटिएशन लॉजिक को encapsulates, जो उपवर्गों को यह तय करने की अनुमति देता है कि किस वर्ग को तत्काल करने के लिए कौन सा वर्ग है। यह दो मुख्य जायके में आता है: फैक्टरी विधि (एक एकल विधि जो नई वस्तुओं को लौटाती है) और Abstract Factory (संबंधित कारखाने के तरीकों का एक परिवार)। दोनों ठोस वर्गों से क्लाइंट कोड को अलग करते हैं, ढीले युग्मन और आसान एक्सटेन्सिबिलिटी को बढ़ावा देते हैं।

विस्तार में फैक्टरी विधि

किसी वस्तु को बनाने के लिए एक इंटरफेस को परिभाषित करें, लेकिन उपवर्गों को उन वस्तुओं के प्रकार को बदलने दें जो बनाई जाएंगी। उदाहरण के लिए, एक संवाद वर्ग में एक विधि हो सकती है । WindowsDialog और LinuxDialog जैसे सबक्लास इस विधि को मंच-विशिष्ट बटन वापस करने के लिए ओवरराइड करते हैं।

abstract class Dialog {
 abstract Button createButton();
 public void render() {
 Button okButton = createButton();
 okButton.onClick();
 }
}
class WindowsDialog extends Dialog {
 Button createButton() { return new WindowsButton(); }
}

यह पैटर्न कब आदर्श है:

एक वर्ग वस्तु के वर्ग को नहीं मान सकता है।
आप एक ही स्थान पर ऑब्जेक्ट निर्माण तर्क को स्थानीय बनाना चाहते हैं।
इस प्रणाली को स्वतंत्र होना चाहिए कि इसकी वस्तुओं का निर्माण कैसे किया जाता है।

अमूर्त फैक्टरी: संबंधित वस्तुओं की परिवारों का निर्माण

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

यह पैटर्न तब पसंद किया जाता है:

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

फैक्टरी और अन्य पैटर्न के बीच निर्णय लेना

जब ऑब्जेक्ट निर्माण जटिल होता है या जब आपको रनटाइम पर कार्यान्वयन को स्वैप करने की आवश्यकता होती है तो फैक्टरी आपका गो-टू है। यह सिंगलटन की तुलना में अधिक लचीला है क्योंकि यह उदाहरणों की संख्या को सीमित नहीं करता है - यह केवल निर्माण को केंद्रीय बनाता है। प्रोटोटाइप के विपरीत, फैक्टरी मौजूदा लोगों की प्रतिलिपि के बजाय खरोंच से नए उदाहरण बनाता है। दोनों रूपों के व्यापक अवलोकन के लिए, यात्रा गुरु के फैक्टरी विधि पृष्ठ को पुन: सक्रिय करना और ]Abstract Factory page]।

प्रोटोटाइप पैटर्न: निर्माण के बजाय क्लोन

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

क्लोनिंग मैकेनिक्स: शालो बनाम डीप कॉपी

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

class MazePrototype {
 public MazePrototype clone() throws CloneNotSupportedException {
 return (MazePrototype) super.clone(); // shallow copy
 }
}

प्रोटोटाइप के लिए आदर्श परिदृश्य

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

प्रोटोटाइप रजिस्ट्री और कैशिंग

आप एक रजिस्ट्री को लागू करके प्रोटोटाइप को आगे ले जा सकते हैं- एक कुंजी द्वारा अनुक्रमित पूर्व निर्मित प्रोटोटाइप का एक केंद्रीय स्टोर। ग्राहक कुंजी द्वारा प्रोटोटाइप का अनुरोध करते हैं, इसे क्लोन करते हैं, और इसे अनुकूलित करते हैं। एक रजिस्ट्री के साथ प्रोटोटाइप का यह संयोजन कुछ मामलों में फैक्ट्री या सिंगलटन के लिए हल्के विकल्प के रूप में काम कर सकता है। विस्तृत walkthrough के लिए, देखें ]Rereactoring गुरु के प्रोटोटाइप गाइड].

साइड-बाय-साइड तुलना: सिंगलटन, फैक्टरी, प्रोटोटाइप

आप चुनने में मदद करने के लिए, नीचे दी गई तालिका मुख्य अंतर को उजागर करती है:

Pattern	Instance Count	Creation Mechanism	Best For
Singleton	Exactly one	Self-managed global access	Shared resources, global state
Factory	Multiple instances (or families)	Centralized creation logic	Decoupling client from concrete classes, complex creation
Prototype	Multiple instances cloned from a template	Cloning (shallow/deep copy)	Expensive instantiation, runtime object generation

जब पैटर्न ओवरलैप या संयोजन

एकलटन + फैक्टरी:एक कारखाना स्वयं एक सिंगलटन (जैसे, एक अमूर्त कारखाना प्रति मंच) हो सकता है। यह केंद्रीकृत निर्माण के साथ वैश्विक पहुंच को जोड़ती है।
Prototype + Factory: एक प्रोटोटाइप रजिस्ट्री एक कारखाने के रूप में कार्य कर सकते हैं - आप एक निर्माता को बुलाने के बजाय एक प्रोटोटाइप क्लोन करते हैं। यह विशेष रूप से खेल विकास में उपयोगी है जब स्पॉनिंग संस्थाओं।
Prototype + Singleton: एक प्रोटोटाइप वस्तु इस अर्थ में एक सिंगलटन हो सकता है कि केवल एक प्रोटोटाइप उदाहरण प्रति प्रकार मौजूद है, हालांकि क्लोन सिंगलटोन नहीं हैं।

प्रैक्टिकल निर्णय

जब आप एक डिज़ाइन समस्या का सामना करते हैं, तो एक रचनात्मक पैटर्न के लिए कॉल करते हैं, तो इन सवालों को क्रम में पूछते हैं:

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

इंजीनियरिंग सॉफ्टवेयर में रियल-विश्व उदाहरण

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

निष्कर्ष: अपने डिजाइन को अनुकूलित करने के लिए पैटर्न मत करो

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

इन तीन पैटर्नों को मास्टर करके, आप अपने आप को मजबूत, लचीला इंजीनियरिंग सॉफ्टवेयर बनाने के लिए बहुमुखी टूलकिट से लैस करते हैं। आगे पढ़ने के लिए, सॉफ्टवेयर डिजाइन पैटर्न पर विकिपीडिया लेख का पता लगाएं और ]]]] निर्माण पैटर्न के गुरु अवलोकन को पुन: निष्क्रिय करना [[FLT: 3]]]]]।