क्या कोई एक बार और सभी के लिए मुझे इन दोनों के बीच अंतर समझा सकता है और उनमें से प्रत्येक का उपयोग कब करने के लिए दिशानिर्देश देने का प्रयास कर सकता है? उदाहरण वास्तव में अच्छा होगा।रणनीति डिजाइन पैटर्न और सार कारखाना पैटर्न के बीच अंतर क्या है?
रणनीति उन भाषाओं के लिए एक समाधान है जिनके पास प्रथम श्रेणी के कार्य नहीं हैं। आप एक रणनीति ऑब्जेक्ट में जाते हैं जो कुछ नीति का निर्णय लेता है जिसे आप शेष कोड से अलग करना चाहते हैं। जावा में सॉर्ट करने और वे तुलनाकर्ताओं का उपयोग करने के बारे में सोचें, एक तुलनाकर्ता एक रणनीति वस्तु है जो आपको सॉर्टिंग एल्गोरिदम से अलग क्रमबद्ध करने के लिए नीति निर्दिष्ट करने की अनुमति देता है। यह आपको विभिन्न रणनीतियों में छोड़कर कोड का पुन: उपयोग करने की अनुमति देता है।
सार फैक्ट्री एक वस्तु है जो अन्य वस्तुओं को बनाने के लिए उपयोग की जाती है, जिसमें अमूर्त हिस्सा यह है कि आपके पास एक कारखाना है जो कारखाने के कार्यान्वयन को वापस करता है, जहां कारखाने के उपयोगकर्ता इसे इंटरफ़ेस के माध्यम से एक्सेस करते हैं। इसलिए फैक्ट्री के उपयोगकर्ताओं में कोई बदलाव नहीं होने के कारण एक फैक्ट्री कार्यान्वयन दूसरे के लिए बदल दिया जा सकता है, क्योंकि वे उपयोगकर्ता ऑब्जेक्ट्स इंटरफेस पर निर्भर करते हैं।
INTENT संरचनात्मक और कार्यान्वयन विवरण के अलावा अलग है। जैसे ही आप इसे मौलिक समझते हैं कि विचार महत्वपूर्ण है, तो आप सही रास्ते पर होंगे।
Understand the role of intent in design patterns
Intent for Strategy। यह एक व्यवहार पैटर्न
सार फैक्टरी के लिए इरादा। यह एक क्रिएशनल पैटर्न
ठीक है तो, से क्या आशय/ठहराई गई है कि उनमें से हर एक के उद्देश्य से है? मैं remmber कि startegy सही एल्गोरिदम चुनने के लिए और अधिक जुड़ा हुआ है ... लेकिन पहली वाक्य – RanZilber
फ़ैक्टरी डिजाइन पैटर्न फ़ैक्टरी के रूप में कार्य करता है और आपके अनुरोध के अनुसार रन टाइम पर विभिन्न प्रकार की ऑब्जेक्ट उत्पन्न करता है। तो नियंत्रण रन टाइम पर है और आप उस समय का ऑब्जेक्ट तय कर सकते हैं जिसकी आपको आवश्यकता है। तो वस्तुओं के बीच युग्मन कम हो जाएगा।
दूसरी तरफ, रणनीति डिजाइन पैटर्न आपको "एक" संबंध "रिश्ते" का उपयोग करके पदानुक्रमित संरचनाओं का बेहतर नियंत्रण लेने की अनुमति देता है। क्योंकि अगर हम अधिक जटिल परिदृश्य में विरासत (ए) का उपयोग करने का लुत्फ उठाते हैं तो हमें पीढ़ियों में विरासत में प्राप्त विधियों को ओवरराइड करना पड़ सकता है और यह कोड पुन: उपयोग से बचाता है।
मान लीजिए कि आप एक एनिमल क्लास (या इंटरफेस) बनाते हैं और इसमें एक चाल विधि है।
और आप इसे विस्तारित करके एक पक्षी वर्ग बनाने की उम्मीद कर रहे हैं। तो आप चाल() विधि के तहत उड़ान सुविधाओं को जोड़ देंगे। लेकिन पेंगुइन के साथ मामला क्या है? उनके पास चलने वाली विशेषताएं होंगी।
इसलिए हर बार जब आप पशु वर्ग का विस्तार करके एक पशु बनाते हैं, तो आपको बार-बार चाल() विधि को ओवरराइड करना होगा। आप स्पष्ट रूप से समझ सकते हैं कि चाल() विधि परिवर्तनों के प्रति अधिक संवेदनशील है, इसलिए सर्वोत्तम अभ्यास कोर कोड से बदलते हिस्से को अलग करना है।
बस हम() विधियों को स्थानांतरित करने के लिए एक अलग पदानुक्रम बना सकते हैं। आप सेटर विधियों के माध्यम से ऑब्जेक्ट को संबंधित चाल() विधि असाइन कर सकते हैं। तो नियंत्रण समय चलाने के लिए पारित किया जाता है। निम्नलिखित चित्र उस तथ्य को दर्शाता है;
के बाद अपने ब्लॉग पोस्ट में से 2 हैं अगर आप आप उन्हें अधिक जानकारी के लिए उल्लेख कर सकते हैं पसंद है।
बेहतर के लिए –
+1 पर भरोसा करने के लिए कुछ नहीं मिला। मैं आपको बेहतर उत्तर के साथ भी सामान्य रूप से सामान्य रूप से अपने ब्लॉग से जोड़ने के बारे में सावधान रहने के लिए प्रोत्साहित करता हूं। यह 'प्रकटीकरण' आवश्यकता को पूरा करता है, लेकिन यह बहुत अधिक अर्थहीन fluff है। इस तरह के बहुत सारे जवाब, और आप अभी भी * स्पैम के लिए ध्वजांकित किया जा सकता है। – thepirat000