जावा का इंटरफ़ेस और हास्केल का प्रकार वर्ग: अंतर और समानताएँ?

Question

जब मैं हास्केल सीख रहा था, तो मैंने इसके प्रकार की कक्षा पर ध्यान दिया , जो कि हास्केल से उत्पन्न एक महान आविष्कार माना जाता है।

हालाँकि, प्रकार वर्ग पर विकिपीडिया पृष्ठ में :

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

जो मुझे जावा के इंटरफ़ेस के करीब लगता है ( विकिपीडिया के इंटरफ़ेस (जावा) पृष्ठ को उद्धृत करते हुए ):

जावा प्रोग्रामिंग भाषा में एक इंटरफ़ेस एक अमूर्त प्रकार है जिसका उपयोग एक इंटरफ़ेस निर्दिष्ट करने के लिए किया जाता है (शब्द के सामान्य अर्थ में) जो कक्षाएं लागू होती हैं।

ये दो समान दिखते हैं: टाइप क्लास एक प्रकार के व्यवहार को सीमित करता है, जबकि इंटरफ़ेस एक वर्ग के व्यवहार को सीमित करता है।

मुझे आश्चर्य है कि जावा में हास्केल और इंटरफ़ेस में टाइप क्लास के बीच अंतर और समानताएं क्या हैं, या शायद वे मौलिक रूप से अलग हैं?

संपादित करें: मैंने देखा कि haskell.org भी मानता है कि वे समान हैं । यदि वे समान हैं (या वे हैं?), तो इस तरह के प्रचार के साथ टाइप क्लास का व्यवहार क्यों किया जाता है?

अधिक संपादित करें: वाह, बहुत बढ़िया जवाब! मुझे लगता है कि मुझे उस समुदाय को तय करने देना होगा जो सबसे अच्छा है। हालांकि, जवाबों को पढ़ते समय, वे सभी सिर्फ यह कहते प्रतीत होते हैं कि "कई चीजें टाइपकास्ट कर सकती हैं, जबकि इंटरफ़ेस जेनरिक के साथ सामना नहीं कर सकता है" । मैं मदद नहीं कर सकता, लेकिन सोच रहा था कि टाइपकास्टल नहीं कर सकते, तो कुछ भी इंटरफेस हो सकता है? इसके अलावा, मैंने देखा कि विकिपीडिया का दावा है कि टाइपक्लास का आविष्कार मूल रूप से 1989 के पेपर में हुआ था * "एड-हॉक पोलिमोर्फ़िज्म को कम तदर्थ कैसे बनाया जाए", जबकि हास्केल अभी भी अपने पालने में है, जबकि जावा प्रोजेक्ट 1991 में शुरू किया गया था और पहली बार 1995 में जारी किया गया था। तो हो सकता है कि टाइपकास्ट के बजाय इंटरफेस के समान हो, इसके दूसरे तरीके के आसपास, उस इंटरफेस को टाइपकास्ट से प्रभावित किया गया था?क्या कोई दस्तावेज / कागजात इसका समर्थन करते हैं या इसे रोकते हैं? सभी उत्तर के लिए धन्यवाद, वे सभी बहुत ज्ञानवर्धक हैं!

सभी जानकारी के लिए धन्यवाद!

Comments

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

— सीए मैककैन

यदि आपके पास कई प्रश्न हैं, तो आपको कई प्रश्न पूछने चाहिए, उन सभी को एक प्रश्न में रटने का प्रयास न करें। वैसे भी, आपके अंतिम प्रश्न का उत्तर देने के लिए: जावा का मुख्य प्रभाव ऑब्जेक्टिव-सी है (और नहीं सी ++ जैसा कि अक्सर गलत तरीके से रिपोर्ट किया जाता है), जिसका मुख्य प्रभाव स्मालटाक और सी। है। जावा के इंटरफेस ऑब्जेक्टिव-सी के प्रोटोकॉल प्रोटोकॉल का अनुकूलन हैं जो फिर से एक हैं OO में प्रोटोकॉल के विचार की औपचारिकता , जो बदले में नेटवर्किंग में प्रोटोकॉल के विचार पर आधारित है , विशेष रूप से ARPANet। यह सब आपके द्वारा उद्धृत पेपर के बहुत पहले हुआ। ...

— Jörg W Mittag

... जावा पर हास्केल का प्रभाव बहुत बाद में आया, और जेनरिक तक ही सीमित है, जो आखिरकार, हास्केल, फिल वाडलर के डिजाइनरों में से एक द्वारा सह-डिजाइन किया गया था।

— Jörg W Mittag

यह पैट्रिक नॉटन द्वारा यूज़नेट का एक लेख है, जो जावा के मूल डिजाइनरों में से एक है: जावा वाजिबली-सी द्वारा प्रबल रूप से प्रभावित था और सी ++ नहीं । दुर्भाग्य से, यह इतना पुराना है कि ऑर्निगल पोस्टिंग Google के अभिलेखागार में भी दिखाई नहीं देती है।

— जोर्ज डब्ल्यू मित्तग

एक और प्रश्न है जो इस एक के सटीक डुप्लिकेट के रूप में बंद किया गया था, लेकिन इसकी गहराई से उत्तर में बहुत अधिक है: stackoverflow.com/questions/8122109/…

— बेन

Answer 1

मैं कहूंगा कि एक इंटरफ़ेस एक प्रकार के वर्ग की तरह है SomeInterface tजहां सभी मानों का प्रकार होता है t -> whatever(जिसमें whateverशामिल नहीं है t)। ऐसा इसलिए है क्योंकि जावा और इसी तरह की भाषाओं में वंशानुक्रम के संबंध के साथ, विधि कहा जाता है, जिस प्रकार की वस्तु पर उन्हें बुलाया जाता है, और कुछ नहीं।

इसका मतलब है कि add :: t -> t -> tइंटरफ़ेस के साथ चीजों को बनाना बहुत मुश्किल है , जहां यह एक से अधिक मापदंडों पर बहुरूपी है, क्योंकि इंटरफ़ेस के लिए यह निर्दिष्ट करने का कोई तरीका नहीं है कि तर्क प्रकार और वापसी का तरीका उसी प्रकार का है जैसे कि अब का प्रकार ऑब्जेक्ट इसे कहा जाता है (यानी "स्व" प्रकार)। जेनेरिक के साथ, जेनेरिक पैरामीटर के साथ एक इंटरफ़ेस बनाकर इसे नकली करने के लिए थोड़े तरीके हैं जो कि ऑब्जेक्ट के समान ही होने की उम्मीद है, जैसे कि Comparable<T>यह कैसे करता है, जहां आपको उपयोग करने की उम्मीद है Foo implements Comparable<Foo>ताकि compareTo(T otherobject)प्रकार का प्रकार हो t -> t -> Ordering। लेकिन फिर भी प्रोग्रामर को इस नियम का पालन करने की आवश्यकता होती है, और सिरदर्द का कारण भी बनता है जब लोग एक फ़ंक्शन बनाना चाहते हैं जो इस इंटरफ़ेस का उपयोग करता है, उनके पास पुनरावर्ती सामान्य प्रकार के पैरामीटर होने चाहिए।

इसके अलावा, आपके पास ऐसी चीज़ें नहीं होंगी empty :: tक्योंकि आप यहां कोई फ़ंक्शन नहीं कह रहे हैं, इसलिए यह एक विधि नहीं है।

Comments

स्काला लक्षण (मूल रूप से इंटरफेस) यह टाइप करने की अनुमति देता है ताकि आप "स्व प्रकार" के मापदंडों को वापस कर सकें या स्वीकार कर सकें। स्काला की एक पूरी तरह से अलग विशेषता है जिसे वे "स्व प्रकार" btw कहते हैं जिसका इससे कोई लेना-देना नहीं है। इसमें से कोई भी एक वैचारिक अंतर नहीं है, सिर्फ कार्यान्वयन अंतर है।

— क्ले

Answer 2

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

उस रास्ते से, यहाँ कुछ उल्लेखनीय अंतर हैं:

• इंटरफेसेस तरीके हमेशा एक वस्तु उदाहरण के साथ जुड़े होते हैं। दूसरे शब्दों में, हमेशा एक निहित 'यह' पैरामीटर होता है जो कि वह वस्तु है जिस पर विधि कहा जाता है। एक प्रकार वर्ग फ़ंक्शन के सभी इनपुट स्पष्ट हैं।
• एक इंटरफ़ेस कार्यान्वयन को उस वर्ग के भाग के रूप में परिभाषित किया जाना चाहिए जो इंटरफ़ेस को लागू करता है। इसके विपरीत, एक प्रकार के वर्ग 'उदाहरण' को इसके संबद्ध प्रकार से पूरी तरह से अलग किया जा सकता है ... यहां तक ​​कि दूसरे मॉड्यूल में भी।

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

Comments

आप टाइपसेकल्स का विस्तार कैसे करेंगे? क्या टाइपसेकल्स अन्य टाइपकास्टेस का विस्तार कर सकते हैं जैसे इंटरफेस कैसे इंटरफेसों का विस्तार कर सकता है?

— CMCDragonkai

यह इंटरफेस में जावा 8 के डिफ़ॉल्ट कार्यान्वयन के प्रकाश में इस उत्तर को अपडेट करने के लायक हो सकता है।

— मोनिका

@CMCDragonkai हां, आप उदाहरण के लिए "वर्ग (फू ए) => बार ए ए ..." कह सकते हैं कि बार प्रकार वर्ग फू प्रकार वर्ग का विस्तार करता है। जावा की तरह, हास्केल के यहाँ कई विरासत हैं।

— मोनिका

इस मामले में क्लोजर में प्रोटोकॉल के समान वर्ग नहीं है लेकिन टाइप सुरक्षा के साथ?

— नवाफाल

Answer 3

"एड-हॉक पोलिमोर्फ़िज्म" को व्यक्त करने के लिए एक संरचित तरीके के रूप में टाइप कक्षाएं बनाई गईं, जो मूल रूप से ओवरलोड कार्यों के लिए तकनीकी शब्द है । एक प्रकार की वर्ग परिभाषा कुछ इस प्रकार है:

class Foobar a where
    foo :: a -> a -> Bool
    bar :: String -> a

इसका मतलब यह है कि, जब आप फ़ंक्शन fooका उपयोग उस प्रकार के कुछ तर्कों पर लागू करते हैं जो कक्षा से संबंधित हैं Foobar, तो यह fooउस प्रकार के विशिष्ट के कार्यान्वयन को देखता है , और इसका उपयोग करता है। यह अधिक लचीली और सामान्यीकृत को छोड़कर, C ++ / C # जैसी भाषाओं में ऑपरेटर ओवरलोडिंग के साथ स्थिति के समान है।

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

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

संक्षेप में: वे समान उद्देश्यों की सेवा करते हैं, लेकिन जिस तरह से वे काम करते हैं वह कुछ अलग है, और प्रकार की कक्षाएं दोनों बहुत अधिक अभिव्यंजक हैं और कुछ मामलों में, निश्चित प्रकारों पर काम करने के कारण उपयोग करने के लिए सरल है, बल्कि एक विरासत पदानुक्रम के टुकड़े।

Comments

मैं हास्केल में प्रकार के पदानुक्रम को समझने के साथ संघर्ष कर रहा था, आप ओमेगा जैसी प्रकार की प्रणालियों के बारे में क्या सोचते हैं? क्या वे प्रकार पदानुक्रम का अनुकरण कर सकते हैं?

— CMCDragonkai

@CMCDragonkai: मैं ओमेगा के साथ वास्तव में कहने के लिए पर्याप्त परिचित नहीं हूं, क्षमा करें।

— सीए मैककैन

Answer 4

मैंने उपरोक्त उत्तर पढ़े हैं। मुझे लगता है कि मैं थोड़ा और स्पष्ट रूप से जवाब दे सकता हूं:

एक हास्केल "प्रकार वर्ग" और एक जावा / सी # "इंटरफ़ेस" या एक स्काला "विशेषता" मूल रूप से अनुरूप हैं। उनके बीच कोई वैचारिक भेद नहीं है लेकिन कार्यान्वयन अंतर हैं:

• हास्केल प्रकार की कक्षाएं "उदाहरण" के साथ लागू की जाती हैं जो डेटा प्रकार की परिभाषा से अलग होती हैं। C # / Java / Scala में, इंटरफेस / लक्षण को क्लास की परिभाषा में लागू किया जाना चाहिए।
• हास्केल प्रकार की कक्षाएं आपको इस प्रकार या स्व प्रकार को वापस करने की अनुमति देती हैं। Scala लक्षण भी (यह टाइप करें)। ध्यान दें कि स्काला में "स्व प्रकार" पूरी तरह से असंबंधित विशेषता है। Java / C # को इस व्यवहार के बारे में जानने के लिए जेनरिक के साथ एक गड़बड़ काम करने की आवश्यकता है।
• हास्केल प्रकार की कक्षाएं आपको इनपुट के बिना फ़ंक्शन (स्थिरांक सहित) को परिभाषित करने देती हैं यह "प्रकार" पैरामीटर। जावा / सी # इंटरफेस और स्काला लक्षण सभी कार्यों पर "यह" इनपुट पैरामीटर की आवश्यकता होती है।
• हास्केल प्रकार की कक्षाएं आपको कार्यों के लिए डिफ़ॉल्ट कार्यान्वयन को परिभाषित करने देती हैं। तो स्काला लक्षण और जावा 8+ इंटरफेस करें। C # एक्सटेंशन विधियों के साथ कुछ इस तरह अनुमानित कर सकता है।

Comments

बस इस उत्तर बिंदुओं में कुछ साहित्य जोड़ने के लिए, मैं ऑन (हास्केल) टाइप क्लासेस और (सी #) इंटरफेस आज पढ़ता हूं , जो जावस के बजाय सी # इंटरफेस के साथ भी तुलना करता है, लेकिन अच्छी तरह से वैचारिक पक्ष पर एक समझ देनी चाहिए। भाषा सीमाओं के पार इंटरफ़ेस।

— daniel.kahlenberg

मुझे लगता है कि डिफ़ॉल्ट कार्यान्वयन जैसी चीजों के लिए कुछ सन्निकटन कहीं अधिक कुशलता के साथ # अमूर्त कक्षाओं में किए जाते हैं?

— अरविन

Answer 5

में प्रोग्रामिंग के मास्टर मन , वहाँ फिल वाद्लेर, प्रकार कक्षाओं के आविष्कारक, जो हास्केल में जावा में इंटरफेस और प्रकार वर्गों के बीच समानता की व्याख्या के साथ हास्केल के बारे में एक साक्षात्कार है:

एक जावा विधि की तरह:

   public static <T extends Comparable<T>> T min (T x, T y) 
   {
      if (x.compare(y) < 0)
            return x; 
      else
            return y; 
   }

हास्केल विधि के समान है:

   min :: Ord a => a -> a -> a
   min x y  = if x < y then x else y

तो, टाइप कक्षाएं इंटरफेस से संबंधित हैं, लेकिन वास्तविक पत्राचार एक स्थिर विधि होगी जो ऊपर दिए गए प्रकार के साथ पैराड्राइज्ड है।

Comments

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

— वोंग जिया हौ

Answer 6

फिलिप वाडलर की बात विश्वास, विकास और प्रोग्रामिंग भाषाएँ देखें । वाडलर ने हास्केल पर काम किया और जावा जेनरिक में एक प्रमुख योगदानकर्ता था।

Comments

प्रासंगिक सामान कहीं 25m के आसपास है (हालांकि शुरुआत काफी मज़ेदार है)।

— फ्रेड फू

Answer 7

सॉफ़्टवेयर एक्सटेंशन और टाइप कक्षाओं के साथ एकीकरण पढ़ें जहां उदाहरण दिए गए हैं कि किस प्रकार वर्ग कई समस्याओं को हल कर सकते हैं जो इंटरफेस नहीं कर सकते हैं।

कागज में सूचीबद्ध उदाहरण हैं:

• अभिव्यक्ति की समस्या,
• फ्रेमवर्क एकीकरण समस्या,
• स्वतंत्र एक्स्टेंसिबिलिटी की समस्या,
• प्रमुख अपघटन, बिखरने और स्पर्श के अत्याचार।

Comments

लिंक ऊपर मर चुका है। इसके बजाय यह प्रयास करें ।

— जस्टिन लेटेजब

अच्छा अब वह भी मर गया। प्रयास करें कि यह एक

— RichardW

Answer 8

मैं "प्रचार" के लिए बात नहीं कर सकता, अगर यह उस तरह से ठीक लगता है। लेकिन हाँ टाइप कक्षाएं बहुत सारे तरीकों से समान हैं। एक अंतर जो मैं सोच सकता हूं, वह यह है कि यह हास्केल आप कुछ प्रकार के संचालन के लिए व्यवहार प्रदान कर सकते हैं :

class  Eq a  where
  (==), (/=) :: a -> a -> Bool
  x /= y     = not (x == y)
  x == y     = not (x /= y)

जो दिखाता है कि दो ऑपरेशन, समान (==)और समान नहीं हैं (/=), उन चीजों के लिए जो Eqटाइप क्लास के उदाहरण हैं । लेकिन बराबर-बराबर ऑपरेशन को बराबरी के संदर्भ में परिभाषित किया गया है (ताकि आपको केवल एक प्रदान करना पड़े), और इसके विपरीत।

तो शायद-कानूनी-जावा में ऐसा कुछ नहीं होगा:

interface Equal<T> {
    bool isEqual(T other) {
        return !isNotEqual(other); 
    }

    bool isNotEqual(T other) {
        return !isEqual(other); 
    }
}

और जिस तरह से यह काम करेगा वह यह है कि आपको इंटरफ़ेस को लागू करने के लिए केवल उन तरीकों में से एक प्रदान करना होगा। इसलिए मैं कहूंगा कि इंटरफ़ेस स्तर पर आप जिस तरह का व्यवहार चाहते हैं, उसका आंशिक कार्यान्वयन प्रदान करने की क्षमता में अंतर है।

Answer 9

वे समान हैं (पढ़ें: इसका समान उपयोग है), और संभवतः इसी तरह लागू किया गया: हास्केल में बहुरूपिक कार्य, हुड के तहत टाइपसेकल्स से जुड़े कार्यों को सूचीबद्ध करने के लिए एक 'व्यवहार्य' के तहत लेते हैं।

इस तालिका को अक्सर संकलन समय पर काटा जा सकता है। यह शायद जावा में कम सच है।

लेकिन यह कार्यों की एक तालिका है , न कि विधियाँ । विधियाँ किसी वस्तु से बंधी होती हैं, हास्केल टाइपकालेज़ नहीं होते हैं।

उन्हें जावा के जेनेरिक की तरह देखें।

Answer 10

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

एक और अंतर यह है कि आप एक प्रकार के आधार पर विधियों का उपयोग कर सकते हैं, तब भी जब आपके पास उस प्रकार का ठोस मूल्य नहीं है जो अभी तक लटका हुआ है!

उदाहरण के लिए, read :: Read a => String -> a। इसलिए यदि आपके पास पर्याप्त अन्य प्रकार की जानकारी है, जिसके बारे में आप "पढ़" के परिणाम का उपयोग करेंगे, तो आप संकलक को यह पता लगाने दे सकते हैं कि आपको किस शब्द का उपयोग करना है।

आप ऐसी चीजें भी कर सकते हैं, instance (Read a) => Read [a] where...जो आपको पठनीय चीजों की किसी सूची के लिए रीड इंस्टेंस को परिभाषित करने देती हैं। मुझे नहीं लगता कि जावा में यह संभव है।

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

Comments

सामान्य प्रकार की कक्षाएं इंटरफेस में हैं क्योंकि मल्टी-पैरामीटर प्रकार की कक्षाएं OOP में एकाधिक-प्रेषण के लिए हैं; आप प्रोग्रामिंग भाषा और प्रोग्रामर के सिरदर्द दोनों की शक्ति में एक समान वृद्धि प्राप्त करते हैं।

— सीए मैककैन