2013-01-10 21 views
5

मैं सिर्फ स्कैला में प्रोग्राम करना सीख रहा हूं। मेरे पास कार्यात्मक प्रोग्रामिंग में कुछ अनुभव है, क्योंकि मेरे पास ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग है। मेरा प्रश्न सरल, अभी तक मुश्किल है:स्कैला अपरिवर्तनीय बनाम परिवर्तनीय बनाम। किसी को क्या जाना चाहिए?

स्कैला में कौन सी संरचनाओं का उपयोग किया जाना चाहिए? क्या हमें केवल अपरिवर्तनीय रहना चाहिए, उदाहरण के लिए। इसके माध्यम से पुनरावृत्ति करके संशोधित सूचियां और एक साथ एक नया चिपकाएं, या mutables के लिए जाओ? उस पर आपकी राय क्या है, प्रदर्शन पहलुओं, स्मृति संबंधी पहलुओं, ...

मुझे एक कार्यात्मक शैली में प्रोग्राम करने की संभावना है, लेकिन यह अक्सर ऐसी चीजों को करने के प्रयासों की एक पागल राशि तक फैलता है जो mutables का उपयोग करके आसानी से किया। क्या यह स्थिति निर्भर है, क्या उपयोग करें?

+2

यह प्रश्न बहुत सामान्य है। मैं उन समस्याओं की पहचान करने की अत्यधिक अनुशंसा करता हूं जो आपको लगता है कि काम करने के लिए "पागल" प्रयास की आवश्यकता है, और उनके बारे में प्रश्न पूछना। आप नई कार्यात्मक तकनीकों को सीख सकते हैं जो प्रयास को उचित लगते हैं - या परिवर्तनीय डेटा का उपयोग करने से भी आसान! –

+9

ऐसे अन्य प्रश्न हैं जो इसे संबोधित करते हैं, और यह प्रश्न एक अच्छा जवाब स्वीकार करने के लिए बहुत अस्पष्ट या व्यापक है, लेकिन संक्षेप में: सबसे अच्छा काम करता है _overall_। अंगूठे के नियम के रूप में, यदि कोई गंभीर कमी नहीं होती है तो एक अपरिवर्तनीय समाधान का उपयोग करें; उसके बाद, एक उत्परिवर्तनीय व्यक्ति का पक्ष लें जहां परस्पर राज्य स्थानीय संदर्भ से बच नहीं जाता है (यानी आप जिस विधि का उपयोग कर रहे हैं), उसके बाद एक जहां उत्परिवर्तनीय राज्य कक्षा में कम से कम छिपा हुआ है (इसलिए इसके बारे में चिंता करने की आवश्यकता नहीं है _except_ एकाधिक थ्रेड का उपयोग करते समय - और थ्रेड सुरक्षा की कमी दस्तावेज)। अपरिवर्तनीयता का उपयोग करें क्योंकि यह आपकी मदद करता है, जब यह दर्द होता है! –

+0

आसान/पागल अनुपात पर: एक धागे से निपटने के दौरान उत्परिवर्तन अक्सर प्रोग्राम और डीबग करना आसान होता है और एकाधिक धागे का उपयोग करते समय प्रोग्राम और डीबग करना बेहद मुश्किल हो जाता है। –

उत्तर

3

(मैंने सोचा था कि यह एक नकली होना चाहिए, लेकिन आसानी से एक पहले इसी तरह की एक नहीं मिल सकता है, तो मैं जवाब देने के लिए ... उद्यम)

इस प्रश्न का कोई सामान्य जवाब नहीं है। स्कैला के रचनाकारों द्वारा सुझाए गए अंगूठे का नियम अपरिवर्तनीय vals और संरचनाओं से शुरू करना है और जब तक यह समझ में आता है तब तक उनके साथ चिपकना है। आप लगभग हमेशा अपनी समस्या के लिए एक व्यावहारिक समाधान बना सकते हैं। लेकिन यदि नहीं, निश्चित रूप से व्यावहारिक और उत्परिवर्तन का उपयोग करें।

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

+0

मैंने ऐसा भी सोचा (कि इसके बारे में कोई विषय होना चाहिए) और चारों ओर देखा लेकिन कुछ भी नहीं मिला मैंने सोचा कि मैं इसके बारे में पूछूंगा। आपके उत्तर के लिए टाई, महोदय! – smoes

3

मैं आमतौर पर निम्नलिखित नियमों का पालन:

  • कभी स्थिर परिवर्तनशील वार्स

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

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

  • यह समारोह परिणामों के लिए

  • उपयोग अपरिवर्तनीय संग्रह तरीकों में परिवर्तनशील स्थानीय वार्स उपयोग करने के लिए ठीक है। उपयोग किए गए संदर्भ में सर्वोत्तम प्रदर्शन करने के आधार पर इनका सख्ती से या आलसी मूल्यांकन किया जा सकता है। सावधान रहें यदि आप आलसी मूल्यांकन वाले परिणाम का उपयोग करते हैं जो कि एक परिवर्तनीय संग्रह पर निर्भर करता है।

3

उत्परिवर्तनीय राज्य के लिए अपरिवर्तनीय पसंद करते हैं। केवल परिवर्तनीय स्थिति का उपयोग करें जहां यह बिल्कुल जरूरी है।कुछ उल्लेखनीय कारणों में शामिल हैं:

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

  • आई/ओ। I/O, या बाहरी दुनिया के साथ बातचीत करना स्वाभाविक रूप से राज्य निर्भर है, और इस प्रकार एक उत्परिवर्तनीय तरीके से निपटाया जाना चाहिए।

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

कई में मामलों में, यह स्वत: समांतर निष्पादन की भी अनुमति देता है, उदाहरण के लिए, स्कैला में संग्रह कक्षाओं में par फ़ंक्शन है, जो समानांतर संग्रह को map या reduce जैसे कार्यों में स्वचालित रूप से कॉल चलाता है।