स्मॉलटॉक और आईओसी

Question

मुझे नेट और जावा के लिए बहुत सारे आईओसी फ्रेमवर्क दिखाई देते हैं। क्या किसी को पता है कि स्मॉलटाक के लिए कोई समकक्ष ढांचा क्यों नहीं है। यह किसी और चीज की तुलना में एक दर्शन प्रश्न है। मैं सोच रहा हूं कि क्या चीजों को करने के छोटे-छोटे तरीके में कुछ ऐसा है जो आईओसी ढांचे की आवश्यकता को रोकता है।

Answer 1

MVC का आविष्कार स्मॉलटाक पर किया गया था और तर्कसंगत रूप से मूल Inversion of Control ढांचा है। जबकि इसके जावा समकक्षों की तुलना में थोड़ा अधिक हल्का वजन होता है, इसमें डेटा धारण करने वाले मॉडल की बुनियादी अवधारणाएं होती हैं, एक नियंत्रक से प्रचारित घटनाओं के जवाब में डेटा प्रस्तुत करने वाला एक दृश्य।

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

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

Answer 2

कार्य छोटे-छोटे वर्ग में प्रथम श्रेणी के नागरिक हैं, इसलिए आईओसी को ढांचे के बिना आसान बनाना आसान है।

Answer 3

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

Answer 4

इसके लिए कुछ संभावित कारण हैं। एक यह है कि हमने "आईओसी" क्वालीफायर का उपयोग करने के लिए परेशान नहीं किया है, जो अनिवार्य रूप से अनावश्यक है - क्योंकि कुछ ढांचे को कॉल करने से नियंत्रण प्रवाह में उलटा लगता है।

दूसरा यह है कि स्मॉलटाक भाषा बंद होने के रूप में "आईओसी" प्रवाह के लिए प्रत्यक्ष समर्थन प्रदान करती है। बंद होने के साथ प्रोग्रामिंग का एक परिणाम यह है कि ढांचे में पाए गए नियंत्रण का प्रवाह प्रवाह की "सामान्य" भावना से "उलटा" होने की भावना को विकसित करने के लिए इतना अलग नहीं लगता है; बल्कि, बंद होने के साथ, नियंत्रण का प्रवाह हर समय, और हर जगह इन दो दृष्टिकोणों के बीच आगे बढ़ रहा है। यहां तक ​​कि एकल बयान के भीतर भी।

एक तीसरा कारण, शायद, यह है कि, बिना किसी बंद होने के भी, "नियंत्रण में उलटा" का वर्णन ढांचे के साथ विशिष्ट रूप से जुड़ा हुआ नहीं है - उसी प्रवाह में अधिकांश प्रवाह कोड I/O शामिल होते हैं।

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

अंत में, कोई भी "सरल" के रूप में नियंत्रण प्रवाह की आरईपीएल शैली का वर्णन करने के बारे में सोच सकता है, लेकिन "सामान्य" प्रवाह की "उलटा" भावना, सामान्य रूप से यह लगभग हर जगह उपयोग किया जाता है।

संक्षेप में, छोटे प्रकार के ढांचे के लिए ढांचे के समान प्रकार मौजूद हैं। हम उन्हें थोड़ा अलग वर्णन करते हैं। अंतर, कम से कम भाग में, उपस्थिति और उपयोग के कारण स्मॉलटॉक में बंद होने के कारण, जो कई अन्य वातावरण अभी तक प्रदान नहीं करते हैं - - विशेष रूप से सी ++, सी #, और जावा।

Answer 5

जावा में एक निर्भरता बन जाता है

की तरह कुछ

MyClass32 अस्थायी लिखने = this.theThing();

अब आपका कोड कक्षा MyClass32 पर डिप्न्ड करता है। आपका कोड इसके बिना काम नहीं करेगा। उस कक्षा में कोई भी परिवर्तन आपके कोड को असंभव बना सकता है, आपके कोड में बहुत से अतिरिक्त परिवर्तन की आवश्यकता है, जो कक्षा में आगे कोड-परिवर्तन की आवश्यकता हो सकती है जो आपके पर निर्भर करता है। बहुत सारे काम

स्मॉलटॉक में आप temp लिखेंगे: = self theThing;

आपका कोड काम करेगा #getTheThing द्वारा लौटाया गया कोई फर्क नहीं पड़ता। आपका कोड क्लास MyClass32 पर पर निर्भर नहीं है। आपकी केवल निर्भरता यह है कि 'temp' को जो भी संदेश भेजते हैं उसे समझना चाहिए।

तो एक अर्थ में निर्भरता इंजेक्शन फ्रेमवर्क एक स्थिर रूप से टाइप की गई भाषा जैसे जावा काम की तरह एक dy7namically टाइप किया गया है।

यानी, एक डिज़ाइन पैटर्न मैं अक्सर स्मालटाक में पालन किया है: MyClass कि कुछ वर्ग रिटर्न की तरह एक वर्ग विधि बनाएँ। इसमें NAME 'MyCLass' की आवश्यकता नहीं है। यह रात में एक अलग वर्ग लौटने, कई कक्षाओं में से एक हो सकता है। यह पैटर्न स्मॉलटॉक एमवीसी, में मौजूद है जहां व्यू-क्लास में विधि #defaultControllerClass, है जो आमतौर पर सबक्लास द्वारा पुन: परिभाषित किया जाता है।