2010-02-11 16 views
5

मैंने सामान्य कारण से पहले कारखानों का कभी भी उपयोग नहीं किया है, मुझे समझ में नहीं आता कि मुझे उनकी आवश्यकता है। मैं अपने खाली समय में एक छोटे से खेल पर काम कर रहा हूं, और मैंने ध्वनि के लिए एफएमओडी लागू करने का फैसला किया। मैं एक आवरण OpenAL के लिए बनाया गया (विभिन्न ध्वनि सेटअप) को देखा और यह कुछ की तरह लग रहा था ...कारखानों को समझना और क्या मुझे उनका उपयोग करना चाहिए?

SoundObject * SoundObjectManager * SoundObjectFactory *

SoundObject मूल रूप से प्रत्येक ध्वनि वस्तु का उदाहरण था। SoundObjectManager बस इन सभी वस्तुओं का प्रबंधन करता है। यह सीधे आगे है और बहुत समझ में आता है, लेकिन मुझे नहीं लगता कि कारखाना क्या कर रहा है या इसका क्या उपयोग किया जाता है। मैं फैक्ट्री पर पढ़ रहा हूं लेकिन अभी भी उन्हें वास्तव में नहीं मिला है।

किसी भी मदद की सराहना की जाएगी!

उत्तर

2

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

+0

तो इस तरह के कुछ के लिए वास्तव में इसकी आवश्यकता नहीं है? ध्यान में रखते हुए मैं हमेशा SoundObject * के उदाहरणों और प्रबंधक के एक सिंगलटन का उपयोग कर रहा हूं। –

+0

यदि आपके पास अलग-अलग SoundObject उपप्रकार नहीं हैं, तो मैं "नहीं" कहूंगा। – duffymo

+0

वास्तव में, पैटर्न को नियोजित करने का इरादा उनके उपयोग से वस्तुओं के निर्माण को अपनाना है। यह बेस क्लास का उपयोग करने वाले कोड में कोई बदलाव नहीं होने के साथ नए व्युत्पन्न प्रकारों को पेश करने की अनुमति देता है। आपके पास शायद SoundObject के उपप्रकार हैं, लेकिन आप इसे नहीं जानते हैं, फैक्ट्री आपको उन कार्यान्वयन विवरणों से प्रेरित करती है –

1

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

1

हाइपोटेटिकल स्थिति: मैं एक ध्वनि पुस्तकालय लिख रहा हूं जिसे मैं कई प्लेटफॉर्म पर चलाने के लिए चाहता हूं। मैं प्लेटफॉर्म को जितना संभव हो उतना कोड बनाने की कोशिश करूंगा, लेकिन निश्चित रूप से इसमें से कुछ को विंडोज बनाम ओएसएक्स बनाम लिनक्स के लिए बदलना होगा।

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

तो मैं इस अच्छे जेनेरिक SoundObject बेस क्लास को परिभाषित करता हूं जो क्लाइंट का उपयोग करने के सभी तरीकों को परिभाषित करता है। फिर मैं अपना LinuxSoundObject, WindowsSoundObject बना देता हूं, और 5 अन्य SoundObject से प्राप्त होते हैं। लेकिन मैं उपयोगकर्ता से इन सभी ठोस कार्यान्वयन को छिपाने जा रहा हूं और केवल उन्हें SoundObject प्रदान करता हूं। इसके बजाय, आपको अपने SoundObjectFactory को एक सादा पुराना SoundObject होने के लिए प्रतीत होता है, लेकिन वास्तव में मैंने आपके लिए सही रनटाइम प्रकार चुना है और इसे स्वयं चालू कर दिया है।

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

यह सब बहुत बढ़िया है, लेकिन उम्मीद है कि आपको यह विचार मिल जाएगा।

कारखाने एक इंटरफ़ेस के उपभोक्ताओं को अलग-अलग रनटाइम प्रकार (यानी कार्यान्वयन) से अलग करते हैं।

+0

यह सही समझ में आता है, आपको डमीज किताबों के लिए C++ लिखना चाहिए। जहां तक ​​यह लिंक ऊपर जाता है, मैंने ऊपर टिप्पणी में पोस्ट किया है, फिर भी मुझे यकीन नहीं है कि hes क्या कर रहा है, लेकिन यह कारखाने का उपयोग करके इसे मूवबल ऑब्जेक्ट में बदलने के लिए hes की तरह दिखता है, लेकिन मुझे वास्तव में यह नहीं मिलता है। चूंकि यह सिर्फ एक सीखने की परियोजना है जिसे मैं बिना किसी के लिए जाने जा रहा हूं, मुझे लगता है और मुझे पता चलेगा कि मुझे भविष्य में एक का उपयोग करने की आवश्यकता है। –

+0

यह सी ++ विशिष्ट नहीं है, यह सभी ओओ भाषाओं (और कुछ गैर-ओओ) के लिए एक सामान्य डिजाइन पैटर्न है –

0

कारखानों का उपयोग नियंत्रण में उलझन को लागू करने के लिए किया जा सकता है, और आपके घटकों के तर्क से तत्काल कोड ('नया) अलग करने के लिए किया जा सकता है। जब आप यूनिट परीक्षण लिख रहे हों तो यह सहायक होता है क्योंकि आप अन्य ऑब्जेक्ट्स का समूह बनाने के लिए परीक्षण ऑब्जेक्ट्स नहीं चाहते हैं।

संबंधित मुद्दे