रिच हिकी का क्या मतलब था जब उन्होंने कहा, "वह सभी विशिष्टता [इंटरफेस / क्लास / प्रकार] आपके पुन: उपयोग को मारता है!"


41

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

उत्तरों की मेरी खोज में, मैं भर में चला गया:

  • लिटर नॉलेज का सिद्धांत AKA डेमेटर ऑफ लॉ जो एयरटाइट एपीआई इंटरफेस को प्रोत्साहित करता है। विकिपीडिया कुछ नुकसानों को भी सूचीबद्ध करता है।

  • केविन हेंनी के इंपीरियल क्लोथिंग क्राइसिस का तर्क है कि इसका उपयोग करना, पुन: उपयोग करना उचित लक्ष्य नहीं है।

  • जैक डिडेरिच की " स्टॉप राइटिंग क्लासेस " बात करते हैं जो सामान्य रूप से ओवर-इंजीनियरिंग के खिलाफ तर्क देते हैं।

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

मैं एक अच्छे इंटरफ़ेस के एक अच्छे उदाहरण की तलाश कर रहा हूँ जो कुछ कोड के वैध लेकिन अनपेक्षित उपयोग को रोक रहा है। क्या वह मौजूद है? मैं यह तस्वीर नहीं कर सकता।


1
सामान को देखा / पढ़ा नहीं गया (मैंने "राइटिंग क्लासेस" को मेरी टू-वॉच लिस्ट में जोड़ा है :)), लेकिन शायद वे डायनेमिक बनाम स्टेटिक टाइपिंग एंगल से बहस कर रहे हैं? ...फिर?
एंड्रेस एफ

oO एप्लीकेशन प्रोग्रामिंग इंटरफ़ेस इंटरफेस
थॉमस ईडिंग

लिंक के लिए धन्यवाद! मुझे जैक डिडरिच की बात विशेष रूप से रोशन करने वाली नहीं लगी (यह देखें कि वह दर्शकों के वास्तविक सवालों के जवाब देने में कैसे विफल हो जाती है .. "उह, हाँ, शायद उस मामले में ..."। मुझे अच्छा लगा कि वह बिना फंक्शनल कॉम्बिनेशन के बहस कर रहा है। यहां तक ​​कि इसे देख;)), लेकिन "इंपीरियल क्लॉथ क्राइसिस" बहुत अच्छा और व्यावहारिक है।
एंड्रेस एफ

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

1
@AmyBlankenship मैंने पाया कि "इंपीरियल क्लोथ्स क्राइसिस" ऊपर जोड़ा गया है। लेखक "पुन: उपयोग" को एक झूठी मूर्ति मानता है (कुछ ऐसा है जो व्यवहार में उपयोगी साबित नहीं हुआ है, और ज्यादातर लोग इसे भी नहीं समझते हैं, हालांकि वे शब्द का उपयोग करते हैं)। वह पुस्तकालयों को "पुन: उपयोग" पर भी विचार नहीं करता है; आप एक पुस्तकालय का उपयोग करते हैं, आप इसे पुन: उपयोग नहीं करते हैं। वह पुन: उपयोग के लिए कुछ डिजाइन करने पर विचार करता है "दोधारी तलवार"; ऐसा कुछ जिसे लोग आमतौर पर एक जीत-जीत की स्थिति मानते हैं, लेकिन जो वास्तव में नहीं है: जब आप पुन: उपयोग के लिए कुछ डिज़ाइन करते हैं, तो यह हमेशा एक समझौता होता है (उदाहरण के लिए आप सादगी में खो सकते हैं)
एंड्रेस एफ

जवाबों:


32

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

यदि आपके पास जावा-भूमि में दो { "name":"John" }प्रकार की Personऔर { "name": "Rover" }प्रकार की इकाइयाँ हैं Dog, तो वे संभवत: तब तक आपस में नहीं जुड़ सकते हैं जब तक कि वे एक सामान्य इंटरफ़ेस या पूर्वज (जैसे Mammal, जिसका अर्थ अधिक कोड लिखना) को साझा नहीं करते हैं। तो यहाँ इंटरफेस / प्रकार "आपके पुन: उपयोग को मार रहे हैं": भले ही Personऔर Dogसमान दिखें, एक को दूसरे के साथ परस्पर उपयोग नहीं किया जा सकता है, जब तक कि आप समर्थन करने के लिए अतिरिक्त कोड नहीं लिखते हैं। नोट हिक्की ने जावा में बहुत सी कक्षाओं की जरूरत वाली परियोजनाओं के बारे में भी मजाक उड़ाया है ("यहां किसने लिखा है कि सिर्फ 20 कक्षाओं का उपयोग करके जावा अनुप्रयोग लिखा है?"), जो उपरोक्त में से एक परिणाम है।

"मूल्य-उन्मुख" भाषाओं में, हालांकि, आप उन संरचनाओं को प्रकार प्रदान नहीं करेंगे; वे केवल मूल्य हैं जो एक ही संरचना को साझा करने के लिए होते हैं (मेरे उदाहरण में, वे दोनों nameएक स्ट्रिंग मूल्य के साथ एक क्षेत्र है) और इसलिए आसानी से एक दूसरे को जोड़ सकते हैं, जैसे कि उन्हें एक ही संग्रह में जोड़ा जा सकता है, एक ही तरीके से पारित किया जा सकता है, आदि।

संक्षेप में, यह सब संरचनात्मक समानता बनाम स्पष्ट प्रकार / इंटरफ़ेस समानता के बारे में कुछ प्रतीत होता है । जब तक मैं वीडियो के कुछ हिस्सों को याद नहीं करता जो मैंने अभी तक नहीं देखा है :)


2
BTW, जैक डिडेरिच की बात "स्टॉप राइटिंग क्लासेस" इस विषय से असंबंधित लगती है, और यह YAGNI के बारे में अधिक है और "जब तक आपको इसकी आवश्यकता न हो कोड न लिखें, और उसके बाद केवल सरल कोड लिखें"।
एंड्रेस एफ

9
ERROR: Object doesn't have a property called "name"अक्सर value-orientedभाषाओं का परिणाम होता है, और दूसरी समस्या यह है कि आप अब उस संपत्ति को कॉल नहीं करना चाहते हैं name। सौभाग्य की बात है क्योंकि वहाँ एक संपत्ति के साथ सैकड़ों वस्तुओं की संभावना है nameलेकिन सभी Personया नहीं हैं Dog
रिएक्टगुलर

2
@MathewFoscarini हाँ, मैं जरूरी इसके साथ सहमत नहीं हूं, यह सिर्फ मेरी व्याख्या है कि मुझे क्या लगता है कि हिकी कह रहा था :) मुझे प्रकार और स्थिर टाइपिंग पसंद है; मैं सिर्फ जावा को नापसंद करने लगा हूं। और मेरा नापसंद करने के लिए असंबंधित है, interfaceलेकिन उस गड़बड़ के लिए जो विशिष्ट जावा प्रोजेक्ट है।
एंड्रेस एफ

1
जावा उन लोगों के लिए प्रोग्रामिंग भाषा है जो बहुत अधिक सोचना पसंद करते हैं। यह उन कुछ भाषाओं में से एक है जो एक डेवलपर को एक प्रोजेक्ट पर इंजीनियर के प्रयासों को आसानी से छिपाने की अनुमति देता है।
रिएक्टगुलर

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

28

वह मूल तथ्य की बात कर रहा है कि एक इंटरफेस को तत्काल नहीं किया जा सकता है। आप reuseएक इंटरफ़ेस नहीं कर सकते । आप केवल उस कोड को लागू कर सकते हैं जो इसका समर्थन करता है, और जब आप इंटरफ़ेस के लिए कोड लिखते हैं तो कोई पुन: उपयोग नहीं होता है।

जावा के पास कई एपीआई के फ्रेमवर्क प्रदान करने का इतिहास है जो एक इंटरफ़ेस को तर्क के रूप में लेते हैं, लेकिन जिस टीम ने एपीआई विकसित किया है, वह उन इंटरफेस के साथ पुन: उपयोग करने के लिए आपके लिए कई प्रकार की कक्षाएं लागू नहीं करता है।

यह एक GUI ढांचे की तरह है जिसमें IWindowएक संवाद बॉक्स के लिए एक इंटरफ़ेस है, और फिर आप IButtonनियंत्रण के लिए इंटरफेस जोड़ सकते हैं । सिवाय, उन्होंने कभी भी आपको एक अच्छा Buttonवर्ग नहीं दिया जो लागू करता है IButton। तो आप अपना खुद का बनाना छोड़ रहे हैं।

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

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


4
इस उत्तर के लिए धन्यवाद। अब मुझे लगता है कि मैं प्रश्न और उत्तर को समझता हूं :)
मेटाफ़ाइट

2
+1 मैं वास्तव में आपके उत्तर की सराहना करता हूं और यह इस प्रश्न की रोचक जानकारी की एक आकर्षक परत जोड़ता है। लेकिन मुझे लगता है कि एंड्रियास एफ का जवाब श्री हिक्की के दिल के करीब होने की संभावना है, इसलिए मैंने उनकी जगह स्वीकार कर लिया।
ग्लेनपेटर्सन

@GlenPeterson कोई समस्या नहीं है, मुझे लगता है कि वह निशान पर भी हो सकता है।
रिएक्टगुलर

1
वैसे यह और स्वीकृत उत्तर दो अलग-अलग हैं, लेकिन समान रूप से दिलचस्प, व्याख्याएं। मैं उत्सुक हूँ जो इस बारे में बात करते समय एक मिस्टर हिकी को ध्यान में था ..
डेविड कॉडन

आप एक इंटरफ़ेस का पुन: उपयोग नहीं कर सकते हैं, लेकिन आप पुरानी कक्षाओं को बदले बिना इसे बढ़ा सकते हैं (और मूल्यवान संस्करण संख्या दे सकते हैं)। नई कक्षाओं के लिए नई नौकरी जोड़ने के लिए आप कई इंटरफेस से वारिस हो सकते हैं, या पुराने पुनर्नवीनीकरण कक्षाओं में नई विरासत जोड़ सकते हैं। आप उस वर्ग का विस्तार भी कर सकते हैं जो नई नौकरी के लिए इस इंटरफ़ेस को लागू करता है।
cl-r

14

मुझे लगता है कि उनकी प्रस्तुति पर स्लाइड 13 ( मानों का मूल्य ) इसे समझने में मदद करता है:

http://i.stack.imgur.com/LVMne.png


मान

  • तरीकों की जरूरत नहीं है
    • मैं आपको बिना कोड के मान भेज सकता हूं
      और आप ठीक हैं

मेरी समझ है, हिक्की सुझाव देते हैं कि अगर मुझे जरूरत है, तो कहो, मेरे द्वारा भेजे गए मूल्य को दोगुना कर दो, मैं बस कोड की तरह लिख रहा हूं

    MyValue = Double(YourValue)

आप देखते हैं, ऊपर कोड समान है, इससे कोई फर्क नहीं पड़ता कि आपने किस प्रकार का मूल्य भेजा है - एक सही पुन: उपयोग की तरह

अब, यह भाषा में वस्तुओं और इंटरफेस की तरह कैसे दिखेगा?

    Doublable MyValue = YourValue.Double()

अरे रुको! क्या होगा अगर YourValueलागू नहीं होता है Doublable? ऐसा नहीं है कि इसे दोगुना नहीं किया जा सकता है, यह पूरी तरह से हो सकता है लेकिन ... अगर कोई विधि नहीं है तो क्या होगा Double? (क्या होगा अगर वहाँ एक विधि कहा जाता है TwiceAsMuch?)

उह ओह हम एक समस्या है। YourValue.Doubleकाम नहीं करेगा, इसे अब पुन: उपयोग नहीं किया जा सकता है। उपरोक्त स्लाइड के मेरे पढ़ने के अनुसार, इस बारे में हिक्की का क्या मतलब है जब उन्होंने कहा, "वे सभी इंटरफेस आपके पुन: उपयोग को मारते हैं!"

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

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


साइड नोट: कोड-कम मानों के आसपास से गुजरने की धारणा किसी तरह मुझे OOP में फ्लाईवेट पैटर्न की याद दिलाती है ।

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

फ्लाईवेट उपयोग मैंने आमतौर पर वस्तुओं से कोड (विधियों, इंटरफेस) को अलग करने और सामान को चारों ओर से पास करने के समान दृष्टिकोण का पालन किया है, साथ ही, कोड-कम मान , यह अपेक्षा करते हुए कि कोड प्राप्त करना इन पर काम करने के लिए आवश्यक है।

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


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

1
एक दिलचस्प ले। अच्छा उत्तर!
maple_shaft

2
फ्लाईवेट पैटर्न वह नहीं है जिसके बारे में रिच बात कर रहे हैं। जैसा कि लेख के दूसरे वाक्य में कहा गया है, फ्लाईवेट पैटर्न का उद्देश्य स्मृति का संरक्षण करना है। रिच का दृष्टिकोण ऐसा नहीं चाहता है।

5
MyValue = Double(YourValue)समझ नहीं आता है कि YourValue एक स्ट्रिंग, एक पता, एक उपयोगकर्ता, एक फ़ंक्शन या एक डेटाबेस है। अन्यथा, आपके लापता-विधि तर्क एक मजबूत है। OTOH, एक्सेसर मेथड्स आपको विभिन्न बाधाओं को लागू करने देते हैं ताकि आपके वैल्यूज़ मान्य हों, और नए वैल्यूज़ का उत्पादन करने के लिए केवल समझदार संचालन का उपयोग किया जाता है। यदि आप बाद में अपने उपयोगकर्ता और कंपनी से पते को अलग करने का निर्णय लेते हैं, तो एक्सेसर विधियों का अर्थ है कि आप अपने कोड के सभी क्लाइंट को नहीं तोड़ते हैं। इसलिए वे लंबे समय में पुन: उपयोग में मदद कर सकते हैं, भले ही वे कभी-कभी इसे अल्पकालिक में बाधा डालते हों।
ग्लेनपेटर्सन

4
(दूसरी तरफ, मैं इस बात से सहमत हूं कि जावा-भूमि में, कक्षाओं, इंटरफेस और फ्रेमवर्क का विस्फोट एक बुरा सपना है। जावा में सबसे सरल "एंटरप्रिसिए" समाधान कोड की गड़बड़ी है। इसलिए मैं इसके लिए एक मूल्यवान सबक लेता हूं। प्रश्न और उत्तर, आवश्यक रूप से गतिशील टाइपिंग सामग्री से सहमत हुए बिना)
एंड्रेस एफ

2

एक (यानी मेरी) आदर्श विश्व कक्षाएं और इंटरफेस हमेशा व्यवहार का वर्णन करेंगे, लेकिन तथ्य यह है कि सभी अक्सर वे वास्तव में डेटा का वर्णन करते हैं। कल ही मैंने किसी का वीडियो देखा BankAccountथा जो एक तथाकथित वर्ग का निर्माण करता था, जो कि महिमामंडित करने से ज्यादा कुछ नहीं था int(वास्तव में यह बहुत कम उपयोगी था int, इस प्रकार पुन: उपयोग किए जाने वाले 'हत्या' के लिए मुझे इसे बस छोड़ देना पड़ा था int), सभी 'अच्छा' डिजाइन के नाम पर। कोड, पसीने और आँसू की मात्रा डेटा के लगातार प्रबलित निरूपण पर बर्बाद हो रही है; यदि आप डेटा का उपयोग सार्थक तरीके से नहीं कर रहे हैं, तो कृपया इसे करने दें।

अब, यह वह चरण है जहां रिच हिकी बच्चे को स्नान के पानी के साथ बाहर फेंकने के लिए सामग्री है और कहती है कि हम सभी को मूल्यों की भूमि में जीना चाहिए (पड़ोसी की संज्ञाओं का साम्राज्य)। मुझे लगता है, हाथ पर, कि OOP कर सकते हैं और फिर से उपयोग को बढ़ावा देने (और महत्वपूर्ण रूप से खोजशीलता, जो मुझे कार्यात्मक प्रोग्रामिंग में कमी है) को विवेकपूर्ण तरीके से नियोजित करते हैं। यदि आप एक ओओपी सिद्धांत की तलाश कर रहे हैं जो इस तनाव को सबसे अच्छी तरह से पकड़ता है तो मुझे लगता है कि यह http://c2.com/cgi/wiki?TellDontAsk हो सकता है (जो निश्चित रूप से डेमेटर के करीबी चचेरे भाई हैं)


खोज से क्या मतलब है? यह करने के लिए इसी तरह की है यह ?

1
हां, मुझे लगता है कि बहुत सारे मुख्य बिंदुओं को छूता है। यह एक सूक्ष्म बिंदु है, लेकिन खोजनीयता एक संतुलनकारी कार्य है, चीजों को बहुत पारदर्शी बनाना भी अवांछनीय है क्योंकि आपको शोर अनुपात के लिए एक बुरा संकेत मिलेगा।
कर्टनडॉग
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.