फ़ील्ड बनाम विधि तर्क [बंद]


9

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

ऐसा करने का अर्थ है कि बहुत सारी विधियाँ जिनमें कोई तर्क नहीं हो सकता था, एक, दो या तीन के साथ समाप्त हो सकती हैं।

मैं आपकी राय सुनना चाहता हूं कि आप इस ट्रेडऑफ के बारे में क्या सोचते हैं, और आप यह कैसे तय करते हैं कि किस स्थिति में क्या करना है?

चूंकि कोड का वर्णन करते समय अंग्रेजी की तुलना में कोड को समझना अक्सर आसान होता है, इसलिए मैंने एक छोटी सी तस्वीर बनाई, जिसमें दोनों प्रकार हैं: https://gist.github.com/JeroenDeDauw/6525656


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

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

जवाबों:


2

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

यदि यह एक अधिक सामान्य वर्ग (जैसे TableTools) का हिस्सा है , तो मैं सहायक विधियों को स्थानांतरित करूँगा, जिन्हें राज्य को एक छिपे हुए आंतरिक वर्ग में बदलने की आवश्यकता है।

छद्म कोड उदाहरण:

class TableTools {
    ...
    public void updateTable(currentTable, newTable) {
        TableUpdater u = new TableUpdater(schemaModifier, currentTable, newTable);
        u.removeRemovedFields();
        u.addAddedFields();
     }

     private class TableUpdater { ... }
}

इस तरह, आप केवल एक सार्वजनिक विधि द्वारा उपयोग किए जाने वाले फ़ील्ड से बचते हैं। इसके अलावा, कोड इस अर्थ में थ्रेड-सेफ है कि अद्यतन करने के लिए प्रत्येक कॉल TableUpdater की अपनी प्रति का उपयोग करता है और इस प्रकार, TableUpdater के उदाहरण चर।


7

खेतों का उपयोग उन तरीकों का उपयोग करने के लिए मल्टीथ्रेडिंग उपलब्ध होने की क्षमता का सह-ऑप्स करता है।

पुन: प्रयोज्य और बनाए रखने के दृष्टिकोण से ग्लोबल्स का उपयोग करने की तुलना में उस तरह के क्षेत्रों का उपयोग करना थोड़ा बेहतर है, यहां महत्वपूर्ण बिंदु यह है कि जटिल सेटअपों को सावधान और अप-टू-डेट प्रलेखन की आवश्यकता होती है कि कौन से तरीकों का उपयोग करें और / या क्लोबार कौन से फ़ील्ड का उपयोग करें; तर्क का उपयोग करते समय आपको कुछ करने की आवश्यकता नहीं है।


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

7

आम आदमी के शब्दों में:

  • तरीकों में यथासंभव कम तर्क होने चाहिए (मार्टिन क्लीन कोड)
  • वस्तुओं की सुविधाओं में से एक है कि वे एक राज्य कर सकते हैं (और चाहिए)
  • गैर-स्टेटिक विधियाँ जो ऑब्जेक्ट की स्थिति पर काम नहीं करती हैं, अर्थात पैरामीटर के रूप में सब कुछ प्राप्त करती हैं, कोई सामंजस्य नहीं है
  • गैर-सामंजस्यपूर्ण तरीकों को स्थिर और उपयोगिता वर्ग में वर्गीकृत किया जा सकता है

फिर, मेरी विनम्र राय में गैर-सामंजस्यपूर्ण तरीके एक उपयोगिता वर्ग के हैं और एक डोमेन नाम वाले वर्ग के लिए नहीं।


1

वर्तमान मामले में फ़ील्ड का उपयोग न करें! एक ही समय में वस्तु का उपयोग करने वाले दो "धागे" गंभीरता से एक दूसरे को भ्रमित करेंगे। उन्हें वास्तविक नहीं होना चाहिए, अलग-अलग धागे (इसलिए उद्धरण)। यदि आप एक तालिका के लिए ऑब्जेक्ट सेट करते हैं, तो एक विधि को कॉल करें जो इसे दूसरी तालिका के लिए उपयोग करती है, फिर मूल सेट अप का उपयोग करने का प्रयास करें, आपको एक समस्या है। फिलहाल मापदंडों के साथ रहें।

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


0

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

हमें इस मामले में प्रभावकारिता के द्वारा निर्देशित किया जाना चाहिए (अंतर वैसे भी महत्वहीन है), या (ईश्वर बचाओ!) टाइपिंग की सहजता, लेकिन कोड की समझ और स्वाभाविकता से।


0

मेरी राय में यदि आप ऐसा कोड लिख रहे हैं जो कुछ करने के लिए कुछ करता है तो उसे ऐसे पैरामीटर लेने चाहिए जो यह निर्धारित करें कि यह उन्हें क्या करना चाहिए और इसके नाम को जहां तक ​​संभव हो इसे परिभाषित करना चाहिए।

यदि आप ऐसा कोड लिख रहे हैं जो किसी चीज़ पर किए जाने वाले एक्शन को पैकेज करता है तो आपको उन चीजों को लपेटना चाहिए जो किसी ऑब्जेक्ट पर होनी चाहिए और उन्हें अपनी चीज़ में पास करें जो कुछ करता है

यह क्रिया तब कॉल की एक तरह की मेटा-विवरण बन जाती है, पहले तरीकों के बारे में जिसे आप बाद में शायद कतार में लगाकर प्रदर्शन कर सकते हैं या किसी कारण से इसे बिल्कुल भी न करने का निर्णय ले सकते हैं।

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

आप पूर्ववत और क्रिया कर सकते हैं, लेकिन कार्य नहीं ।

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