जावा / जावा ईई में समान जटिलता का प्रबंधन करते समय एक और लोकप्रिय भाषा कारखाने के पैटर्न का उपयोग करने से कैसे बचेंगी?

Question

फ़ैक्टरी पैटर्न (या कम से कम उपयोग FactoryFactory..) कई चुटकुलों का बट है, जैसे यहां ।

वर्बोज़ और "क्रिएटिव" नाम जैसे RequestProcessorFactoryFactory.RequestProcessorFactory होने के अलावा , क्या फैक्ट्री पैटर्न के साथ मौलिक रूप से कुछ भी गलत है अगर आपको जावा / सी ++ में प्रोग्राम करना है और Abstract_factory_pattern का usecase है ?

एक और लोकप्रिय भाषा (उदाहरण के लिए, रूबी या स्काला ) समान जटिलता का प्रबंधन करते समय इसका उपयोग करने से कैसे बचेंगी?

मैं जो कारण पूछ रहा हूं वह यह है कि मैं ज्यादातर जावा / जावा ईई पारिस्थितिकी तंत्र के संदर्भ में वर्णित कारखानों की आलोचना देख रहा हूं , लेकिन वे कभी नहीं समझाते हैं कि अन्य भाषाएं / रूपरेखा उन्हें कैसे हल करती हैं।

Comments

के संभावित डुप्लिकेट कहाँ सभी कार्यात्मक प्रोग्रामिंग डिजाइन पैटर्न रहे हैं?

— gnat

समस्या कारखानों का उपयोग नहीं है - यह एक पूरी तरह से ठीक पैटर्न है। यह कारखानों का अति प्रयोग है जो विशेष रूप से एंटरप्रीज जावा दुनिया में प्रचलित है।

— कोडइन्चोस

बहुत अच्छा जोक लिंक। मुझे मसाला रैक बनाने के लिए उपकरण को पुनः प्राप्त करने की एक कार्यात्मक भाषा व्याख्या देखना अच्छा लगेगा। मुझे लगता है कि यह वास्तव में घर चलाएगा।

— पैट्रिक एम।

Answer 1

आपके प्रश्न को "जावा" के साथ टैग किया गया है, कोई आश्चर्य नहीं कि आप पूछ रहे हैं कि फैक्ट्री पैटर्न का मज़ाक क्यों उड़ाया जा रहा है: जावा स्वयं उस पैटर्न के अच्छी तरह से पैक की गई गालियों के साथ आता है।

उदाहरण के लिए, फ़ाइल से XML दस्तावेज़ लोड करने का प्रयास करें और इसके विरुद्ध XPath क्वेरी चलाएँ। फैक्टरियों और बिल्डर्स को सेटअप करने के लिए आपको कोड की 10 लाइनों की तरह कुछ चाहिए:

DocumentBuilderFactory builderFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = builderFactory.newDocumentBuilder(); 

Document xmlDocument = builder.parse(new FileInputStream("c:\\employees.xml"));
XPath xPath =  XPathFactory.newInstance().newXPath();

xPath.compile(expression).evaluate(xmlDocument);

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

चूँकि आप पूछ रहे हैं कि यहाँ पर C # में XML फ़ाइल लोड करने का विकल्प क्या है:

XDocument xml = XDocument.Load("c:\\employees.xml");
var nodes = xml.XPathSelectElements(expression);

मुझे शक है कि नए हैटेड जावा डेवलपर्स फैक्ट्री के पागलपन को देखते हैं और सोचते हैं कि ऐसा करना ठीक है - अगर जिन जीनियस ने स्वयं जावा का निर्माण किया है, उन्होंने उनका इतना उपयोग किया है।

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

Comments

बस ध्यान दें कि आपका C # विकल्प XML के लिए नए LINQ का उपयोग कर रहा है - पुराने DOM विकल्प को कुछ इस तरह देखा होगा: XmlDocument xml = new XmlDocument(); xml.Load("c:\\employees.xml"); XmlNodeList nodes = xml.SelectNodes(expression); (कुल मिलाकर, LINQ to XML का उपयोग करना कहीं अधिक आसान है, हालांकि ज्यादातर अन्य क्षेत्रों में।) और यहाँ एक KB लेख है। मैंने एमएस-अनुशंसित विधि के साथ पाया: support.microsoft.com/kb/308333

— Bob

Answer 2

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

और यह कि कोई संदेह नहीं है कि जिस तरह से प्रोग्रामिंग (और पैटर्न) सिखाया जाता है। स्कूली बच्चे (अक्सर खुद को "छात्र" कहते हैं) को "पैटर्न वाई का उपयोग करके एक्स" बनाने के लिए कहा जाता है और इसके कुछ पुनरावृत्तियों के बाद लगता है कि यह किसी भी प्रोग्रामिंग समस्या का सामना करने का तरीका है।
इसलिए वे एक विशिष्ट पैटर्न को लागू करना शुरू करते हैं जो वे किसी भी चीज और हर चीज के खिलाफ स्कूल में पसंद करते हैं, चाहे वह उचित हो या नहीं।

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

सिस्टम में 5 वें सामान्य रूप में एक डेटाबेस सामान्य था (I kid you not)।

एक प्रणाली जो अनिवार्य रूप से एक पता पुस्तिका की तुलना में थोड़ी अधिक थी जिसका उपयोग आने वाले और बाहर जाने वाले दस्तावेजों को लॉग और ट्रैक करने के लिए किया जा सकता था, इसमें C ++ में 100MB कोडबेस और 50 से अधिक डेटाबेस टेबल थे। सॉफ्टवेयर चलाने वाले कंप्यूटर से सीधे जुड़े हुए प्रिंटर का उपयोग करते हुए 500 फॉर्म अक्षरों को प्रिंट करने में 72 घंटे का समय लगेगा।

वे लोग क्यों पैटर्न का उपहास करते हैं, और विशेष रूप से लोग एकल विशिष्ट पैटर्न पर ध्यान केंद्रित करते हैं।

Comments

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

— डोभाल

इस उपाख्यान के लिए धन्यवाद। क्या आप "विकल्प क्या हैं?" पर थोड़ा विस्तार कर सकते हैं। सवाल का हिस्सा तो हम भी वैसा नहीं बन जाते?

— फिलिप

@ डोवल क्या आप मुझे बता सकते हैं कि आप निष्पादित कमांड या वैल्यू स्ट्रैटेजी से वैल्यू कैसे लौटाते हैं जब आप केवल फ़ंक्शन पास कर सकते हैं? और यदि आप बंद कहते हैं, तो ध्यान रखें कि कक्षा बनाने के समान बिल्कुल स्पष्ट है, और अधिक स्पष्ट को छोड़कर।

— व्यंग्यात्मक

@ जोश मैं समस्या नहीं देख रहा हूँ, क्या आप विस्तृत कर सकते हैं? किसी भी मामले में, वे एक ही बात नहीं हैं। आप किसी एकल फ़ील्ड वाली किसी वस्तु की तुलना में ठीक वैसा ही कह सकते हैं, जैसा कि एक चर के लिए एक पॉइंटर / संदर्भ के रूप में होता है या एक पूर्णांक एक (वास्तविक) एनम के समान होता है। व्यवहार में मतभेद हैं: यह कार्यों की तुलना करने के लिए कोई मतलब नहीं है; मुझे अभी तक अनाम कक्षाओं के लिए संक्षिप्त वाक्यविन्यास देखना है; और एक ही तर्क और वापसी प्रकार वाले सभी कार्यों में एक ही प्रकार (विभिन्न नामों के साथ वर्गों / इंटरफेस के विपरीत, जो अलग-अलग प्रकार के होते हैं जब वे समान होते हैं।)

— डोभाल

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

— डोभाल

Answer 3

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

WidgetFactory redWidgetFactory = new ColoredWidgetFactory(COLOR_RED);
Widget widget = redWidgetFactory.create();

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

WidgetBuilder widgetBuilder = new WidgetBuilder();
widgetBuilder.setColor(COLOR_RED);
Widget widget = widgetBuilder.create();

लेकिन जब ओवरगेंरिंग आपकी समस्या है, तो एक बिल्डर के साथ एक कारखाने की जगह में सुधार की संभावना नहीं है।

या तो पैटर्न के लिए सबसे सरल प्रतिस्थापन newऑपरेटर के साथ एक साधारण निर्माता के साथ ऑब्जेक्ट-इंस्टेंस बनाने के लिए है :

Widget widget = new ColoredWidget(COLOR_RED);

कंस्ट्रक्टर्स, हालांकि, अधिकांश ऑब्जेक्ट-ओरिएंटेड भाषाओं में एक महत्वपूर्ण कमी है: उन्हें उस सटीक वर्ग की एक वस्तु वापस करनी चाहिए और एक उप-प्रकार वापस नहीं कर सकते।

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

 Widget widget = Widget.createColoredWidget(COLOR_RED); // returns an object of class RedColoredWidget

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

Comments

एक कारखाना अक्सर निर्माण के बाद भी कॉन्फ़िगर किया जा सकता है। एक बिल्डर के लिए मुख्य अंतर, afaik, यह है कि एक बिल्डर का उपयोग आमतौर पर एकल, जटिल उदाहरण बनाने के लिए किया जाता है, जबकि कारखानों का उपयोग कई समान उदाहरण बनाने के लिए किया जाता है।

— सेफालोपॉड

धन्यवाद (+1), लेकिन उत्तर यह समझाने में विफल रहता है कि अन्य पीएल इसे कैसे हल करेंगे, फिर भी जावा 8 विधि संदर्भों को इंगित करने के लिए धन्यवाद।

— अर्थव्यू

मैंने अक्सर सोचा है कि यह वास्तविक ऑब्जेक्ट निर्माण को प्रश्न के प्रकार तक सीमित करने के लिए ऑब्जेक्ट-ओरिएंटेड फ्रेमवर्क में समझ में आएगा, और इसके foo = new Bar(23);समकक्ष होगा foo = Bar._createInstance(23);। किसी ऑब्जेक्ट को निजी getRealType()विधि का उपयोग करके अपने स्वयं के प्रकार को मज़बूती से क्वेरी करने में सक्षम होना चाहिए , लेकिन वस्तुओं को बाहरी कॉल द्वारा लौटाए जाने के लिए एक सुपरपाइप को नामित करने में सक्षम होना चाहिए getType()। बाहरी कोड को इस बात की परवाह नहीं करनी चाहिए कि क्या new String("A")वास्तव में एक कॉल उदाहरण के लिए String[ उदाहरण के लिए विरोध किया गया है SingleCharacterString]।

— सुपरकैट

जब मैं संदर्भ के आधार पर एक उपवर्ग का चयन करने की आवश्यकता होती है, तो मैं बहुत सारे स्टैटिक विधि कारखानों का उपयोग करता हूं, लेकिन अंतर कॉल करने वाले के लिए अपारदर्शी होना चाहिए। उदाहरण के लिए, मेरे पास छवि वर्गों की एक श्रृंखला है जिसमें सभी शामिल हैं, draw(OutputStream out)लेकिन थोड़ा अलग HTML उत्पन्न करते हैं, स्थैतिक विधि का कारखाना स्थिति के लिए सही वर्ग बनाता है और फिर कॉल करने वाला केवल ड्रा विधि का उपयोग कर सकता है।

— माइकल शोपिन

@ supercat आप उद्देश्य-सी पर एक नज़र लेने में रुचि हो सकती है। वस्तुओं के निर्माण में आमतौर पर सरल विधि कॉल शामिल होते हैं [[SomeClass alloc] init]। एक पूरी तरह से अलग श्रेणी की आवृत्ति या किसी अन्य ऑब्जेक्ट (जैसे कैश्ड मान) को वापस करना संभव है

— axelarge

Answer 4

उपयुक्त परिस्थितियों में एक वस्तु या किसी अन्य की वस्तुएं बहुत अधिक किसी भी वस्तु-उन्मुख भाषा में पाई जाती हैं। कभी-कभी आपको एक सादे पैरामीटर को स्ट्रिंग की तरह बनाने के लिए किस तरह की वस्तु का चयन करने के लिए बस सादे तरीके की आवश्यकता होती है।

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

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

इसके अलावा, जैसा कि अन्य टिप्पणियों और उत्तरों ने बताया है, क्लोजर और प्रथम श्रेणी के कार्य कई पैटर्न की आवश्यकता को कम करते हैं। इस कारण से, मेरा मानना ​​है कि कई विरोधी प्रतिमान C ++ 11 और Java 8 के व्यापक रूप से अपनाने के रूप में गायब होने लगेंगे।

Comments

धन्यवाद (+1)। आपका जवाब इस बारे में मेरी कुछ शंकाओं की व्याख्या करता है कि स्काला इससे कैसे बचेंगी। ईमानदारी से, क्या आपको नहीं लगता कि एक बार (यदि) स्काला कम से कम जावा के रूप में लोकप्रिय हो जाता है तो उद्यम स्तर पर, चौखटों की सेनाएं, पैटर्न, पेड ऐप सर्वर आदि पॉप-अप होंगे?

— सेंडविवो

मुझे लगता है कि अगर स्काला जावा से आगे निकल जाता है, तो ऐसा इसलिए होगा क्योंकि लोग आर्किटेक्चरिंग सॉफ्टवेयर के "स्काला तरीका" को पसंद करते हैं। जावा 5 और जेनेरिक और जावा 8 लैंबडैस और स्ट्रीम की तरह लोगों को स्कैला पर स्विच करने के लिए ड्राइव करने वाली अधिक से अधिक सुविधाओं को अपनाने के लिए जावा ने अधिक संभावना के रूप में मुझ पर क्या प्रहार जारी रखा है, उम्मीद है कि अंततः उन प्रोग्रामर्स का परिणाम होगा जो विरोधी पैटर्न को छोड़ देते हैं जो उन पर उछला। सुविधाएँ उपलब्ध नहीं थीं। हमेशा फैक्ट्रीफैक्टरी के पालनकर्ता होंगे, चाहे कितनी भी अच्छी भाषा हो। जाहिर है कुछ लोग उन आर्किटेक्चर को पसंद करते हैं, या वे इतने सामान्य नहीं होंगे।

— कार्ल बेज़ेलफेल्ट

Answer 5

सामान्य तौर पर, यह प्रवृत्ति है कि जावा कार्यक्रम बुरी तरह से अधिक इंजीनियर हैं [उद्धरण वांछित]। कई कारखानों का होना अति-इंजीनियरिंग के सबसे आम लक्षणों में से एक है; इसलिए लोग उनका मजाक बनाते हैं।

विशेष रूप से, जावा के कारखानों के साथ समस्या यह है कि जावा में क) निर्माता कार्य नहीं कर रहे हैं और बी) कार्य प्रथम श्रेणी के नागरिक नहीं हैं।

कल्पना कीजिए कि आप इस तरह से कुछ लिख सकते हैं ( JREFunction का एक जाना-माना इंटरफ़ेस हो )

// Framework code
public Node buildTree(Function<BranchNode, Node, Node> branchNodeFactory) {
    Node current = nextNode();
    while (hasNextNode()) {
        current = branchNodeFactory.call(current, nextNode());
    }
    return current
}

// MyDataNode.java
public class MyBranchNode implements BranchNode {

    public MyBranchNode(Node left, Node right) { ... }
}

// Client code
Node root = buildTree(MyBranchNode::new);

देखें, कोई कारखाना इंटरफेस या कक्षाएं नहीं। कई गतिशील भाषाओं में प्रथम श्रेणी के कार्य होते हैं। काश, यह जावा 7 या उससे पहले (कारखानों के साथ लागू नहीं होता है, पाठक के लिए एक अभ्यास के रूप में छोड़ दिया जाता है)।

तो, विकल्प इतना अधिक नहीं है "एक अलग पैटर्न का उपयोग करें", लेकिन अधिक "एक बेहतर ऑब्जेक्ट मॉडल के साथ एक भाषा का उपयोग करें" या "सरल समस्याओं को खत्म न करें"।

Comments

यह पूछे गए प्रश्न का उत्तर देने का प्रयास भी नहीं करता है: "विकल्प क्या हैं?"

— gnat

पिछले पैराग्राफ को पढ़ें और आपको "अन्य भाषाएं कैसे करें" भाग मिलेगा। (पुनश्च: अन्य उत्तर भी विकल्प नहीं दिखाते हैं)

— सेफेलोपॉड

@gnat क्या वह परोक्ष रूप से यह नहीं कह रहा है कि विकल्प प्रथम श्रेणी के कार्यों का उपयोग करना है? यदि आप चाहते हैं कि एक ब्लैक बॉक्स है जो ऑब्जेक्ट्स बना सकता है, तो आपके विकल्प या तो एक कारखाने या एक फ़ंक्शन हैं, और एक कारखाने के बस एक कार्य में भेस है।

— डोभाल

"कई गतिशील भाषाओं में" थोड़ा भ्रामक है, क्योंकि वास्तव में जो आवश्यक है वह प्रथम श्रेणी के कार्यों के साथ एक भाषा है। "डायनेमिक" इसके लिए ऑर्थोगोनल है।

— एंड्रेस एफ।

सच है, लेकिन यह एक संपत्ति है जो अक्सर गतिशील भाषाओं में पाई जाती है। मैंने अपने उत्तर की शुरुआत में प्रथम श्रेणी के कार्य की आवश्यकता का उल्लेख किया।

— सेफालोपॉड