क्या एक वर्ग को अपने उपवर्गों के बारे में पता होना चाहिए?


24

क्या एक वर्ग को अपने उपवर्गों के बारे में पता होना चाहिए? क्या किसी वर्ग को कुछ ऐसा करना चाहिए जो उदाहरण के लिए दिए गए उपवर्ग के लिए विशिष्ट हो?

मेरी वृत्ति मुझे बताती है कि यह एक बुरा डिज़ाइन है, यह किसी प्रकार के विरोधी पैटर्न की तरह लगता है।


6
आमतौर पर नहीं, लेकिन विशेष मामलों में यह उपयोगी है।
कोडइन्चोस

यह है "Liskov प्रतिस्थापन सिद्धांत" या कभी कभी बस LSP, पर इसके बारे में पढ़ें: एक विरोधी पैटर्न, एक प्रसिद्ध एक कहा जाता en.wikipedia.org/wiki/Liskov_substitution_principle
जिमी हौफा

5
@ जिमीहॉफ़ - "लिस्कोव सबस्टीट्यूशन सिद्धांत" एक विरोधी पैटर्न का नाम नहीं है। एक विरोधी पैटर्न एलएसपी का उल्लंघन कर सकता है, लेकिन यह भी निश्चित नहीं है कि यह यहां सच होगा। यह संभव है कि, भले ही एक प्रकार यह जानता है कि यह उपप्रकार है, कि उपप्रकार अभी भी अपने माता-पिता के लिए contravariance और covariance के साथ प्रतिस्थापित किया जा सकता है।
मैथ्यू फ्लिन

4
@MatthewFlynn शायद मैं एलएसपी का उपयोग बहुत कम कर रहा हूं, लेकिन मेरी परिभाषा में यह तथ्य नहीं है कि वे सभी एलएसपी का अनुपालन करने वाले प्रत्येक अभिभावक की आवश्यकताओं को पूरा करते हैं, यह एक आवश्यकता है कि उनके पास एक डिकॉउलिंग ऐसी हो जो न केवल प्रत्येक अभिभावक से सहमत हो बल्कि आप एक और उपवर्ग लागू कर सकते हैं जो एलएसपी का उल्लंघन नहीं करता है। यदि पदानुक्रम स्वयं-जागरूक है, तो बाहरी कार्यान्वयन संभवतः आधार वर्ग को बदलने के बिना एलएसपी को पूरा नहीं कर सकता है। शायद यह कड़ाई से एलएसपी नहीं है, लेकिन यह ताकतवर है। और हां मुझे यह कहना चाहिए था कि एलएसपी उल्लंघन प्रतिमान है
जिमी होफा

2
कुछ समय के बाद मैंने इसका सामना किया, मैंने उस ज्ञान को एक ऐसी विधि में बदल दिया, जिसे एक उपवर्ग में ओवरराइड किया जा सकता है (या तो इसे अमूर्त या शुद्ध आभासी बनाकर, या एक समझदार डिफ़ॉल्ट कार्यान्वयन प्रदान किया जा सकता है जिसे ओवरराइड किया जा सकता है)।

जवाबों:


32

कक्षाओं की अवधारणा से निहित उत्तर "नहीं" है।

या तो जो भी कार्रवाई, डेटा या संबंध आप संभाल रहे हैं वह सभी उपवर्गों का हिस्सा है - फिर इसे वास्तविक प्रकार की जांच के बिना सुपरक्लास में संभाला जाना चाहिए। या यह केवल कुछ उपवर्गों पर लागू होता है - फिर आपको सही काम करने के लिए रन-टाइम प्रकार की जाँच करनी होगी, सुपरक्लास को तब बदलना होगा जब कोई अन्य व्यक्ति इसे प्राप्त करता है (या यह चुपचाप गलत काम कर सकता है), व्युत्पन्न वर्गों में परिवर्तन अपरिवर्तित सुपरक्लास को तोड़ सकता है, आदि।

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


4
इस नियम का एक अपवाद: वर्ग के प्रलेखन को अपने उपवर्गों को अपने पुस्तकालय में सूचीबद्ध करना चाहिए।
13

3
@Kieveli ... जब तक उस दस्तावेज को अद्यतन रखा जाता है।
मौविसील

14
किसी भी प्रयोग करने योग्य दस्तावेज़ीकरण उपकरण को वंशानुक्रम के पेड़ों को आकर्षित करने में सक्षम होना चाहिए ...
जोहान्स

13
मुझे नहीं लगता कि यह कोई अपवाद है। वर्ग अभी भी कुछ नहीं जानता है। प्रलेखन जानता है।
होन्जा ब्रेबेक

4
@ किवेली उह मैं पूरी तरह से असहमत हूं ।
जिम्मी हॉफ

16

इतना ही नहीं पता होना चाहिए , यह बस नहीं कर सकता ! आमतौर पर, एक वर्ग को कभी भी, कहीं भी बढ़ाया जा सकता है। यह उन वर्गों द्वारा बढ़ाया जा सकता है जो तब भी मौजूद नहीं थे जब यह लिखा गया था।

कुछ भाषाएँ सुपरक्लास द्वारा फैली कक्षाओं को नियंत्रित करने की अनुमति देती हैं। स्काला में, एक वर्ग के रूप में चिह्नित किया जा सकता है sealed, जिसका अर्थ है कि यह केवल उसी संकलन इकाई (स्रोत फ़ाइल) के भीतर अन्य वर्गों द्वारा विस्तारित किया जा सकता है। हालांकि, जब तक कि उपवर्ग भी नहीं हैं sealed या final, उपवर्गों को तब अन्य वर्गों द्वारा आगे बढ़ाया जा सकता है।

स्काला में, इसका उपयोग बंद बीजीय डेटा प्रकारों को मॉडल करने के लिए किया जाता है, इसलिए कैनोनिकल हास्केल Listप्रकार:

data List a = Nil | Cons a (List a)

इस तरह स्काला में मॉडलिंग की जा सकती है:

sealed trait List[+A]

case object Nil extends List[Nothing]

final case class Cons[+A] extends List[A]

और आपको लगता है कि गारंटी ले सकते हैं केवल उन दो उप "वर्गों" मौजूद हैं, क्योंकि Listहै sealedऔर इस प्रकार फ़ाइल की विस्तारित बाहर नहीं किया जा सकता, Consहै finalऔर इस तरह बिल्कुल भी नहीं बढ़ाई जा सकती है और Nilएक है objectजो वैसे भी नहीं बढ़ाई जा सकती।

लेकिन यह एक विशिष्ट उपयोग का मामला है (वंशानुक्रम के माध्यम से बीजीय डेटा प्रकार मॉडलिंग) और यहां तक ​​कि इस मामले में, सुपरक्लास वास्तव में इसके उपवर्गों के बारे में नहीं जानता है। यह उस प्रकार के उपयोगकर्ता के लिए अधिक गारंटी है Listकि यदि वह किसी के साथ भेदभाव करता है Nilऔर Cons, उसकी पीठ के पीछे कोई अन्य वैकल्पिक पॉपिंग नहीं होगी ।


कई भाषाओं में जो काम करता है वह किसी न किसी abstract internalसदस्य को जोड़ रहा है ।
कोडइन्कॉस्टोस नोव

4

सीधा - सा जवाब है 'नहीं।

यह कोड को भंगुर बनाता है और ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के दो बुनियादी सिद्धांतों को आवाज देता है।

  • लिस्कोव प्रतिस्थापन सिद्धांत
  • बंद सिद्धांत खोलें

1

हाँ कभी कभी। उदाहरण के लिए, जब सीमित संख्या में उपवर्ग मौजूद होते हैं। एक विज़िटर पैटर्न इस दृष्टिकोण की उपयोगिता का चित्रण है।

उदाहरण: कुछ अच्छी तरह से परिभाषित व्याकरण के एक सार वाक्यविन्यास वृक्ष (एएसटी) नोड्स को Nodeसभी नोड प्रकारों को संभालने के लिए एक आगंतुक पैटर्न को लागू करने वाले एकल वर्ग से विरासत में मिला जा सकता है ।


9
नहीं, नहीं और नहीं। यह उपयोगी नहीं है और एक अच्छा समाधान नहीं है।
सुल्तान

@ सुल्तान ने कक्षा के बाहर एएसटी के साथ काम किया है, और मुझे विश्वास है कि कोरस वास्तव में प्रश्न को नहीं समझता है। एक आगंतुक एक AST पर नोड का एक प्रकार नहीं है, यह एक अलग वस्तु है। इसे व्याकरण की वस्तुओं के बारे में पता होना चाहिए। लेकिन एक उच्च स्तर एएसटी नोड नहीं होना चाहिए।

1
@ जोहानगॉगन शब्द "जानता है" मुझे भ्रमित करता है। बेस Nodeक्लास, निश्चित रूप से, इसके उपवर्गों का कोई सीधा संदर्भ नहीं है। लेकिन इसमें acceptएक Visitorपैरामीटर के साथ एक विधि शामिल है । और प्रत्येक उपवर्ग Visitorमें एक visitविधि शामिल है । इसलिए, Nodeइसके उपवर्गों का कोई सीधा संदर्भ नहीं होने के बावजूद , यह Visitorइंटरफ़ेस के माध्यम से अप्रत्यक्ष रूप से उनके बारे में "जानता" है। वे सभी इसके माध्यम से एक साथ युग्मित हुए।
10

1
@ सुल्तान ने कभी नहीं कहा। विकल्प प्रकार उस मामले का एक वैध उदाहरण है जब सुपरक्लास वंशज के बारे में जानता है। लेकिन जैसा कि जॉर्ज ने कहा था कि इसे सील के रूप में चिह्नित किया जाएगा।
पावेल वोरोनिन

फिर सहमत हैं: एक आगंतुक को यह जानना होगा कि वह क्या देख रहा है।

1

यदि मैं एक फर्म के लिए एक घटक लिखता हूं और बाद में, मेरे जाने के बाद, कोई इसे अपने स्वयं के प्रयोजनों के लिए बढ़ाता है तो क्या मुझे इस बारे में सूचित किया जाना चाहिए?

नहीं!

कक्षाओं के साथ भी। अपनी प्रकृति पर विश्वास रखें।


नौकरी की सुरक्षा???
साठफुटेरसुड

आपका साठ फुट ऊँचा इसलिए मैं आपसे बहस नहीं करूँगा :-) हालाँकि, मुझे आशा है कि मेरे जाने के बाद मेरा अर्थ था और मुझे दूसरी नौकरी मिल गई थी।
डेनियल हॉलिन्रेके
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.