क्या उन वर्गों को बनाना बुरा है जिनका एकमात्र उद्देश्य दूसरे वर्ग में निहित रूप से परिवर्तित होना है?

Question

ऐसी स्थिति की कल्पना करें जहां हम एक पुस्तकालय का उपयोग कर रहे हैं जो आपको Circleऑब्जेक्ट बनाने की अनुमति देता है , जहां आप इसे परिभाषित करने के लिए त्रिज्या और सर्कल के केंद्र को निर्दिष्ट कर सकते हैं। हालांकि, किसी कारण के लिए, यह एक आवश्यक flavourपैरामीटर भी लेता है । अब कहते हैं कि मुझे वास्तव Circleमें अपने ऐप में उपयोग करने की आवश्यकता है , लेकिन अपने ऐप के प्रयोजनों के लिए मैं Flavours.Cardboardहर एक बार स्वाद सेट कर सकता हूं ।

इस "हल" करने के लिए, मैं अपने खुद के बनाने के Circleलिए एक अलग नाम स्थान है, जो केवल लेता में वर्ग radiusऔर centerपैरामीटर के रूप में, लेकिन बाहरी लाइब्रेरी की करने के लिए एक अंतर्निहित कनवर्टर है Circleवर्ग जो सिर्फ एक बनाता है Circle(this.radius, this.center, Flavours.Cardboard)वस्तु। इसलिए हर जगह मुझे दूसरे प्रकार की आवश्यकता है Circle, मैंने स्वचालित रूपांतरण होने दिया।

ऐसी कक्षा बनाने के परिणाम क्या हैं? क्या कोई बेहतर उपाय हैं? अगर मेरे एप्लिकेशन को इस बाहरी लाइब्रेरी के शीर्ष पर बनाया गया एक एपीआई होता तो क्या इससे कोई फर्क पड़ता है, जो अन्य प्रोग्रामर द्वारा उपयोग के लिए बनाया गया था?

Comments

यह एडेप्टर पैटर्न की भिन्नता की तरह लगता है , हालांकि यह यहां संदिग्ध मूल्य का लगता है (यह एक पैरामीटर सेट करने से बचने के लिए केवल एक सुविधा है)।

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

एक MakeCircle समारोह क्यों नहीं बनाया ?

— user253751

@ मिनीबिस थाय मेरा पहला विचार था। जब मैं गेम बना रहा होता हूं, तो मैं अक्सर उसी के तर्ज पर एक फंक्शन तैयार करता हूं, makePlayerजिसमें खुद को केवल प्लेयर को जगह देने के लिए कोर्ड स्वीकार करता है, लेकिन बहुत अधिक जटिल कंस्ट्रक्टर को सौंपता है।

— कार्क्जिनेट

Answer 1

हालांकि यह हमेशा बुरा नहीं होता है , यह बहुत दुर्लभ है कि निहित रूपांतरण आपका सबसे अच्छा विकल्प है।

मुद्दे हैं।

1. निहित रूपांतरण बहुत पठनीय नहीं हैं।
2. क्योंकि आप एक नई वस्तु बना रहे हैं, मूल वस्तु में कोई भी परिवर्तन आप द्वारा परिवर्तित करने वाले, बग के लिए अग्रणी द्वारा नहीं देखा जाएगा।
3. यदि आप ऑब्जेक्ट को फेंक रहे हैं, तो सफाई के लिए अतिरिक्त कचरा है।
4. यदि कोई समस्या है, तो यह तब होगा जब रूपांतरण होता है, न कि जब चीज़ बनाई जाती है, तो ऐसे कीड़े बनाते हैं जिन्हें नीचे ट्रैक करना मुश्किल होता है।

सामान्य तौर पर, बेहतर समाधान होते हैं।

1. आंतरिक रूप से दूसरे वर्ग / ढांचे का उपयोग करने वाले अपने स्वयं के पतले आवरण बनाएं।
2. एक सहायक विधि बनाएं जो आप चाहते हैं कि जो तंरगें तर्कों को लेती हैं और जो निश्चित है उसकी आपूर्ति करती है, उस तर्क को निर्दिष्ट किए बिना वास्तविक वस्तु को लौटाएं जिसकी आपको परवाह नहीं है।
3. समस्या वर्ग से बाहर निकलें और अपने स्वयं के, अच्छे निर्माणकर्ता की आपूर्ति करें।
4. एहसास है कि वास्तव में अतिरिक्त तर्क में गुजरना सौदा का उतना बड़ा नहीं है।

निजी तौर पर, मुझे लगता है कि # 2 को लागू करना सबसे सरल है, और डिजाइन पर सबसे कम बोझ है। दूसरों को ठीक किया जा सकता है, स्थिति को देखते हुए और आप इन वर्गों के साथ क्या करने की कोशिश कर रहे हैं।

अंतर्निहित रूपांतरण एक अंतिम उपाय है, और केवल तब ही मेरे लिए यह उचित लगता है जब मेरे पास C ++ शैली के फंक्शनलर्स हैं जो मैं बनाने की कोशिश कर रहा हूं - रणनीति ऑब्जेक्ट जो मैं स्पष्ट रूप से प्रतिनिधि प्रकारों में परिवर्तित करता हूं।

Answer 2

आप जिस परिदृश्य का वर्णन कर रहे हैं, उसे देखते हुए, आप आंशिक फ़ंक्शन अनुप्रयोग के बारे में सोच सकते हैं।

एक कंस्ट्रक्टर एक फ़ंक्शन है (कम से कम सिद्धांत में; C # में, आप एक "फ़ैक्ट्री फ़ंक्शन" बना सकते हैं जो कंस्ट्रक्टर को कॉल करता है):

Func<double, Point, Flavour, Circle> MakeCircle = (r, p, f) => new Circle(r, p, f);

आंशिक आवेदन के लिए, निम्नलिखित पर्याप्त होगा:

public static Func<T1, T2, R> Partial<T1, T2, T3, R>(this Func<T1, T2, T3, R> func, T3 t3)
   => (t1, t2) => func(t1, t2, t3);

अब आप अपने निर्माता को केवल 2 मापदंडों की आवश्यकता कर सकते हैं:

Func<double, Point, Circle> MakeCardboardCircle = Circle.Partial(Flavours.Cardboard)

तो अब आपके पास अपने वांछित मापदंडों के साथ एक फैक्ट्री फ़ंक्शन है

Circle c = MakeCardboardCircle(1.0, new Point(0, 0)))

BTW, यह स्पष्ट रूप से ऊपर विकल्प 2 के बराबर है, बस एक अधिक कार्यात्मक दृष्टिकोण से।