जो आर्मस्ट्रांग द्वारा केले बंदर जंगल समस्या को समझाने के लिए नमूना कोड [बंद]

Question

पुस्तक में कोडर्स एट वर्क जो आर्मस्ट्रांग ने कहा कि:

मुझे लगता है कि पुन: प्रयोज्य की कमी वस्तु उन्मुख भाषाओं में आती है, कार्यात्मक भाषाओं में नहीं। क्योंकि ऑब्जेक्ट ओरिएंटेड भाषाओं के साथ समस्या यह है कि उन्हें यह सब निहित वातावरण मिला है जो वे अपने साथ ले जाते हैं। आप एक केला चाहते थे लेकिन आपको जो मिला वह था एक केला और पूरे जंगल को पकड़ना

मैं यहाँ नहीं मिलता। यदि समस्या केला पाने की है, तो हम 'getBanana' फ़ंक्शन के पीछे के सभी तर्कों को कूटबद्ध कर सकते हैं। इस संदर्भ में बंदर और जंगल कैसे शामिल हैं। क्या कोई कोड स्निपेट लिख सकता है जो समस्या को समझने में आसान तरीके से समझाता है, कहते हैं, इस तथ्य को प्रदर्शित करते हैं कि Bananaऑब्जेक्ट को शुरू करने के लिए ऑब्जेक्ट Monkeyऔर Jungleवस्तुओं की आवश्यकता है , कृपया?

Comments

देखें इस $ {ब्लॉग} पर चर्चा करें

— gnat

अफ़सोस कि यह बंद हो गया - यह कुछ अच्छी चर्चा कर रहा था। एक स्टार्टर के रूप में प्रथम श्रेणी के कार्यों को देखें।

— रॉबी डी

@Euphoric चर्चा प्रकार प्रश्न वास्तव में अनुमति दी जाती है, लेकिन कौन से प्रश्न व्यक्तिपरक हो सकते हैं ... व्यक्तिपरक।

— रॉबी डी

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

— जोर्ग डब्ल्यू मित्तग

नमस्ते, मेरा प्रश्न कुछ नमूना कोड प्रदान करने के बारे में है जो मुझे (और अन्य) समस्या को बेहतर ढंग से समझने में मदद करता है। कोई भी कोड स्निपेट जो समस्या को प्रदर्शित करता है, स्वीकार्य है, केवल राय नहीं।

— खा गुयेन

Answer 1

वह एक तथ्य पर इशारा कर रहा है, वास्तविक OOP कार्यक्रमों के बहुमत चिंताओं के अलगाव का सम्मान नहीं करते हैं। उदाहरण के लिए, आपके पास कक्षाएं हो सकती हैं:

public class Banana
{
    public Monkey Owner {get;}
}

public class Monkey
{
    public Jungle Habitat {get;}
}

public class Jungle
{
}

यदि आप उपयोग करते हैं Banana, तो यह भी आवश्यक है कि यह भी निर्भर करता है Monkeyऔर Jungle।

लेकिन मैं कड़ाई से असहमत हूं कि यह ओओपी के साथ समस्या है और यह कार्यात्मक शैली किसी भी तरह से नहीं है। यह सही गर्भपात की शुरूआत के साथ OOP में आसानी से तय किया जा सकता है।

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

संभव अमूर्तता हो सकती है:

public class Banana
{
    public IBananaOwner Owner {get;}
}

public interface IBananaOwner
{
}

public class Monkey : IBananaOwner
{
    public Jungle Habitat {get;}
}

public class Jungle
{
}

इस तरह, आप जानते हैं कि Bananaमालिक है, लेकिन यह होना जरूरी नहीं है Monkey। यह कुछ भी हो सकता है। और यह सीमित करता है कि Bananaमालिक द्वारा केवल परिभाषित कार्यों को क्या किया जा सकता है IBananaOwner, जो तर्क को सरल करता है।

Comments

और इसके विपरीत, जबकि कार्यात्मक भाषाएँ बॉक्स से बाहर प्रथम श्रेणी के कार्यों का समर्थन करती हैं - यह कहना नहीं है कि फ़ंक्शन X को साइड इफेक्ट के बिना फ़ंक्शन वाई द्वारा सुरक्षित रूप से उपभोग किया जा सकता है।

— रॉबी डी

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

— रॉबी डी

@RobbieDee Monkeyऔर के Jungleलिए एक वातावरण हैं Banana। जैसे अमूर्तता का परिचय देकर IBananaOwner, पर्यावरण स्पष्ट हो जाता है। और इस माहौल को कैसे बनाया गया है, उसकी समस्या क्या है।

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

आप बहुत अच्छी तरह से सही हो सकते हैं, लेकिन मैं मदद नहीं कर सकता, लेकिन यह सोचकर कि कमरे में हाथी (किसी अन्य जानवर को जोड़ने के लिए) को पढ़ने के बाद यह है कि समस्या उन कार्यों की सही संरचना में है जो कार्यात्मक प्रोग्रामिंग, ऐतिहासिक रूप से, है अधिक के लिए खुद को उधार दिया।

— रॉबी डी

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

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

Answer 2

गोरिल्ला बंदर नहीं हैं!

उस तरफ छोड़ते हुए, आप अपने स्वयं के प्रश्न का उत्तर देते हैं " हम फ़ंक्शन 'getBanana' के पीछे सभी तर्क को अलग कर सकते हैं ।" मैं जो चाहता हूं वह एक केला है, लेकिन इसे प्राप्त करने के लिए मुझे getBananaकिसी वस्तु पर कॉल करने की आवश्यकता है , जैसे कि Gorillaकक्षा का एक उदाहरण । उस केले की वस्तु में संभवतः उस गोरिल्ला का संदर्भ होता है जो उसका है और जो गोरिल्ला वस्तु है वह उस जंगल का संदर्भ होगा जो उसका है। इसलिए मैं एक केला मांगता हूं, लेकिन इसके पीछे का पूरा जंगल ही है।

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

Comments

यह इस सवाल का जवाब नहीं देता है क्योंकि इसका कोई नमूना कोड नहीं है ...

— रॉबी डी