design patterns - हमें सार कारखाने के डिजाइन पैटर्न की आवश्यकता क्यों है?




design-patterns abstract-factory (9)

अधिकांश परिभाषा कहती है:

एक अमूर्त कारखाना संबंधित कंक्रीट वर्गों को निर्दिष्ट किए बिना संबंधित वस्तुओं के परिवार बनाने के लिए एक इंटरफ़ेस प्रदान करता है

सार फैक्टरी पैटर्न का उपयोग क्या है क्योंकि हम ठोस वर्ग की वस्तु बनाकर कार्य प्राप्त कर सकते हैं। हमारे पास एक कारखाना विधि क्यों है जो कंक्रीट कक्षा का उद्देश्य बनाती है?

कृपया मुझे कोई वास्तविक जीवन उदाहरण प्रदान करें जहां मुझे अमूर्त कारखाना पैटर्न लागू करना होगा?


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

सी # में सार फैक्टरी पैटर्न को समझना और कार्यान्वित करना


सार फैक्टरी पैटर्न का उपयोग क्या है क्योंकि हम ठोस वर्ग की वस्तु बनाकर कार्य प्राप्त कर सकते हैं। हमारे पास एक कारखाना विधि क्यों है जो कंक्रीट कक्षा का उद्देश्य बनाती है?

सार फैक्ट्री की अनुपस्थिति में, ग्राहक को ठोस वर्गों के विवरण जानने की आवश्यकता है। इस तंग युग्मन को सार फैक्ट्री के साथ हटा दिया गया है।

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

बेहतर समझने के लिए इन संबंधित एसई प्रश्नों का संदर्भ लें:

फैक्टरी और सार फैक्टरी पैटर्न के बीच बुनियादी अंतर क्या है?

आशय:

संबंधित या आश्रित वस्तुओं के परिवारों को उनके ठोस वर्ग निर्दिष्ट किए बिना एक इंटरफ़ेस प्रदान करें।

आप इस sourcemaking लेख से सार फैक्टरी पैटर्न के अंगूठे के इरादे, संरचना, चेकलिस्ट और नियमों को समझ सकते हैं।

चेकलिस्ट:

  1. तय करें कि मंच स्वतंत्रता और निर्माण सेवाएं दर्द का वर्तमान स्रोत हैं या नहीं।
  2. प्लेटफॉर्म बनाम उत्पादों के मैट्रिक्स को मानचित्र बनाएं।
  3. एक कारखाने इंटरफ़ेस को परिभाषित करें जिसमें प्रति उत्पाद फ़ैक्टरी विधि शामिल है।
  4. प्रत्येक प्लेटफार्म के लिए फैक्ट्री व्युत्पन्न कक्षा को परिभाषित करें जो नए ऑपरेटर के सभी संदर्भों को समाहित करता है।
  5. ग्राहक को सभी संदर्भों को नए सेवानिवृत्त करना चाहिए, और उत्पाद वस्तुओं को बनाने के लिए कारखाने के तरीकों का उपयोग करना चाहिए।

आपके कोड-बेस को एकीकृत रखते हुए कई प्लेटफ़ॉर्म का समर्थन करने के लिए सार फैक्ट्री बहुत बढ़िया हैं। मान लें कि आपके पास एक बड़ा क्यूटी या जीटीके + या .NET / मोनो प्रोग्राम है जिसे आप विंडोज, लिनक्स और ओएसएक्स पर चलाना चाहते हैं। लेकिन आपके पास एक सुविधा है जो प्रत्येक प्लेटफ़ॉर्म पर एक अलग तरीके से लागू की जाती है (शायद कर्नेल 32 एपीआई या पॉज़िक्स सुविधा के माध्यम से)।

public abstract class Feature
{
    public abstract int PlatformSpecificValue { get; }

    public static Feature PlatformFeature
    {
        get
        {
            string platform;
            // do platform detection here
            if (platform == "Win32")
                return new Win32Feature();
            if (platform == "POSIX")
                return new POSIXFeature();
        }
    }

    // platform overrides omitted
}

इस सार फैक्टरी के साथ, आपके यूआई को वर्तमान प्लेटफ़ॉर्म के बारे में कुछ भी जानने की आवश्यकता नहीं है।

Feature feature = Feature.PlatformFeature;
Console.WriteLine(feature.PlatformSpecificValue);

मान लें कि आप ajar बनाते हैं, और कोई और आपके जार का उपयोग करता है और आपके कोड में एक नई ठोस वस्तु का उपयोग करना चाहता है। यदि आप अमूर्त कारखाने का उपयोग नहीं कर रहे हैं, तो उसे आपके कोड को संशोधित करना होगा या अपना कोड ओवरराइट करना होगा। लेकिन यदि आप अमूर्त कारखाने का उपयोग कर रहे हैं, तो वह एक कारखाना प्रदान कर सकती है और आपके कोड को पास कर सकती है और सबकुछ ठीक है।

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


मैं सार फैक्टरी पैटर्न overrated पाया।

सबसे पहले, ऐसा नहीं होता है कि अक्सर आपके पास अंतःसंबंधित प्रकार का एक सेट होता है जिसे आप तुरंत चालू करना चाहते हैं।

दूसरा, निर्भरता इंजेक्शन के साथ काम करते समय इंटरफेस द्वारा प्रदान किए गए संकेत (अबास्ट्रक्शन) का स्तर सामान्य रूप से पर्याप्त होता है।

विंडोजगुई बनाम मैकगुई बनाम का सामान्य उदाहरण ... जहां आपके पास विंडोजबटन, मैकबटन, विंडोजस्क्रोलबार, मैकस्क्रॉलबार इत्यादि होगा, आगंतुकों और / या इंटरप्रेटर पैटर्न का उपयोग करके कंक्रीट बटन, स्क्रॉलबार इत्यादि को परिभाषित करके अक्सर कार्यान्वित करना आसान होता है। वास्तविक व्यवहार


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


यह निर्भरताओं के बारे में सब कुछ है। यदि आपको तंग युग्मन और निर्भरताओं की परवाह नहीं है, तो आपको एक अमूर्त कारखाने की आवश्यकता नहीं है। लेकिन जैसे ही आप एक आवेदन लिखते हैं, जो रखरखाव की आवश्यकता है, इससे कोई फर्क नहीं पड़ता।


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

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


सीधे अपने प्रश्न का उत्तर देने के लिए, आप शायद इस तरह के एक डिजाइन पैटर्न का उपयोग किए बिना दूर हो सकते हैं।

हालांकि, ध्यान रखें कि वास्तविक दुनिया में अधिकांश परियोजनाएं विकसित होती हैं और आप अपनी परियोजना भविष्य के सबूत बनाने के लिए किसी प्रकार की विस्तारशीलता प्रदान करना चाहते हैं।

अपने अनुभव से, ज्यादातर समय, फैक्ट्री लागू की जाती है और जैसे ही परियोजना बढ़ती है, यह सार फैक्ट्री जैसे जटिल डिजाइन पैटर्न में बदल जाती है।





abstract-factory