ओओपी भाषा और प्रकार में वर्ग

Question

प्रोग्रामिंग भाषा सिद्धांत में, एक प्रकार मूल्यों का एक समूह है। उदाहरण के लिए "int" सभी पूर्णांक मानों का समूह है।

ओओपी भाषाओं में, एक वर्ग एक प्रकार है, यह है?

जब एक वर्ग को एक से अधिक सदस्यों के साथ परिभाषित किया जाता है, जैसे

class myclass{
    int a; 
    double b;
}

जब हम एक वर्ग के बारे में बात करते हैं, तो क्या हमारा मतलब है

• " (a,b)जहां aएक इंट है और bएक डबल है", या
• {" (x,y)| xकोई इंट है, yकोई डबल} है"?

क्या मतलब की एक उदाहरण myclassहै?

• " (a,b)जहां aएक इंट है और bएक डबल है", या
• एक ऑब्जेक्ट जो एक मेमोरी स्पेस पर कब्जा कर लेता है और जो कर सकता है (जरूरी नहीं, यानी खाली हो सकता है) स्टोर (x,y), जहां xकोई इंट है और yकोई डबल है?

Comments

एक वर्ग एक प्रकार है। "{(एक्स, वाई) | x है किसी भी पूर्णांक, वाई किसी भी डबल है}" " , लगभग सही होगा दो बातें होती है: जबकि एक वर्ग धारणात्मक एक रिकार्ड है 1) यदि आप एक टपल का उपयोग किया है - आप का उल्लेख अपने नाम, नहीं स्थिति से क्षेत्रों, और 2) क्षेत्रों के साथ हर रिकॉर्ड aऔर bउस प्रकार के सदस्यों, कर रहे हैं के रूप में किलन आगे उल्लेख MyClass है। isomorphic क्षेत्रों के साथ रिकॉर्ड के aऔर bके प्रकार intऔर double- आप ऐसा एक रिकार्ड लेने के लिए और इसे बंद में कर सकता है की एक आवृत्ति myclass।

— डोभाल

दृढ़ता से टाइप भाषाओं में, एक वर्ग एक प्रकार है। कमजोर प्रकार की भाषाओं में, यह एक प्रकार का हो सकता है या नहीं भी हो सकता है।

— शॉनहॉर्की

प्रोग्रामिंग भाषा सिद्धांत में, एक प्रकार मूल्यों का एक समूह है? मुझे लगता है कि आपको अपने आप को एक अन्य पुस्तक या अन्य शिक्षक या दोनों प्राप्त करने की आवश्यकता है। ए 'चर' या 'निरंतर' एक 'प्रकार' है और अक्सर एक 'मूल्य' है। वहाँ शून्य मान प्रकार, scalars और composit मूल्य प्रकार जहां चर या निरंतर का मूल्य उप चर / उप-स्थिरांक शामिल हैं।

— user1703394

@ user1703394 एक प्रकार मानों का एक समूह है। 32-बिट पूर्णांक प्रकार 2 ^ 32 अलग-अलग मानों का एक सेट है। यदि कोई अभिव्यक्ति उस प्रकार के मान का मूल्यांकन करती है, तो आप जानते हैं कि मान उस सेट में है। गणितीय ऑपरेटर है कि सेट के मूल्यों से अधिक सिर्फ कार्य हैं।

— डोभाल

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

— तेलस्तीन

Answer 1

न तो।

मैं इसे ले आग्रह कर रहे हैं कि क्या फ़ील्ड प्रकार के एक ही सेट होने एक ही कक्षा होने के रूप में वर्गीकृत करने के लिए पर्याप्त है, या कि क्या वे के साथ-साथ समान नाम किया जाना है। इसका उत्तर है: "समान प्रकार और समान नाम होने पर भी पर्याप्त नहीं है!" संरचनात्मक रूप से समतुल्य कक्षाएं आवश्यक रूप से संगत नहीं हैं।

उदाहरण के लिए, यदि आपके पास एक वर्ग CartesianCoordinatesऔर एक PolarCordinatesवर्ग है, तो वे दोनों अपने क्षेत्र के रूप में दो संख्याएँ हो सकते हैं, और उनके पास समान Numberप्रकार और समान नाम भी हो सकते हैं , लेकिन फिर भी वे संगत नहीं होंगे, और उदाहरण एक PolarCoordinatesनहीं होगा का उदाहरण CartesianCoordinates। अपने इच्छित उद्देश्य द्वारा प्रकारों को अलग करने की क्षमता और उनका वर्तमान कार्यान्वयन सुरक्षित लिखने का एक बहुत ही उपयोगी हिस्सा है, अधिक रखरखाव योग्य कोड।

Comments

यह ध्यान दिया जाना चाहिए कि कुछ भाषाओं में संरचनात्मक रूप से समतुल्य होना एक प्रकार को दूसरे का उपप्रकार बनाने के लिए पर्याप्त है (और अक्सर इसके विपरीत)। हालांकि यह निश्चित रूप से असामान्य / अलोकप्रिय है।

— तेलस्टिन

@ टाइप टाइपफ़ एक प्रकार का निर्माण नहीं करता है, यह एक मौजूदा प्रकार को संदर्भित करने के लिए उपयोग किए गए नाम को उपनाम देता है।

— डोभाल

@DevSolar उन्होंने स्पष्ट रूप से सी का उल्लेख किया है, और सी ++ के अलावा, मुझे उस कीवर्ड का उपयोग करने वाली किसी अन्य भाषा का पता नहीं है।

— डोभाल

@ टेलस्टाइन - उन भाषाओं को आग से मार दिया जाना चाहिए।

— जॉन स्टोरी

@JonStory स्ट्रक्चरल सबटाइपिंग एक मॉड्यूल स्तर पर उपयोगी है; इसकी कमी यह है कि क्या आप interfaceजावा और सी # में सब कुछ चालू करने के लिए मजबूर करते हैं यदि आप कभी यूनिट परीक्षण करना चाहते हैं। आप अंत में बॉयलरप्लेट का एक टन लिखना समाप्त करते हैं, ताकि आप उस विशेष वर्ग को बदल सकें जिसका उपयोग आपका कार्यक्रम करेगा, भले ही आपके पास इसे रनटाइम में बदलने का कोई इरादा न हो।

— डोभाल

Answer 2

प्रकार सेट नहीं हैं।

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

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

वास्तव में, यह कहना कि आप "सबस्ट्रेट" बना सकते हैं, कुछ हद तक निराशाजनक है, क्योंकि सेट पूरी तरह से एक अलग तरह का जानवर है। सेट सिद्धांत में, उन सबसेट पहले से मौजूद हैं , सभी अनंत तरीकों से आप उन्हें परिभाषित कर सकते हैं। प्रकार सिद्धांत रूप में, हम आम तौर पर किसी भी समय पर एक परिमित (यदि बड़े) प्रकारों की संख्या के साथ काम होने की उम्मीद। केवल प्रकारों के बारे में कहा जाता है कि वे वास्तव में परिभाषित किए गए हैं, न कि हर प्रकार जिन्हें हम संभवतः परिभाषित कर सकते हैं।

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

सेट को आमतौर पर एक दूसरे में समाहित किए बिना ओवरलैप करने की अनुमति होती है। यह प्रकार के सिद्धांत में असामान्य है, हालांकि कुछ भाषाएं इसे कई विरासत के रूप में समर्थन करती हैं। अन्य भाषाएँ, जैसे कि जावा, केवल इस के प्रतिबंधित रूप की अनुमति देती हैं या इसे पूरी तरह से अस्वीकृत कर देती हैं।

खाली प्रकार मौजूद है (इसे नीचे का प्रकार कहा जाता है ), लेकिन अधिकांश भाषाएं इसका समर्थन नहीं करती हैं, या इसे प्रथम श्रेणी के प्रकार के रूप में नहीं मानती हैं। "प्रकार जिसमें अन्य सभी प्रकार शामिल हैं" भी मौजूद है (इसे शीर्ष प्रकार कहा जाता है ) और व्यापक रूप से समर्थित है, सेट सिद्धांत के विपरीत।

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

---

"सबटाइपिंग" की धारणा वास्तव में "सब्सेट" की धारणा से काफी अलग है। अगर Xकी एक उप-प्रकार है Y, इसका मतलब है कि हम कर सकते हैं विकल्प के उदाहरण Yके उदाहरण के लिए Xऔर कार्यक्रम अभी भी होगा "काम" कुछ अर्थों में। यह संरचनात्मक के बजाय व्यवहारिक है, हालांकि कुछ भाषाओं (जैसे गो, जंग, यकीनन सी) ने उत्तरार्द्ध को सुविधा के कारणों के लिए चुना है, या तो प्रोग्रामर या भाषा कार्यान्वयन के लिए।

Comments

टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।

— वर्ल्ड इंजीनियर

Answer 3

बीजगणितीय डेटा प्रकार इस पर चर्चा करने का तरीका है।

तीन मूलभूत तरीके हैं जिनसे आप प्रकार जोड़ सकते हैं:

• उत्पाद। मूल रूप से आप यही सोच रहे हैं:

  struct IntXDouble{
    int a; 
    double b;
  }
  

  एक उत्पाद प्रकार है; इसके मूल्य एक intऔर एक के सभी संभव संयोजन (यानी टुपल्स) हैं double। यदि आप संख्या प्रकारों को सेट के रूप में मानते हैं, तो उत्पाद प्रकार की कार्डिनिटी वास्तव में खेतों की कार्डिनैलिटी का उत्पाद है।

• योग। प्रक्रियात्मक भाषाओं में यह सीधे व्यक्त करने के लिए थोड़ा अजीब है (शास्त्रीय रूप से यह टैग किए गए यूनियनों के साथ किया जाता है ), इसलिए बेहतर समझ के लिए, यहां हास्केल में एक योग प्रकार है:

  data IntOrDouble = AnInt Int
                   | ADouble Double
  

  इस प्रकार के मूल्यों में या तो रूप है AnInt 345, या है ADouble 4.23, लेकिन इसमें हमेशा एक ही नंबर शामिल होता है (उत्पाद प्रकार के विपरीत, जहां प्रत्येक मान में दो नंबर होते हैं)। तो कार्डिनैलिटी: आप पहले सभी Intमूल्यों को मानते हैं, प्रत्येक को AnIntकंस्ट्रक्टर के साथ जोड़ा जाना चाहिए । इसके अलावा , सभी Doubleमूल्यों, प्रत्येक के साथ संयुक्त ADouble। इसलिए राशि टाइप करें ।

• प्रतिपादक ^१ । मैं इस पर विस्तार से चर्चा नहीं करूंगा क्योंकि इसमें कोई स्पष्ट OO पत्राचार नहीं है।

तो कक्षाओं के बारे में क्या? मैं जानबूझ कर कीवर्ड का इस्तेमाल किया structबजाय classके लिए IntXDouble। बात यह है कि, एक वर्ग के रूप में एक वर्ग वास्तव में अपने क्षेत्रों की विशेषता नहीं है, वे केवल कार्यान्वयन विवरण हैं। बल्कि महत्वपूर्ण कारक यह है कि वर्ग के लिए अलग-अलग मूल्य क्या हो सकते हैं।

क्या है प्रासंगिक है, हालांकि, एक वर्ग का मान हो सकता है के मूल्यों किसी भी यह उपवर्गों की ! तो एक वर्ग वास्तव में एक योग प्रकार के बजाय एक उत्पाद के प्रकार है: अगर Aऔर Bदोनों से प्राप्त की जाएगी myClass, myClassअनिवार्य रूप से की राशि होगी Aऔर B। वास्तविक कार्यान्वयन के बावजूद।

---

¹ _{यह कार्य है ( गणितीय अर्थ में! ); एक फ़ंक्शन प्रकार Int -> Doubleघातीय द्वारा दर्शाया गया है Double^Int। बुरा करने के लिए अगर आपकी भाषा में उचित कार्य नहीं हैं ...}

Comments

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

— बरबाद

@ruakh: नहीं। आप निश्चित रूप से OO में फ़ंक्शंस लागू कर सकते हैं, लेकिन सामान्य तौर पर, तरीके फ़ंक्शंस नहीं हैं ( क्योंकि वे राज्य आदि को संशोधित करते हैं)। और न ही प्रक्रियात्मक भाषा के कार्यों में "कार्य" हैं, इस बात के लिए। दरअसल, एक स्थैतिक-विधि इंटरफेस समारोह / घातीय-प्रकार के सबसे करीब आते हैं, लेकिन मुझे लगता है, क्योंकि यह इस प्रश्न के लिए कोई प्रासंगिकता है कि की चर्चा से बचने के लिए आशा व्यक्त की।

— लेफ्टरनैबाउट

... और अधिक महत्वपूर्ण बात, मेरे anwer करता व्यवहार पर विचार करें। वास्तव में व्यवहार आमतौर पर यही कारण है कि आप वंशानुक्रम का उपयोग करते हैं, और विभिन्न संभावित व्यवहारों का एकीकरण OO वर्गों के योग-प्रकार पहलू को सटीक रूप से कैप्चर करता है।

— लेफ्टरनैबाउट

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

— डोभाल

@ डोवल 1) आप AFAIK के आसपास तरीके पारित कर सकते हैं, इसलिए वे प्रथम श्रेणी के मूल्य हैं; 2) यह समानता के लिए कार्यों की तुलना करने के लिए समझ में आता है, जेएस लोग इसे हर समय करते हैं।

— डेन

Answer 4

क्षमा करें, लेकिन मैं "कच्चे" सिद्धांत के बारे में नहीं जानता। मैं केवल एक व्यावहारिक दृष्टिकोण प्रदान कर सकता हूं। मुझे आशा है कि इस programmers.SE पर स्वीकार्य है; मैं यहाँ शिष्टाचार से परिचित नहीं हूँ।

---

OOP का एक केंद्रीय विषय सूचना छिपाना है । किसी वर्ग के डेटा सदस्य वास्तव में, उसके ग्राहकों के लिए कोई रुचि नहीं होनी चाहिए। एक ग्राहक एक उदाहरण के लिए (कॉल विधियों / सदस्य कार्यों को कॉल करता है) संदेश भेजता है , जो आंतरिक स्थिति को संशोधित या नहीं कर सकता है। विचार यह है कि एक वर्ग के आंतरिक परिवर्तन हो सकते हैं, इसके बिना ग्राहक इससे प्रभावित हो सकता है।

इसका एक कारण यह है कि यह सुनिश्चित करने के लिए वर्ग जिम्मेदार है कि इसका आंतरिक प्रतिनिधित्व "वैध" बना रहे। मान लें कि एक वर्ग जो दो पूर्णांकों में एक (सरलीकृत) फोन नंबर संग्रहीत करता है:

    int areacode;
    int number;

ये वर्ग के डेटा सदस्य हैं । हालांकि, वर्ग शायद हो जाएगा और अधिक सिर्फ अपने डेटा के सदस्यों की तुलना में, और यह निश्चित रूप से "के रूप में पूर्णांक एक्स पूर्णांक के सभी संभव मूल्यों का वह समूह" definable नहीं है। आपको डेटा सदस्यों तक सीधी पहुंच नहीं होनी चाहिए।

एक उदाहरण का निर्माण किसी भी नकारात्मक संख्या से इनकार कर सकता है। शायद निर्माण भी किसी तरह से क्षेत्रकोड सामान्य होता है, या यहां तक कि पूरी नंबर को सत्यापित। आप इस प्रकार अपने बहुत करीब खत्म हो जाएगा "(a,b) where a is an int and b is a double", क्योंकि यह निश्चित रूप से उस वर्ग में संग्रहीत कोई दो int नहीं है ।

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

जब तक वे विधियां समान रहती हैं, तो कार्यान्वयनकर्ता डेटा प्रकारों को फ़्लोटिंग पॉइंट, BIGNUMs, स्ट्रिंग्स, जो भी हो, और सभी व्यावहारिक उद्देश्यों के लिए बदल सकता है, यह अभी भी एक ही वर्ग होगा ।

---

यह सुनिश्चित करने के लिए डिज़ाइन पेटेंट हैं कि ग्राहक के बिना आंतरिक प्रतिनिधित्व के ऐसे परिवर्तन किए जा सकते हैं, यहां तक ​​कि इसके बारे में पता किए बिना (उदाहरण के लिए C ++ में pimpl मुहावरा, जो किसी भी डेटा सदस्यों को एक अपारदर्शी सूचक के पीछे छिपाता है )।

Comments

It is neither the type of the data members, nor the range of their possible values that defines the class, it's the methods that are defined for it.जब आप उन्हें छिपाते हैं तो डेटा सदस्य केवल एक वर्ग को परिभाषित नहीं करते हैं। यह सबसे आम मामला हो सकता है, लेकिन यह निश्चित रूप से नहीं कहा जा सकता है कि यह सभी वर्गों के लिए सच है। अगर एक भी क्षेत्र सार्वजनिक है, तो यह उसके तरीकों जितना ही महत्वपूर्ण है।

— डोभाल

जब तक आप जावा में कोडिंग नहीं कर रहे हैं, जहां आपके पास मामले में कोई विकल्प नहीं है और यहां तक ​​कि आपका गूंगा नो-व्यवहार faux- रिकॉर्ड भी होना चाहिए class। (उन्हें चिह्नित करने finalसे बिंदु को पार पाने में मदद मिलती है, लेकिन फिर भी)। आपको अभी भी protectedसदस्यों के साथ एक समस्या है , जो विरासत में मिली है और इस प्रकार उपवर्गों के कार्यान्वयन के लिए एक दूसरे एपीआई का हिस्सा बन सकता है।

— डोभाल

@ डोभाल: मैंने इसे एक "सिद्धांत" प्रश्न समझा, यही कारण है कि मैं यथासंभव वास्तविक भाषा के मुद्दों से दूर रहा। (जैसे मैं जावा के स्पष्ट protectedरूप में और अभ्यास में संभव के रूप में रहना ; ;-))

— DevSolar

समस्या यह है कि classएक भाषा पर निर्भर निर्माण है। जहाँ तक मुझे पता है कि classटाइप थ्योरी में ऐसा कुछ नहीं है।

— डोभाल

@ डोभाल: इसका मतलब यह नहीं होगा कि प्रति वर्ग प्रकार सिद्धांत कक्षाओं पर लागू नहीं होता, क्योंकि वे उस सिद्धांत के दायरे से बाहर एक निर्माण हैं?

— DevSolar

Answer 5

• एक प्रकार एक श्रेणी / मानों की श्रेणी, यौगिक संरचनाओं, या आपके पास क्या है का विवरण है। OOPwise, यह एक "इंटरफ़ेस" के समान है। (भाषा-अज्ञेय अर्थ में। भाषा-विशिष्ट अर्थ, इतना अधिक नहीं। उदाहरण के लिए, जावा intएक प्रकार है , लेकिन इसका interfaceसार्वजनिक / संरक्षित क्षेत्र विनिर्देशों से कोई संबंध नहीं है , साथ ही, का हिस्सा नहीं हैं interface। लेकिन एक "इंटरफ़ेस" या प्रकार का हिस्सा हैं ।)

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

• एक वर्ग एक प्रकार का बोध है। यह एक टेम्पलेट है जो वास्तव में आंतरिक संरचना, संलग्न व्यवहार आदि को परिभाषित करता है।