मैं अपनी प्रोग्रामिंग भाषा विकसित कर रहा हूं। यह एक सामान्य उद्देश्य की भाषा है (डेस्कटॉप के लिए स्टैटिकली टाइप किए गए पायथन को सोचें, यानी int x = 1;क्लाउड के लिए नहीं)।
क्या आपको लगता है कि विरासत या मिक्सिन्स को अनुमति नहीं देना ठीक है? (यह देखते हुए कि उपयोगकर्ता के पास कम से कम इंटरफेस होगा)
उदाहरण के लिए: Google Go, एक सिस्टम भाषा जिसने वंशानुक्रम की अनुमति नहीं देकर प्रोग्रामिंग समुदाय को झटका दिया।
जवाबों:
वास्तव में, हम अधिक से अधिक यह पाते हैं कि वंशानुक्रम का उपयोग उप-इष्टतम है क्योंकि (दूसरों के बीच) यह तंग युग्मन की ओर जाता है।
कार्यान्वयन वंशानुक्रम हमेशा इंटरफ़ेस विरासत प्लस संरचना द्वारा प्रतिस्थापित किया जा सकता है, और अधिक आधुनिक सॉफ्टवेयर डिज़ाइन रचना के पक्ष में कम और कम विरासत का उपयोग करने की दिशा में जाते हैं।
तो हाँ , विशेष रूप से विरासत प्रदान नहीं करना पूरी तरह से वैध है, और बहुत ही प्रचलन डिजाइन निर्णय में है।
Mixins, दूसरे हाथ पर, यहां तक कि (अभी तक) एक मुख्य धारा भाषा की सुविधा नहीं हैं, और जिन भाषाओं में है एक विशेषता "mixin" कहा जाता है प्रदान करते हैं अक्सर यह द्वारा बहुत अलग बातें समझते हैं। इसे प्रदान करने के लिए स्वतंत्र महसूस करें, या नहीं। व्यक्तिगत रूप से मुझे यह बहुत उपयोगी लगता है लेकिन इसे लागू करना बहुत कठिन हो सकता है।
वंशानुक्रम (या कोई एकल विशेषता, वास्तव में) के बारे में तर्क करना आवश्यक है या नहीं, इसके बिना भाषा के बाकी शब्दों पर विचार करना व्यर्थ है; आप शून्य में बहस कर रहे हैं।
आपको एक सुसंगत भाषा डिजाइन दर्शन की आवश्यकता है; भाषा को उन समस्याओं को हल करने में सक्षम होना चाहिए जो इसके लिए डिज़ाइन की गई हैं। इसे प्राप्त करने के लिए मॉडल को विरासत की आवश्यकता हो सकती है या नहीं, लेकिन बड़ी तस्वीर के बिना इसे आंकना मुश्किल है।
यदि, उदाहरण के लिए, आपकी भाषा में प्रथम श्रेणी के कार्य, आंशिक फ़ंक्शन अनुप्रयोग, पॉलीमॉर्फिक डेटा प्रकार, प्रकार चर और सामान्य प्रकार हैं, तो आपने बहुत से आधारों को कवर किया है जैसा कि आप क्लासिक ओओपी विरासत के साथ होगा, लेकिन एक अलग प्रतिमान का उपयोग करके।
यदि आपके पास देर से बाध्यकारी, गतिशील टाइपिंग, तरीके-गुण, लचीले फ़ंक्शन तर्क, और प्रथम श्रेणी के कार्य हैं, तो आप एक ही आधार को कवर भी करते हैं, लेकिन फिर से एक अलग प्रतिमान का उपयोग करते हैं।
(उल्लिखित दो प्रतिमानों के लिए उदाहरण ढूँढना पाठक के लिए एक अभ्यास के रूप में छोड़ा गया है।)
इसलिए, इस तरह के शब्दार्थों के बारे में सोचें जो आप चाहते हैं, उनके साथ खेलें और देखें कि क्या वे विरासत के बिना पर्याप्त हैं। यदि वे नहीं हैं, तो आप या तो मिश्रण में विरासत को फेंकने का निर्णय ले सकते हैं, या आप यह तय कर सकते हैं कि कुछ और गायब है।
हाँ।
मुझे लगता है कि विरासत की अनुमति नहीं देना ठीक है, खासकर यदि आपकी भाषा गतिशील रूप से टाइप की गई है। आप उदाहरण के लिए, प्रतिनिधिमंडल या रचना के द्वारा समान कोड पुन: उपयोग को प्राप्त कर सकते हैं। उदाहरण के लिए, मैंने कुछ मामूली जटिल कार्यक्रम लिखे हैं - ठीक है, यह जटिल नहीं है :) - जावास्क्रिप्ट में बिना किसी विरासत के। मैंने मूल रूप से वस्तुओं को बीजगणितीय डेटा संरचनाओं के रूप में उपयोग किया है, कुछ तरीकों के साथ संलग्न हैं। मेरे पास कार्यों का एक गुच्छा भी था जो इन वस्तुओं पर संचालित होने वाले तरीके नहीं थे ।
यदि आपके पास गतिशील टाइपिंग है - और मैं मान रहा हूं कि आप करते हैं - तो आप विरासत के बिना भी बहुरूपता हो सकते हैं। इसके अलावा, यदि आप रनटाइम में ऑब्जेक्ट्स में मनमाने तरीके जोड़ने की अनुमति देते हैं, तो आपको वास्तव में मिक्सिन्स जैसी चीजों की बहुत आवश्यकता नहीं होगी।
एक अन्य विकल्प - जो मुझे लगता है कि एक अच्छा है - जावास्क्रिप्ट का अनुकरण करना और प्रोटोटाइप का उपयोग करना है। ये कक्षाओं की तुलना में सरल हैं, फिर भी बहुत लचीले हैं। बस कुछ विचार करने के लिए।
इसलिए, सभी ने कहा, मैं इसके लिए जाऊंगा।
हां, यह वंशानुक्रम को छोड़ने के लिए पूरी तरह से उचित डिजाइन निर्णय है।
कार्यान्वयन विरासत को हटाने के वास्तव में बहुत अच्छे कारण हैं, क्योंकि यह कोड को बनाए रखने के लिए कुछ अत्यंत जटिल और कठिन उत्पादन कर सकता है। मैं यहां तक कि वंशानुक्रम के संबंध में भी जाना चाहता हूं (क्योंकि यह आमतौर पर ज्यादातर ओओपी भाषाओं में लागू होता है) एक मिसफिट के रूप में।
उदाहरण के लिए, क्लोजर कार्यान्वयन विरासत प्रदान नहीं करता है, ऑर्थोगोनल सुविधाओं (प्रोटोकॉल, डेटा, फ़ंक्शंस, मैक्रोज़) का एक सेट प्रदान करना पसंद करता है जिसका उपयोग समान परिणाम प्राप्त करने के लिए किया जा सकता है लेकिन बहुत अधिक सफाई से।
यहाँ एक वीडियो है जो मुझे इस सामान्य विषय पर बहुत ज्ञानवर्धक लगा, जहाँ रिच हिकी प्रोग्रामिंग भाषाओं (विरासत सहित) में जटिलता के मूलभूत स्रोतों की पहचान करता है और प्रत्येक के लिए विकल्प प्रस्तुत करता है: सरल बनाया आसान
जब मैंने पहली बार इस तथ्य पर दौड़ लगाई कि VB6 कक्षाएं वंशानुक्रम (केवल इंटरफेस) का समर्थन नहीं करती हैं, तो इसने मुझे वास्तव में नाराज कर दिया (और अभी भी)।
हालाँकि, इसका कारण इतना बुरा है कि इसमें कंस्ट्रक्टर पैरामीटर नहीं थे, इसलिए आप सामान्य निर्भरता इंजेक्शन (DI) नहीं कर सकते थे। यदि आपके पास DI है, तो यह विरासत से अधिक महत्वपूर्ण है क्योंकि आप विरासत के ऊपर अनुकूल रचना के सिद्धांत का पालन कर सकते हैं। वैसे भी कोड का फिर से उपयोग करने का यह एक बेहतर तरीका है।
हालांकि मिक्सिंस नहीं हैं? यदि आप एक इंटरफ़ेस लागू करना चाहते हैं और निर्भरता इंजेक्शन के माध्यम से सेट किए गए ऑब्जेक्ट के लिए उस इंटरफ़ेस के सभी काम को सौंपते हैं, तो मिक्सिन आदर्श हैं। अन्यथा आपको हर ऑब्जेक्ट और / या प्रॉपर्टी को चाइल्ड ऑब्जेक्ट को सौंपने के लिए सभी बॉयलरप्लेट कोड लिखना होगा। मैं इसे बहुत करता हूं (C # के लिए धन्यवाद) और यह एक बात है जो मैं चाहता हूं कि मुझे नहीं करना है।
किसी अन्य उत्तर से असहमत होने के लिए: नहीं, आप सुविधाओं को बाहर फेंकते हैं जब वे उस चीज से असंगत होते हैं जिसे आप अधिक चाहते हैं। जावा (और अन्य GC'd भाषाओं) ने स्पष्ट मेमोरी प्रबंधन को फेंक दिया क्योंकि यह प्रकार की सुरक्षा अधिक चाहता था। हास्केल ने उत्परिवर्तन को बाहर फेंक दिया क्योंकि यह समान तर्क और फैंसी प्रकार अधिक चाहता था। यहां तक कि सी ने कुछ प्रकार के अलियासिंग और अन्य व्यवहार को बाहर कर दिया (या अवैध घोषित कर दिया) क्योंकि यह संकलक अनुकूलन अधिक चाहता था।
तो सवाल यह है: आप विरासत से अधिक क्या चाहते हैं?
free/ deleteऑपरेशन आपको संदर्भों को अमान्य करने की क्षमता देता है; जब तक आपका प्रकार सिस्टम सभी प्रभावित संदर्भों को ट्रैक करने में सक्षम नहीं होता है, जो भाषा को असुरक्षित बनाता है। विशेष रूप से, न तो C और न ही C ++ सुरक्षित है। यह सच है कि आप उन्हें सहमत करने के लिए एक या दूसरे (जैसे रैखिक प्रकार या आवंटन प्रतिबंध) में समझौता कर सकते हैं। सटीक होने के लिए मुझे कहना चाहिए कि जावा एक विशेष, सरल प्रकार की प्रणाली और अप्रतिबंधित आवंटन के साथ प्रकार की सुरक्षा चाहता था ।
nullसंदर्भों की अनुमति देता है )। मना freeकरना एक बहुत ही मनमाना अतिरिक्त प्रतिबंध है। सारांश में, भाषा सुरक्षित है या नहीं, यह भाषा की तुलना में आपके प्रकार की सुरक्षा पर निर्भर करता है।
Tसंदर्भ nullया तो एक वर्ग के एक वस्तु या विस्तार का संदर्भ देता है T; nullबदसूरत है, लेकिन nullऊपर के प्रकार को दूषित करने के बजाय एक अच्छी तरह से परिभाषित अपवाद को फेंकने पर ऑपरेशन । C ++ के साथ विरोधाभास: कॉल करने के बाद delete, एक T*पॉइंटर मेमोरी को इंगित कर सकता है जो अब Tऑब्जेक्ट नहीं रखता है । इससे भी बदतर, एक असाइनमेंट में उस पॉइंटर का उपयोग करके एक फ़ील्ड असाइनमेंट करना, आप पूरी तरह से एक अलग वर्ग के ऑब्जेक्ट के क्षेत्र को पूरी तरह से अपडेट कर सकते हैं अगर यह सिर्फ पास के पते पर रखा जाए। यह शब्द की किसी भी उपयोगी परिभाषा से प्रकार की सुरक्षा नहीं है।
नहीं।
यदि आप एक बेस लैंग्वेज फीचर को हटाना चाहते हैं, तो आप सार्वभौमिक रूप से यह घोषणा कर रहे हैं कि यह कभी भी आवश्यक नहीं है (या लागू करने के लिए अनुचित रूप से भिन्न, जो यहां लागू नहीं होता है)। और सॉफ्टवेयर इंजीनियरिंग में "कभी नहीं" एक मजबूत शब्द है। इस तरह का बयान देने के लिए आपको बहुत शक्तिशाली औचित्य की आवश्यकता होगी।
कड़ाई से सी + + बोलने वाले से बोलते हुए, विरासत दो मुख्य उद्देश्यों के लिए उपयोगी है:
बिंदु 1 के लिए जब तक आपके पास बहुत अधिक कलाबाजी में लिप्त होने के बिना कोड साझा करने का कोई तरीका है, आप विरासत के साथ दूर कर सकते हैं। बिंदु 2 के लिए। आप जावा के रास्ते पर जा सकते हैं और इस सुविधा को लागू करने के लिए इंटरफ़ेस पर जोर दे सकते हैं।
वंशानुक्रम हटाने का लाभ है
यह व्यापार मुख्यतः "डॉन्ट रिपीट योरसेल्फ" और एक तरफ लचीलेपन और दूसरी तरफ समस्या-परिहार के बीच होता है। व्यक्तिगत रूप से मुझे विरासत से देखने से नफरत होगी C ++ से जाना बस कुछ अन्य डेवलपर को समस्याएँ दूर करने के लिए पर्याप्त स्मार्ट नहीं हो सकता है।
क्या आपको लगता है कि विरासत या मिक्सिन्स को अनुमति नहीं देना ठीक है? (यह देखते हुए कि उपयोगकर्ता के पास कम से कम इंटरफेस होगा)
आप कार्यान्वयन विरासत या मिश्रण के बिना बहुत उपयोगी काम कर सकते हैं , लेकिन मुझे आश्चर्य है कि क्या आपके पास किसी प्रकार का इंटरफ़ेस वंशानुक्रम होना चाहिए, अर्थात, एक घोषणा जो कहती है कि यदि कोई वस्तु इंटरफ़ेस ए लागू करता है, तो उसे भी बी (यानी इंटरफ़ेस) की आवश्यकता होती है A, B का एक विशेषज्ञता है और इसलिए एक प्रकार का संबंध है)। दूसरी ओर, आपकी परिणामी वस्तु को केवल रिकॉर्ड की आवश्यकता है कि यह दोनों इंटरफेस को लागू करता है, इसलिए वहां बहुत अधिक जटिलता नहीं है। सभी पूरी तरह से उल्लेखनीय हैं।
कार्यान्वयन विरासत की कमी का एक स्पष्ट पहलू है, हालांकि: आप अपनी कक्षाओं के लिए संख्यात्मक-अनुक्रमित vtables का निर्माण करने में असमर्थ होंगे और इसलिए हर विधि कॉल के लिए हैश लुकअप करना होगा (या उनसे बचने के लिए एक चतुर तरीका समझें)। यह दर्दनाक हो सकता है यदि आप इस तंत्र के माध्यम से मौलिक मूल्यों (जैसे, संख्या) को भी पार कर रहे हैं। यहां तक कि बहुत अच्छा हैश कार्यान्वयन महंगा हो सकता है जब आप इसे हर आंतरिक लूप में कई बार मारते हैं!