2011-03-30 10 views
48

मैं आमतौर पर यह सुनिश्चित करने का प्रयास करता हूं कि मेरा ऑब्जेक्ट उदाहरण Liskov Substitution Principle का अनुपालन करता है, लेकिन मैंने हमेशा सोचा है कि क्या लोग सोचते हैं कि एलएसपी को कन्स्ट्रक्टरों पर भी आवेदन करना चाहिए?क्या रचनाकारों को लिस्कोव प्रतिस्थापन सिद्धांत का अनुपालन करना चाहिए?

मैंने इसके लिए googling की कोशिश की है, लेकिन मैं किसी भी मजबूत राय को खोजने में सक्षम नहीं हूं।

मुझे ध्यान रखना चाहिए कि मेरा अधिकांश कोड रूबी में है, लेकिन मुझे कभी-कभी पता चलता है कि मेरे सबक्लास निर्माता मूल वर्ग से थोड़ा अलग हैं। वे तर्कों का एक ही आधार सेट लेते हैं, और अक्सर अतिरिक्त तर्क देते हैं। कभी-कभी यह अन्य वर्ग विधियों के साथ भी होता है।

मेरे सिर के पीछे यह हमेशा एक एलएसपी उल्लंघन की तरह महसूस किया है, लेकिन मैं देखना चाहता था कि कोई और भी इस तरह महसूस करता है।

उत्तर

50

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

यह एक अच्छा उदाहरण है कि ColoredSquareSquare का उचित उपप्रकार हो सकता है, लेकिन एक अतिरिक्त पैरामीटर की आवश्यकता है: color। यदि आप इस उपप्रकार की तरह चीजें नहीं कर पाएंगे तो बहुत कम उपयोगी होगा।

कुछ अर्थ में, निर्माता वास्तव में प्रकार का हिस्सा नहीं है: यह एक ऐसा कार्य है जो उस प्रकार का तत्व देता है। इस प्रकार, एक उप प्रकार के लिए एक नया कन्स्ट्रक्टर परिभाषित, एलएसवी तोड़ नहीं है।

+5

"जब आप एक निर्माता का उपयोग करते हैं तो आप जानते हैं कि आप उप प्रकार से निपट रहे हैं।" धन्यवाद। यह एक बड़ा मुद्दा है। – Chance

+0

रचनाकारों, स्थैतिक फैक्ट्री विधियों, फैक्ट्री विधियों के बीच एक अंतर बनाने के लिए संभवतः महत्वपूर्ण है जो कि उत्पाद के प्रकार (सबसे विशेष रूप से 'क्लोन'), और अन्य कारखानों के उदाहरण हैं। स्टेटिक फैक्ट्रियां विभिन्न प्रकार की वस्तुओं का उत्पादन कर सकती हैं जो रिटर्न प्रकार से ली गई हैं, लेकिन एलएसपी उत्पादित सभी वस्तुओं पर लागू होना चाहिए; हालांकि, कोई आवश्यकता नहीं है कि व्युत्पन्न वर्ग बेस क्लास के समान स्थिर तरीकों का समर्थन करते हैं। यदि कोई वर्ग 'क्लोन' जैसी फैक्ट्री विधि का समर्थन करता है, तो किसी को एलएसपी का सम्मान करना चाहिए और उपप्रकारों में समान अर्थशास्त्र का समर्थन करना चाहिए। – supercat

+0

कारखानों के लिए जो अन्य प्रकार की चीजें लौटाते हैं, व्युत्पन्न फैक्ट्री से लौटाई गई वस्तु को उस वस्तु के उदाहरण के रूप में उपयोग करने योग्य होना चाहिए जो आधार कारखाने से वापस किया जाएगा। इसलिए यदि 'कारफैक्टरी' में 'मेककर()' विधि है जो 'कार' लौटाती है, जो बदले में 'ड्राइव()' विधि का समर्थन करती है, तो उसे 'SomeCarFactory.MakeCar() ड्राइव() ड्राइव' कॉल करने में सक्षम होना चाहिए) 'कुछ करफैक्टरी' वास्तव में एक 'फोर्ड फैक्ट्री' है (जिसे 'कारफैक्टरी' प्राप्त होता है) जो 'फोर्ड' (जो 'कार' प्राप्त करता है) देता है। – supercat

1

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

13

निश्चित रूप से नहीं।

कंस्ट्रक्टर्स सामान्य रूप से उप-प्रकारों के लिए विशेष कर रहे हैं। रचनाकारों को एलएसपी लागू करने की कोशिश करना यह कहने जैसा होगा कि उपप्रकारों में विशिष्ट विधियों या सदस्यों को जोड़ा नहीं जा सकता है। लेकिन प्रतिबंध केवल दूसरी तरफ है।

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

यहां एलएसपी का कोई उल्लंघन नहीं है, यह केवल क्लास विधियों (रचनाकारों या किसी अन्य वर्ग विधियों) के लिए उदाहरण विधियों पर लागू होता है।

संबंधित मुद्दे

 संबंधित मुद्दे