सार डेटा प्रकार और वस्तुओं के बीच अंतर क्या है?


11

प्रोग्रामर्स पर एक उत्तर। कुक के अनुसार निबंध का वर्णन करता है ( ऑब्जेक्ट एडीटी नहीं हैं )

  • वस्तुएं एक बीजगणित के बजाय एक प्रकार के मूल्यों पर एक विशिष्ट कार्य की तरह व्यवहार करती हैं। ऑब्जेक्ट अमूर्त प्रकार के बजाय प्रक्रियात्मक अमूर्तता का उपयोग करते हैं

  • ADTs आमतौर पर एक कार्यक्रम में एक अद्वितीय कार्यान्वयन है। जब किसी की भाषा में मॉड्यूल होते हैं, तो एडीटी के कई कार्यान्वयन होना संभव है, लेकिन वे आमतौर पर बीच में नहीं आते हैं।

यह मुझे लगता है कि, कुक के निबंध में, यह सिर्फ ऐसा होता है कि कुक के पेपर में इस्तेमाल किए गए सेट के विशिष्ट उदाहरण के लिए, एक ऑब्जेक्ट को एक विशेषता फ़ंक्शन के रूप में देखा जा सकता है । मुझे नहीं लगता कि वस्तुओं को सामान्य तौर पर विशेषता कार्यों के रूप में देखा जा सकता है।

इसके अलावा, एल्ड्रिच का पेपर इंटरऑपरेबिलिटी की शक्ति: ऑब्जेक्ट अपरिहार्य क्यों हैं's सुझाव देते हैं

कुक की परिभाषा अनिवार्य रूप से गतिशील प्रेषण को ऑब्जेक्ट की सबसे महत्वपूर्ण विशेषता के रूप में पहचानती है

इस बात से सहमत और एलन काय के साथ जब उन्होंने कहा

ओओपी टू का मतलब केवल मैसेजिंग, लोकल रिटेंशन और प्रोटेक्शन और स्टेट-प्रोसेस को छुपाना, और सभी चीजों की एक्सट्रीम लेट-बाइंडिंग है।

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

मेरे सवाल हैं

  1. क्या मैं यह कहना सही हूं कि विशेषता कार्य वस्तुओं की प्रमुख विशेषता नहीं है और फ्रैंक शीयर गलत है?

  2. डेटा है कि जावा के माध्यम से एक दूसरे से बात करते हैं वस्तुओं के उदाहरण इंटरफेस भले ही वे गतिशील प्रेषण का उपयोग नहीं करते हैं? क्यों? (मेरी समझ यह है कि डायनेमिक प्रेषण अधिक लचीला है, और यह कि इंटरफेस ऑब्जेक्टिव- C / smalltalk / erlang स्टाइल मैसेजिंग की ओर एक कदम है।)

  3. क्या एडीटी और वस्तुओं के बीच अंतर से संबंधित निर्भरता व्युत्क्रम सिद्धांत का विचार है? ( विकिपीडिया पृष्ठ या द टॉकिंग ऑब्जेक्ट्स: मैसेज-ओरिएंटेड प्रोग्रामिंग के बारे में एक कहानी देखें ) हालांकि मैं अवधारणा के लिए नया हूं, मैं समझता हूं कि इसमें एक प्रोग्राम के "लेयर्स" के बीच इंटरफेस को जोड़ना शामिल है (विकिपीडिया पेज आरेख देखें)।

  4. यदि आप चाहते हैं कि वस्तुओं और ADTs के बीच अंतर के अन्य उदाहरण / स्पष्टीकरण प्रदान करें।

And यह पेपर (2013 में प्रकाशित) जावा में उदाहरणों के साथ कुक के 2009 के पेपर को पढ़ना आसान है और सारांशित करता है। मैं इस सवाल का जवाब देने के लिए नहीं, बल्कि कम से कम इसे बढ़ाने की सलाह देता हूं, लेकिन सिर्फ इसलिए कि यह एक अच्छा पेपर है।


5
दिलचस्प है, लेकिन कृपया प्रति पोस्ट एक प्रश्न के लिए खुद को प्रतिबंधित करने का प्रयास करें।
राफेल

यह कुछ हद तक एक (सूक्ष्म?) शैक्षिक भेद / बहस लगता है। जाहिरा तौर पर ADTs जावा और अन्य आधुनिक ओओपी भाषाओं में लगभग ऑब्जेक्ट हैं। कई ओओपी भाषाओं में, अमूर्त को उस तरीके के रूप में माना जाता है जो ऑब्जेक्ट मॉडल (एक विवश / केंद्रित तरीके से) वास्तविक दुनिया में होता है। OOP , सॉफ्टवेयर इंजीनियरिंग
vzn

जवाबों:


8

Google ने एक ऐसे प्रश्न का उत्तर दिया, जो मुझे लगता है कि बहुत अच्छा है। मैंने इसे नीचे उद्धृत किया है।

यहाँ एक और अंतर है जो कि मेरे द्वारा जुड़े कुक निबंध में बताया गया है।

अमूर्तता को लागू करने के लिए ऑब्जेक्ट एकमात्र तरीका नहीं है। सब कुछ एक वस्तु नहीं है। ऑब्जेक्ट कुछ को लागू करते हैं, जिसे कुछ लोग प्रक्रियात्मक डेटा को अमूर्त कहते हैं। अमूर्त डेटा प्रकार अमूर्त के एक अलग रूप को लागू करते हैं।

जब आप द्विआधारी विधियों / कार्यों पर विचार करते हैं तो एक महत्वपूर्ण अंतर प्रकट होता है। प्रक्रियात्मक डेटा अमूर्त (ऑब्जेक्ट्स) के साथ, आप इंट सेट इंटरफ़ेस के लिए कुछ इस तरह लिख सकते हैं:

interface IntSet {
  void unionWith(IntSet s);
  ...
}

अब इंसेट के दो कार्यान्वयन पर विचार करें, एक को सूचियों द्वारा समर्थित और एक जो एक अधिक कुशल बाइनरी ट्री संरचना द्वारा समर्थित है:

class ListIntSet implements IntSet {
  void unionWith(IntSet s){ ... }
} 
class BSTIntSet implements IntSet {
  void unionWith(IntSet s){ ... }
}

ध्यान दें कि UnionWith को एक IntSet तर्क लेना चाहिए। ListIntSet या BSTIntSet जैसे अधिक विशिष्ट प्रकार नहीं। इसका मतलब यह है कि BSTIntSet कार्यान्वयन यह नहीं मान सकता है कि इसका इनपुट BSTIntSet है और एक कुशल कार्यान्वयन देने के लिए उस तथ्य का उपयोग करें। (यह जाँच करने के लिए कुछ रन टाइम टाइप की जानकारी का उपयोग कर सकता है और यदि यह है तो अधिक कुशल एल्गोरिदम का उपयोग कर सकता है, लेकिन इसे अभी भी एक ListIntSet पास किया जा सकता है और कम कुशल एल्गोरिदम में वापस आना होगा)।

इसकी तुलना ADTs से करें, जहाँ आप हस्ताक्षर या हेडर फ़ाइल में निम्नलिखित जैसे कुछ और लिख सकते हैं:

typedef struct IntSetStruct *IntSetType;
void union(IntSetType s1, IntSetType s2);

हम इस इंटरफ़ेस के खिलाफ प्रोग्राम करते हैं। विशेष रूप से, प्रकार सार छोड़ दिया गया है। आपको पता नहीं है कि यह क्या है। फिर हमारे पास एक BST कार्यान्वयन है, फिर एक ठोस प्रकार और संचालन प्रदान करता है:

struct IntSetStruct {
 int value;
 struct IntSetStruct* left;
 struct IntSetStruct* right;
}

void union(IntSetType s1, IntSetType s2){ ... }

अब संघ वास्तव में s1 और s2 दोनों के ठोस प्रतिनिधित्व को जानता है, इसलिए यह एक कुशल कार्यान्वयन के लिए इसका फायदा उठा सकता है। हम एक सूची समर्थित कार्यान्वयन भी लिख सकते हैं और इसके बजाय लिंक करना चुन सकते हैं।

मैंने C (ish) सिंटैक्स लिखा है, लेकिन आपको यह देखना चाहिए कि अमूर्त डेटा प्रकारों के लिए Standard ML ठीक प्रकार से किया गया है (जहाँ आप उदाहरण के लिए एक प्रोग्राम में ADT के एक से अधिक कार्यान्वयन का उपयोग कर सकते हैं। IntSetStruct और ListImpl.IntSetStruct, कहते हैं)

इसका संकेत यह है कि प्रक्रियात्मक डेटा अमूर्त (ऑब्जेक्ट्स) आपको आसानी से नए कार्यान्वयन लागू करने की अनुमति देता है जो आपके पुराने लोगों के साथ काम करते हैं। उदाहरण के लिए, आप अपने स्वयं के कस्टम LoggingIntSet कार्यान्वयन को लिख सकते हैं, और इसे BSTIntSet के साथ जोड़ सकते हैं। लेकिन यह एक व्यापार है: आप द्विआधारी तरीकों के लिए जानकारीपूर्ण प्रकार खो देते हैं! अक्सर आप एक ADT कार्यान्वयन के साथ अपने इंटरफ़ेस में अधिक कार्यक्षमता और कार्यान्वयन विवरणों को उजागर करने के लिए समाप्त होते हैं। अब मुझे ऐसा लग रहा है कि मैं सिर्फ कुक निबंध को पुनः लिख रहा हूँ, इसलिए वास्तव में, इसे पढ़ें!

मैं इसका एक उदाहरण जोड़ना चाहूंगा।

कुक सुझाव देते हैं कि अमूर्त डेटा प्रकार का एक उदाहरण सी में एक मॉड्यूल है। सी में मॉड्यूल, जानकारी को छिपाने में शामिल हैं, क्योंकि सार्वजनिक कार्य हैं जो हेडर फ़ाइल के माध्यम से निर्यात किए जाते हैं, और स्थिर (निजी) फ़ंक्शन नहीं होते हैं। इसके अतिरिक्त, अक्सर कंस्ट्रक्टर होते हैं (जैसे list_new ()) और ऑब्जर्वर (जैसे list_getListHead ())।

ADT क्या बनाता है, कहते हैं, एक सूची मॉड्यूल जिसे LIST_MODULE_SINGLY_LINK ने ADT कहा है, मॉड्यूल के कार्य (जैसे list_getListHead ()) यह मानते हैं कि इनपुट किया जा रहा डेटा LIST_MODULE_SINGLY_LINKED के निर्माता द्वारा बनाया गया है, किसी भी समतुल्य के विपरीत। "एक सूची का कार्यान्वयन (जैसे LIST_MODULE_DYNAMIC_ARRAY)। इसका अर्थ है कि LIST_MODULE_SINGLY_LINKED के कार्य, उनके कार्यान्वयन में, एक विशेष प्रतिनिधित्व (जैसे एक एकल लिंक की गई सूची) मान सकते हैं।

LIST_MODULE_SINGLY_LINKED LIST_MODULE_DYNAMIC_ARRAY के साथ काम नहीं कर सकता क्योंकि हम बनाए गए डेटा को फ़ीड नहीं कर सकते, LIST_MODULE_AMODIC_ARRAY के लिए पर्यवेक्षक के रूप में LIST_MODULE_DYNAMIC_ARRAY के साथ काम नहीं कर सकते, क्योंकि यह LIST_MODULE_DYNAMIC_ARRAY के कारण नहीं है।

यह एक तरह से अनुरूप है कि अमूर्त बीजगणित से दो अलग-अलग समूह आपस में जुड़ नहीं सकते हैं (अर्थात, आप एक समूह के एक तत्व के उत्पाद को दूसरे समूह के तत्व के साथ नहीं ले सकते हैं)। ऐसा इसलिए है क्योंकि समूह समूह की बंद संपत्ति मानते हैं (समूह में तत्वों का उत्पाद समूह में होना चाहिए)। हालांकि, अगर हम यह साबित कर सकते हैं कि दो अलग-अलग समूह वास्तव में दूसरे समूह G के उपसमूहों में हैं, तो हम G के उत्पाद का उपयोग दो तत्वों में से एक, दो समूहों में से एक को जोड़ने के लिए कर सकते हैं।

एडीटी और वस्तुओं की तुलना करना

  • कुक ADTs और ऑब्जेक्ट्स के बीच अंतर को आंशिक रूप से अभिव्यक्ति समस्या के रूप में रखता है। मोटे तौर पर, एडीटी सामान्य कार्यों के साथ युग्मित होते हैं जो अक्सर कार्यात्मक प्रोग्रामिंग भाषाओं में लागू होते हैं, जबकि ऑब्जेक्ट्स को इंटरफेस के माध्यम से एक्सेस किए गए जावा "ऑब्जेक्ट्स" के साथ युग्मित किया जाता है। इस पाठ के प्रयोजनों के लिए, एक सामान्य कार्य एक फ़ंक्शन है जो कुछ तर्क ARGS और एक प्रकार TYPE (पूर्व-स्थिति) में लेता है; TYPE के आधार पर यह उपयुक्त फ़ंक्शन का चयन करता है, और ARGS (पोस्ट-कंडीशन) के साथ इसका मूल्यांकन करता है। जेनेरिक फ़ंक्शंस और ऑब्जेक्ट दोनों बहुरूपता को लागू करते हैं, लेकिन जेनेरिक फ़ंक्शंस के साथ, प्रोग्रामर KNOWS जो जेनेरिक फ़ंक्शन के कोड को देखे बिना जेनेरिक फ़ंक्शन द्वारा निष्पादित किया जाएगा। दूसरी ओर वस्तुओं के साथ, प्रोग्रामर को यह नहीं पता होता है कि ऑब्जेक्ट कैसे तर्कों को हैंडल करेगा, जब तक कि प्रोग्रामर ऑब्जेक्ट के कोड को नहीं देखता है।

  • आमतौर पर अभिव्यक्ति की समस्या के बारे में सोचा जाता है "क्या मेरे पास बहुत सारे प्रतिनिधित्व हैं?" बनाम "क्या मुझे कुछ प्रतिनिधित्व के साथ बहुत सारे कार्य हैं"। पहले मामले में किसी को प्रतिनिधित्व द्वारा कोड व्यवस्थित करना चाहिए (जैसा कि सबसे आम है, खासकर जावा में)। दूसरे मामले में एक को फ़ंक्शन द्वारा कोड व्यवस्थित करना चाहिए (यानी एक एकल सामान्य फ़ंक्शन को कई अभ्यावेदन संभालना)।

  • यदि आप अपने कोड को प्रतिनिधित्व द्वारा व्यवस्थित करते हैं, तो, यदि आप अतिरिक्त कार्यक्षमता जोड़ना चाहते हैं, तो आपको ऑब्जेक्ट के प्रत्येक प्रतिनिधित्व के लिए कार्यक्षमता जोड़ने के लिए मजबूर किया जाता है; इस अर्थ में कार्यक्षमता जोड़ना "योगात्मक" नहीं है। यदि आप कार्यक्षमता द्वारा अपना कोड व्यवस्थित करते हैं, तो, यदि आप एक अतिरिक्त प्रतिनिधित्व जोड़ना चाहते हैं - तो आपको प्रत्येक ऑब्जेक्ट में प्रतिनिधित्व जोड़ने के लिए मजबूर किया जाता है; इस अर्थ में "योगात्मक" नहीं है।

वस्तुओं पर ADTs का लाभ

  • कार्यक्षमता जोड़ना योगात्मक है

  • प्रदर्शन के लिए एक एडीटी के प्रतिनिधित्व के ज्ञान का लाभ उठाने के लिए संभव है, या यह साबित करने के लिए कि एडीटी एक पूर्व शर्त दिए गए कुछ पोस्टकंडिशन की गारंटी देगा। इसका मतलब यह है कि एडीटी के साथ प्रोग्रामिंग सही क्रम में सही काम करने के बारे में है ("लक्ष्य" पोस्ट की स्थिति के लिए पूर्व-शर्तों और पोस्ट-शर्तों को एक साथ जोड़ते हुए)।

ADTs पर वस्तुओं का लाभ

  • Additive में अभ्यावेदन जोड़ना

  • वस्तुएं आपस में जुड़ सकती हैं

  • किसी ऑब्जेक्ट के लिए पूर्व / पोस्ट की शर्तों को निर्दिष्ट करना संभव है, और इनको एक साथ मिलाएं जैसा कि ADTs के साथ होता है। इस स्थिति में, वस्तुओं के फायदे यह हैं कि (1) इंटरफ़ेस को बदलने के बिना अभ्यावेदन को बदलना आसान है और (2) ऑब्जेक्ट अंतर-ऑपरेट कर सकते हैं। हालाँकि, यह OOP के उद्देश्य को स्मालटाक के अर्थ में पराजित करता है। (देखें अनुभाग "एलन के के OOP का संस्करण)

डायनेमिक प्रेषण OOP की कुंजी है

अब यह स्पष्ट होना चाहिए कि वस्तु उन्मुख प्रोग्रामिंग के लिए डायनामिक डिस्पैच (यानी देर से बाध्यकारी) आवश्यक है। ऐसा इसलिए है कि प्रक्रियाओं को एक सामान्य तरीके से परिभाषित करना संभव है, जो किसी विशेष प्रतिनिधित्व को ग्रहण नहीं करता है। ठोस होने के लिए - ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग अजगर में आसान है, क्योंकि किसी ऑब्जेक्ट के तरीकों को इस तरह से प्रोग्राम करना संभव है जो किसी विशेष प्रतिनिधित्व को ग्रहण नहीं करता है। यही कारण है कि अजगर को जावा जैसे इंटरफेस की आवश्यकता नहीं है।

जावा में, कक्षाएं एडीटी हैं। हालाँकि, इंटरफ़ेस के माध्यम से एक वर्ग जिस पर लागू होता है वह एक वस्तु है।

परिशिष्ट: एलन Kay OOP का संस्करण

एलन के ने स्पष्ट रूप से वस्तुओं को "बीजगणित के परिवार" के रूप में संदर्भित किया है, और कुक का सुझाव है कि एक एडीटी एक बीजगणित है। इसलिए Kay का अर्थ है कि एक वस्तु ADTs का एक परिवार है। यही है, एक ऑब्जेक्ट सभी वर्गों का संग्रह है जो एक जावा इंटरफ़ेस को संतुष्ट करता है।

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

संक्षेप में, Kay के लिए वस्तुओं का मुख्य विचार - यह नहीं है कि वे बीजगणित के परिवार हैं (जैसा कि कुक द्वारा जोर दिया गया है)। बल्कि, Kay का मुख्य विचार एक मॉडल लागू करना था जो बड़े (एक नेटवर्क में कंप्यूटर) में छोटे (एक प्रोग्राम में ऑब्जेक्ट) में काम करता था।

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

संपादित करें: मुझे एलन कय की OOP की परिभाषा का एक बहुत अच्छा प्रदर्शन यहां मिला


3

यदि आप ADT समर्थकों को देखते हैं, तो वे ADT को एक ऐसा वर्ग मानते हैं जिसे OOP एक वर्ग (आंतरिक, निजी राज्य; संचालन का एक सीमित सेट) की संज्ञा देगा, लेकिन वर्गों के बीच कोई संबंध नहीं (कोई विरासत, मूल रूप से) माना जाता है। इसके बजाय कहा जा रहा है कि एक ही व्यवहार को विभिन्न कार्यान्वयनों के साथ प्राप्त किया जा सकता है। उदाहरण के लिए एक सेट को एक सूची के रूप में लागू किया जा सकता है, किसी सरणी या हैशटेबल में तत्व, या किसी प्रकार का पेड़।


2

मैंने हमेशा इसे इस तरह समझा:

  1. एक एडीटी एक इंटरफ़ेस है: यह सिर्फ तरीकों का एक संग्रह है, उनके प्रकार-हस्ताक्षर, संभवतः पूर्व और बाद की स्थितियों के साथ।

  2. एक वर्ग कर सकते हैं लागू तरीकों एडीटी में निर्दिष्ट के लिए वास्तविक कार्यान्वयन देकर एक या अधिक ADTS,।

  3. एक वस्तु एक वर्ग का एक उदाहरण है, जिसमें किसी भी गैर-स्थिर चर की अपनी प्रति है।

यह संभव है कि साहित्य में, भेद अलग हों, लेकिन यह "मानक" शब्दावली है जिसे आप कंप्यूटर विज्ञान में सुनेंगे।

उदाहरण के लिए, जावा में, Collectionएक एडीटी है, ArrayListएक वर्ग है, और आप ऑपरेटर के ArrayListसाथ एक वस्तु बना सकते हैं new

इस कथन के लिए कि ADT में आमतौर पर केवल एक ही कार्यान्वयन होता है, यह अक्सर ऐसा नहीं होता है। उदाहरण के लिए, यह संभव है कि आप अपने प्रोग्राम में ट्री-बेस्ड और हैशटेबल-आधारित शब्दकोशों दोनों का उपयोग करना चाहते हैं, यह इस बात पर निर्भर करता है कि आप क्या स्टोर कर रहे हैं। वे एक एडीटी साझा करेंगे, लेकिन विभिन्न कार्यान्वयन का उपयोग करेंगे।


1
एक कार्यात्मक-प्रोग्रामिंग दृष्टिकोण से, ADTs के पास कुछ प्रतिबंध नहीं हैं जो सामान्य रूप से वर्ग नहीं हैं?
राफेल

@ राफेल क्या पसंद है?
jmite

1
यह ADT का एक सामान्य दृश्य है, और यह एक उचित अनुमान है। हालाँकि, जैसा कि मैं इसे समझता हूं, एडीटी को पीएल साहित्य में माना जाता है और औपचारिक रूप से परिभाषित के रूप में वास्तव में कुछ अधिक विशिष्ट अर्थ है। एक एडीटी एक प्रकार की डेटा संरचना का एक विनिर्देश है: न कि यह कैसे लागू किया जाता है या डेटा का प्रतिनिधित्व कैसे किया जाता है, लेकिन इसके लिए इंटरफ़ेस (किस प्रकार के संचालन किए जा सकते हैं?) और उन प्रत्येक कार्यों के व्यवहार / शब्दार्थ। तो यह सिर्फ एक जावा इंटरफ़ेस (प्रकार-हस्ताक्षर वाले तरीकों की एक सूची) नहीं है, बल्कि उनके व्यवहार का एक विनिर्देश भी है।
डीडब्ल्यू

1
उदाहरण के लिए, मेरी धारणा यह है कि जावा Collectionइंटरफ़ेस ADT नहीं है। यह विधियों की एक सूची प्रदान करता है, लेकिन उनके शब्दार्थ निर्दिष्ट नहीं करता है। क्या यह एक सेट के शब्दार्थ प्रदान करता है? एक मल्टीसेट (बैग)? एक आदेश सूची? यह अनिर्दिष्ट है। इसलिए मुझे यकीन नहीं है कि यह एक एडीटी के रूप में गिना जाता है। यही कारण है कि मेरी धारणा है, लेकिन यह मेरी समझ गलत हो सकता है कि पूरी तरह से संभव है ...
DW

व्याख्यान स्लाइड्स में मैं एक जावा क्लास से जुड़ा हुआ था (एक इंटरफ़ेस भी नहीं!) एक एडीटी माना जाता है, क्योंकि एक वर्ग में दोनों निजी और सार्वजनिक भाग होते हैं (मुझे लगता है कि वर्ग का हिस्सा अनौपचारिक रूप से निर्दिष्ट होगा लेकिन मुझे यकीन नहीं है) । दूसरी ओर, एक इंटरफ़ेस के माध्यम से एक्सेस की जाने वाली एक क्लास को एक वस्तु माना जाता है, जिसमें इंटरफ़ेस द्वारा परिभाषित तरीके "संदेश" (उच्च स्तर के इरादे) हैं। जब ऑब्जेक्ट एक-दूसरे से इरादों के माध्यम से बात करते हैं, तो ऑब्जेक्ट के विभिन्न कार्यान्वयन एक-दूसरे से "बात" कर सकते हैं।
LMZ
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.