क्या यह एक कोड गंध है यदि एक निजी विधि एक सार्वजनिक कॉल करती है?


25

क्या यह समान वस्तु उदाहरण की निजी विधि में सार्वजनिक विधि को कॉल करने के लिए एक कोड गंध है?


AAMOI क्या आपके पास एक विशिष्ट उदाहरण है?
ओसोडो

नहीं, वर्तमान में नहीं। बस एक मामला याद आया, जिस पर मैंने अपने साथियों के साथ चर्चा की थी। यहां भी कुछ राय लेना चाहता था।
ईमंतस

5
आम तौर पर मैं संदर्भ द्वारा एक संक्षिप्त जानकारी प्राप्त कर सकता हूं, लेकिन AAMOI मुझे निश्चित रूप से देखना था
कार्सन मायर्स

@ करसन - क्या आपको कुछ मिला?
ईमंतस

4
ब्याज की बात के रूप में
कार्सन मायर्स

जवाबों:


32

कोई बुरी गंध नहीं। इसकी आवश्यकता हो सकती है, आप इसे गलत होने पर संदेह क्यों करते हैं? परमाणु स्तर पर एक विधि एक स्वतंत्र इकाई है जो एक कार्य करती है। जब तक यह एक कार्य करता है, जिसके पास इसकी पहुंच है, वह इसे कार्य करने के लिए कह सकता है।


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

19

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

इसे एक संकेत के रूप में लें कि कक्षा को विभिन्न वस्तुओं में विभाजित करने की आवश्यकता हो सकती है, निजी तरीकों को वास्तव में एक ही वस्तु के सार्वजनिक तरीकों को कॉल करने की आवश्यकता नहीं होनी चाहिए, निश्चित रूप से एक साफ ओओ डिजाइन में।

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

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


5
+1 'अलार्म का कारण नहीं' के लिए। बहुत बार हम एक 'गंध' देखते हैं और तुरंत बिना सोचे-समझे रिफ्लेक्टर मोड में चले जाते हैं।
माइकल के

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

18

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


क्यूं कर? यदि एक अधिलेखित सार्वजनिक विधि अप्रिय आश्चर्य की ओर ले जाती है, तो क्या यह वास्तव में मायने रखता है कि किसने विधि को बुलाया?
user281377

4
हाँ यह करता है। यदि एक सार्वजनिक विधि को ओवरराइड करने से दूसरी सार्वजनिक विधि टूट जाती है तो मैं उस दूसरी विधि को भी ओवरराइड कर सकता हूं। यदि यह एक निजी पद्धति को तोड़ता है, तो मैं कर सकता हूं ....?
किम

5
एक सार्वजनिक पद्धति को ओवरराइड करने से उत्पन्न एक अप्रिय आश्चर्य अपने आप में एक कोड गंध है। एक कोड बदबू, वास्तव में।
लैरी कोलमैन

किम: यदि विधि सार्वजनिक है, तो आपको यह मान लेना चाहिए कि अन्य वर्ग उस विधि को भी कहते हैं ...
user281377

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

5

मुझे नहीं लगता कि हम नरसंहार कर सकते हैं।

यह सब बहुत हद तक संदर्भ पर निर्भर करता है।

एक वर्ग में सार्वजनिक उपयोगिता पद्धति, जो अन्य वर्गों द्वारा उपयोग की जाती है, और उसी कक्षा में कुछ निजी पद्धति भी हो सकती है।


5

उस मामले में और क्या किया जाना चाहिए? निजी विधि को सार्वजनिक करें या सार्वजनिक विधि को निजी बनाएं? कॉपी-कोड को सार्वजनिक विधि से निजी एक में पेस्ट करें?


या सार्वजनिक विधि को एक (नई) निजी पद्धति में सौंप दिया जाता है जिसे अन्य निजी विधि द्वारा लागू किया जाता है। लेकिन, परेशान क्यों?
लॉरेंस डॉल

4

नहीं , यहां कोई बदबू नहीं है।

यदि हम सूची के साथ एक कतार के इंटरफ़ेस को लागू करते हैं, तो क्या आसानी से कतार के कार्यान्वयन को प्राप्त करने के लिए उचित सूची कार्यों को कॉल करना एक बुरी गंध है?

अगर आपके पास कुछ है और आप इसे किसी और चीज़ में बदलना चाहते हैं (जैसे रैपर) तो इसकी ख़ुशबू नहीं है, इसका कोड डिज़ाइन पैटर्न के साथ री-यूज़ेबिलिटी फंक्शन लेवल में काम करता है (क्या यह फंक्शन एक ऑब्जेक्ट है?)


2

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

  1. सार्वजनिक पद्धति में ऐसे परीक्षण हो सकते हैं जो आंतरिक रूप से आपके निष्पादन कोड के बाद आवश्यक नहीं हैं। यह एक UserObj प्राप्त कर सकता है और उदाहरण के लिए उपयोगकर्ता अनुमतियों का परीक्षण करना चाहता है।

  2. सार्वजनिक कॉल के बाद, आपको ऑब्जेक्ट को लॉक करने की आवश्यकता हो सकती है, यदि आप थ्रेडिंग का उपयोग कर रहे हैं, तो आंतरिक रूप से, आप किसी सार्वजनिक विधि से वापस कॉल नहीं करना चाहेंगे।

  3. मेरी राय में परिपत्र त्रुटियों और अनंत छोरों और यादगार अपवादों से बाहर आने की अधिक संभावना है।

  4. सादा और सरल, बुरा डिजाइन और "आलसी"। सार्वजनिक विधियाँ बाहरी दुनिया तक पहुँच प्रदान करती हैं। जब आप पहले से ही अंदर हों तो बाहर घूमने का कोई कारण नहीं है।


1
क्या होगा यदि मौजूदा सार्वजनिक विधि को कई अन्य वर्गों द्वारा बुलाया जाए? इसे निजी बनाने से वह टूट जाएगा। याद रखें कि सार्वजनिक तरीकों को अन्य वर्गों द्वारा अन्य कारणों से बुलाया जाता है, न कि केवल इस वर्ग के लिए। थोड़े क्यों सार्वजनिक तरीके मौजूद हैं।
माइकल डुरंट

मैंने कहा था कि 'सार्वजनिक पद्धति की सामग्री को निजी पद्धति में लिया और रखा जाना चाहिए ...' सार्वजनिक पद्धति बनी रहेगी, लेकिन नई निजी पद्धति से कॉल करें। किसी भी अन्य निजी तरीकों के रूप में जिन्हें समान कार्यक्षमता को फिर से उपयोग करने की आवश्यकता है।
मार्क ग्राहम

तो आप बिना किसी अन्य कारण के - के लिए एक और तरीका जोड़ रहे हैं, क्योंकि आपने इसे "कोड गंध" घोषित किया है। व्यर्थ तरीके एक बदतर कोड गंध है।
gnasher729

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

मुझे अपने जीवन में कभी भी निजी तरीके से सार्वजनिक पद्धति को कॉल करने की आवश्यकता नहीं है। यह सिर्फ मुझे लगता है और बहुत गलत लगता है। मैं वास्तव में आश्चर्यचकित हूं कि ज्यादातर लोग सोचते हैं कि यह ठीक है।
ट्रैप

2

इसके विपरीत कल्पना कीजिए। आप एक निजी विधि में हैं और आपको सार्वजनिक विधि में कार्यक्षमता की आवश्यकता है यदि आप उस सार्वजनिक विधि को निजी से कॉल नहीं कर सकते हैं । तुम क्या करोगे?

  • एक डुप्लिकेट निजी विधि बनाएँ? नहीं
  • अवसर के लिए एक विशेष सार्वजनिक विधि बनाएं? नहीं
  • एक विशेष निजी विधि को कॉल करें जो सार्वजनिक विधियों को कॉल कर सकता है? नहीं
  • किसी प्रकार का सुपर जो ऐसा कर सकता है? नहीं

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


1

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

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

तो अपने प्रश्न का उत्तर देने के लिए, यह निश्चित रूप से बुरा कोड नहीं है यदि आप इसे सही तरीके से उपयोग करते हैं।


1

प्रश्न आपको अपने आप से पूछने की आवश्यकता है कि आपकी कक्षा को आपकी कक्षा के ग्राहकों की समान आवश्यकता क्यों है? आमतौर पर एक वर्ग को अपने ग्राहकों से बहुत अलग जरूरत होती है। तो हाँ, यह एक संकेत है कि आपके पास या तो है

(ए) सार्वजनिक रूप से कुछ उजागर किया जो निजी होना चाहिए; या

(बी) वर्ग का व्यवहार पर्याप्त संकीर्ण नहीं है (एकल जिम्मेदारी सिद्धांत पर विचार करें)।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.