2009-01-06 14 views
8

यह अधिक सामान्य प्रश्न है तो भाषा-विशिष्ट, मैं इस समस्या में पाइथन ncurses मॉड्यूल के साथ खेलते समय टक्कर लगी। मुझे लोकेल पात्रों को प्रदर्शित करने की आवश्यकता थी और उन्हें पात्रों के रूप में पहचाना गया था, इसलिए मैंने शाप मॉड्यूल से कुछ कार्य/विधियों को तुरंत बंद कर दिया।बंदर-पैच या नहीं करने के लिए?

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

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

तो, बहुत ही व्यक्तिपरक, क्या हमें बंदर पैचिंग का उपयोग करना चाहिए, और यदि हां, कब और कैसे? हमें इसे कैसे दस्तावेज करना चाहिए?


संपादित करें: @guerda के लिए:

बंदर-पैचिंग निष्पादन समय पर कोड के कुछ खंड के व्यवहार बदलने के लिए, कोड में ही बदले बिना dynamicly की क्षमता है। अजगर में

एक छोटा सा उदाहरण:

import os 
def ld(name): 
    print("The directory won't be listed here, it's a feature!") 

os.listdir = ld 

# now what happens if we call os.listdir("/home/")? 
os.listdir("/home/") 
+1

क्या आप जल्द ही नए लोगों के लिए "बंदर पैचिंग" समझा सकते हैं? धन्यवाद! – guerda

+2

+1 यह व्यक्तिपरक और तर्कसंगत है, SO –

+0

पर सबसे अच्छे प्रश्नों की तरह संबंधित: http://stackoverflow.com/questions/2225698/to-monkeypatch-or-not-to-monkeypatch-that-is-the-question –

उत्तर

6

मत करो!

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

विदेशी कोड बेस पर संभव है कि एक झलक के लिए this answer देखें। linked screencast वास्तव में एक घड़ी के लायक है। अचानक एक गंदे हैक एक मूल्यवान योगदान में बदल जाता है।

यदि आप वास्तव में किसी भी कारण से पैच अपस्ट्रीम नहीं प्राप्त कर सकते हैं, कम से कम एक स्थानीय (गिट) रेपो को अपस्ट्रीम ट्रैक करने के लिए और एक अलग शाखा में अपने परिवर्तन करें।

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

4

मैं कहूंगा कि नहीं है।

प्रत्येक बंदर पैच अपवाद होना चाहिए और चिह्नित किया जाना चाहिए (उदाहरण के लिए // हैक टिप्पणी के साथ) ताकि वे वापस ट्रैक करना आसान हो।

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

-1

एक शब्द: ओएसकॉमर्स।

आप "कार्यक्षमता डाल भी आप हो सकता है" मानसिकता की वजह से उस के साथ नहीं खेला है, तो इससे पहले कि यह है कि पूरे codebase अपमानित किया है उल्लेख करने के लिए

// BOF: Fixed/added/removed bla bla bla 
... 
// EOF 

नहीं से छलनी कर रहा है। ओओ (विरासत और समग्र कक्षाएं दिमाग में आने वाली) जैसी नई प्रोग्रामिंग अवधारणाएं इन गैर-मुद्दों को बनाने के लिए डिज़ाइन की गई हैं। उन्हें इस्तेमाल करें!

0

मुझे लगता है कि प्रश्न को एक निश्चित हां-नहीं/अच्छे-बुरे उत्तर के साथ संबोधित नहीं किया जा सकता है - भाषाओं और उनके कार्यान्वयन के बीच अंतरों पर विचार किया जाना चाहिए।

पायथन में, किसी को यह विचार करने की आवश्यकता है कि कक्षा एक बंदर-पैच हो सकती है (चर्चा के लिए यह SO question देखें), जो पाइथन के थोड़ा कम-ओओ कार्यान्वयन से संबंधित है। इसलिए मैं सावधान रहूंगा और बंदर-पैचिंग से पहले विकल्पों की तलाश में कुछ प्रयासों को खर्च करने के इच्छुक हूं।

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

3

मैं David से सहमत हूं कि बंदर पैचिंग उत्पादन कोड आमतौर पर एक अच्छा विचार नहीं है।

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

+1

आप मजाक करने के लिए मतलब था :) –

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