क्या सभी वर्गों को स्कैला में मामलों के रूप में परिभाषित करना सही है, केवल उनके सभी तर्कों को गुणों को स्वचालित रूप से बनाने के लिए?

Question

मैं स्कैला शुरू कर रहा हूं। क्या मैं समझ में सुधार कर रहा हूं कि मुझे कक्षा के रूप में कक्षा को परिभाषित करना चाहिए यदि मैं गुणों के रूप में उजागर होने के तर्कों को दूंगा? क्या यह किसी भी दुष्प्रभाव का परिचय नहीं देता है?

Answer 1

केस कक्षाओं के लिए जेनरेट किए गए बॉयलरप्लेट कोड में बाइटकोड में एक छोटी लेकिन गैर-शून्य लागत होती है। copy विधि के अतिरिक्त, hashCode, equals और toString के साथ-साथ साथी ऑब्जेक्ट फ़ैक्टरी विधि भी है।

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

यदि आप किसी भी विरासत ग्राफ के पत्ते पर अपने केस कक्षाएं रखते हैं, तो आप ठीक होंगे।

Answer 2

आप परिभाषित कोई पैरामीटर के लिए प्रॉपर्टीज़ मिल जाएगा और वे Vals (यानी, फाइनल)

case class User(name: String, group: String) 
val user = User("jsmith", "admins") 

// access both properties 
println("name: %s group: %s".format(user.name, user.group)) 

आप नियमित रूप से (यानी, गैर मामले वर्ग) के साथ इस व्यवहार प्राप्त कर सकते हैं और साथ ही हो जाएगा:

// creates two final public properties as well 
class User(val name: String, val group: String) 

// creates read/write public properties 
class User(var name: String, var group: String) 
val user = new User("jsmith", "admins") 
user.group = "guests" 

केस क्लास भी कई अन्य चीजें लाता है जैसे कि समानता, हैशकोड और टोस्टिंग और एक फैक्ट्री विधि के साथ एक साथी ऑब्जेक्ट के उपयोगी कार्यान्वयन जो अन्य चीजों के साथ नए उपयोग की आवश्यकता को समाप्त करता है।

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

Answer 3

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

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

Answer 4

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

कुछ गुणों को "वैल" के रूप में घोषित करने वाले कुछ कीस्ट्रोक को बचाने के लिए केस क्लास को घोषित करना गलत अर्थव्यवस्था है, और किसी दिन आपको काट देगा।