वंशानुक्रम और रचना के विपरीत लक्षण का उपयोग कब करें?

Question

जब ओओपी की बात आती है, तो पुन: प्रयोज्यता को लागू करने के लिए एएफएआईके तीन सामान्य तरीके हैं

1. वंशानुक्रम: आमतौर पर प्रतिनिधित्व करने के लिए एक रिश्ता है (एक बतख है-एक पक्षी)
2. रचना: आमतौर पर प्रतिनिधित्व करने के लिए एक संबंध है (एक कार में एक इंजन है)
3. लक्षण (जैसे PHP में विशेषता कीवर्ड): ... वास्तव में इस बारे में निश्चित नहीं है

हालांकि यह मुझे दिखता है कि लक्षण एक-और-एक रिश्ते दोनों को लागू कर सकते हैं, मुझे वास्तव में यकीन नहीं है कि यह किस तरह का मॉडलिंग का उद्देश्य था। लक्षण किस तरह के लिए डिज़ाइन किए गए थे?

Comments

आप लक्षणों के बारे में थोड़ा और समझा सकते हैं, लेकिन क्या लक्षण केवल रचनाओं के लिए एक और शब्द हो सकते हैं?

— त्रैलियन

en.wikipedia.org/wiki/Trait_(computer_programming)

— रॉबर्ट हार्वे

मैं वास्तव में जानना चाहूंगा कि क्यों। एक बार उनका उपयोग नहीं किया।

— एंडी

Answer 1

लक्षण रचना करने का एक और तरीका है। उन्हें संकलित समय (या JIT संकलन समय) पर कक्षा के सभी भागों की रचना करने के तरीके के रूप में सोचें, उन भागों के ठोस कार्यान्वयन को इकट्ठा करना होगा जिनकी आपको आवश्यकता होगी।

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

class TestMyClass
  extends WordSpecLike
  with Matchers
  with MyCustomTrait
  with BeforeAndAfterAll
  with BeforeAndAfterEach
  with ScalaFutures

यूनिट टेस्ट फ्रेमवर्क में अलग-अलग कॉन्फ़िगरेशन विकल्पों का एक टन होता है, और हर टीम की अलग-अलग प्राथमिकताएं होती हैं कि वे कैसे चीजें करना चाहते हैं। विकल्पों को लक्षणों में डालकर (जो withस्काला में उपयोग में मिलाया जाता है ), स्कैलेस्ट उन सभी विकल्पों की पेशकश कर सकता है जैसे कि कक्षा के नाम WordSpecLikeWithMatchersAndFutures, या एक रनटाइम बूलियन झंडे का एक टन बनाने के बिना WordSpecLike(enableFutures, enableMatchers, ...)। इससे ओपन / बंद सिद्धांत का पालन करना आसान हो जाता है । आप नई विशेषताओं को जोड़ सकते हैं, और नई विशेषताओं को जोड़कर, बस एक नया लक्षण जोड़ सकते हैं। यह इंटरफ़ेस अलगाव सिद्धांत का पालन करना भी आसान बनाता है , क्योंकि आप आसानी से एक विशेषता में सार्वभौमिक रूप से आवश्यक कार्यों को नहीं डाल सकते हैं।

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

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

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

Comments

नमस्ते, यह एक महान जवाब है। मैं पूछ सकता हूं कि यह कैसे तय किया जाए कि लक्षणों का उपयोग कब करना है, और निर्भरता इंजेक्शन का उपयोग कब करना है। जो लगता है वही हासिल होगा।

— एक्सट्राकुन

सूक्ष्म अवलोकन। मेरा संपादन देखें।

— कार्ल

इसे लिखने के लिए धन्यवाद। मैं रचना @KarlBielefeldt की तरह लक्षण के बारे में आपके उत्तर के बारे में उत्सुक हूं। आपकी कक्षा का उपयोग उस स्थान पर किया जा सकता है, जहाँ उस विशेषता की आवश्यकता होती है, और आप अभी भी एक नियमित इंटरफ़ेस के साथ उसी नाजुकता से पीड़ित होंगे। तो यह घटाव और विरासत के करीब लगता है, नहीं? मैं यह भी अनिश्चित हूं कि यह DI के समान कैसे है ... यदि आपके पास विभिन्न वर्ग हैं जो लक्षण का विस्तार करते हैं, तो उन ठोस निर्भरताएं नहीं हैं जहां पदानुक्रम में परिभाषित किया गया है कि वर्ग को परिभाषित किया गया है, बल्कि शीर्ष / प्रवेश बिंदु पर। कोड? धन्यवाद!

— आलस्टार

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

— कार्ल बेवेलफेल्ट