स्कैला में मिक्सिन बनाम संरचना

Question

जावा दुनिया में (अधिक सटीक यदि आपके पास एकाधिक विरासत/मिश्रण नहीं हैं) अंगूठे का नियम काफी सरल है: "वर्ग विरासत पर ऑब्जेक्ट संरचना का पक्ष लें"।

यदि आप मिश्रित विशेष रूप से स्केल में भी विचार करते हैं तो यह जानना है कि यह कैसे बदला जाता है?
क्या मिश्रित एकाधिक विरासत, या अधिक कक्षा संरचना का एक तरीका माना जाता है?
क्या "कक्षा संरचना पर ऑब्जेक्ट संरचना का अनुकूलन" (या दूसरी तरफ) दिशानिर्देश भी है?

मैंने कुछ उदाहरण देखे हैं जब लोग ऑब्जेक्ट संरचना का उपयोग करते समय मिश्रण (या दुर्व्यवहार) मिश्रण करते हैं और मुझे हमेशा यकीन नहीं है कि कौन सा बेहतर है। ऐसा नहीं है कि आप उन लोगों के साथ काफी समान चीजें हासिल कर सकते हैं मुझे लगता है, लेकिन वहाँ कुछ मतभेद भी कुछ उदाहरण हैं:

• दृश्यता - साथ mixins सब कुछ सार्वजनिक एपीआई, जो रचना के साथ ऐसा नहीं है का हिस्सा बन जाता।
• शब्दाडंबर - ज्यादातर मामलों में mixins कम वर्बोज़ और उपयोग करने के लिए थोड़ा आसान कर रहे हैं, लेकिन यह हमेशा ऐसा नहीं है (उदाहरण के लिए यदि आप भी जटिल पदानुक्रम में स्वयं प्रकार का उपयोग)

मैं जानता हूँ कि कम जवाब है, " यह निर्भर करता है ", लेकिन शायद कुछ सामान्य स्थिति है जब यह या यह बेहतर है।

दिशा निर्देशों के कुछ उदाहरण मैं अब तक के साथ आ सकता है (यह मानते हुए मैं दो लक्षण एक है और बी और ए बी से कुछ तरीकों का उपयोग करना चाहता):

• आप एक के एपीआई का विस्तार करना चाहते हैं बी से विधियों के साथ मिश्रण, अन्यथा रचना। लेकिन यह मदद नहीं करता है कि मैं जिस वर्ग/उदाहरण को बना रहा हूं वह सार्वजनिक एपीआई का हिस्सा नहीं है।
• यदि आप कुछ पैटर्न का उपयोग करना चाहते हैं जिन्हें मिश्रण की आवश्यकता है (उदा। Stackable Trait Pattern) तो यह एक आसान निर्णय है।
• यदि आपके पास परिपत्र निर्भरता है तो आत्म प्रकार के साथ मिश्रित मदद कर सकते हैं। (मैं इस स्थिति से बचने की कोशिश करता हूं, लेकिन यह हमेशा आसान नहीं होता है)
• यदि आप कुछ गतिशील, रनटाइम निर्णय चाहते हैं तो रचना को कैसे करें, फिर संरचना को ऑब्जेक्ट करें।

कई मामलों में mixins आसान (और/या कम शब्द) होने लगते हैं, लेकिन मैं काफी यकीन है कि वे भी "भगवान वर्ग" और दूसरों को दो ARTIMA लेख में वर्णित जैसे कुछ नुकसान है, कर रहा हूँ: part 1, part 2 (बीटीडब्ल्यू मुझे ऐसा लगता है कि अधिकांश अन्य समस्याएं प्रासंगिक नहीं हैं/स्कैला के लिए इतनी गंभीर नहीं हैं)।

क्या आपके पास इस तरह के अधिक संकेत हैं?

Answer 1

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

trait Locking{ 
    // abstract locking trait, many possible definitions 
    protected def lock(body: =>A):A 
} 

class MyService{ 
    this:Locking => 
} 

//For this time, we'll use a java.util.concurrent lock 
val myService:MyService = new MyService with JDK15Locking 

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

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

Answer 2

अन्य मतभेदों में आप का उल्लेख नहीं किया है:

• विशेषता कक्षाएं किसी भी स्वतंत्र अस्तित्व नहीं है:

(Programming Scala)

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

^{[Martin2003]: रॉबर्ट सी मार्टिन, फुर्तीली सॉफ्टवेयर विकास: सिद्धांत, पैटर्न, और व्यवहार, प्रेंटिस-हॉल, 2003}

• mixins (trait) कोई निर्माता पैरामीटर शामिल हैं।

इसलिए advice, still from Programming Scala

:

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

यह अच्छा ऑब्जेक्ट-ओरिएंटेड डिज़ाइन का एक सामान्य सिद्धांत है कि एक प्रक्रिया हमेशा एक ज्ञात मान्य स्थिति में होनी चाहिए, जिस समय निर्माण प्रक्रिया समाप्त हो जाती है।

अंतिम भाग, एक वस्तु का प्रारंभिक राज्य के बारे में, अक्सर में मदद मिली है कि किसी दिए गए अवधारणा के लिए वर्ग (और वर्ग संरचना) और विशेषता (और mixins) के बीच तय।