OOP से पहले, क्या डेटा संरचना सदस्य सार्वजनिक थे?

Question

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

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

Comments

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

— 8bittree

@ 8bittree ने जो कहा, उस पर एक अलग स्पिन डालने के लिए, सब कुछ सार्वजनिक होना ठीक है यदि आपके कोड का उपयोग करने वाले लोग आपके द्वारा निर्धारित इंटरफ़ेस से चिपके रहने के लिए पर्याप्त अनुशासित हैं। निजी सदस्य निर्माण के बारे में उन लोगों की वजह से आया जो अपनी नाक नहीं रख सकते जहां वे नहीं हैं।

— ब्लरफुल

क्या आपका मतलब था "एनकैप्सुलेशन लोकप्रिय होने से पहले"? OO भाषाओं के लोकप्रिय होने से पहले एनकैप्सुलेशन काफी लोकप्रिय था।

— फ्रैंक हिलमैन

@FrankHileman मुझे लगता है कि वास्तव में इस सवाल का मूल है: ओपी यह जानना चाहता है कि क्या

— सिम्पुला

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

— जेरेड स्मिथ

Answer 1

ओओपी ने एनकैप्सुलेशन का आविष्कार नहीं किया और एनकैप्सुलेशन का पर्याय नहीं है। कई ओओपी भाषाओं में सी ++ / जावा शैली का उपयोग संशोधक नहीं है। कई गैर-ओओपी भाषाओं में एनकैप्सुलेशन की पेशकश करने के लिए विभिन्न तकनीकें उपलब्ध हैं।

एन्कैप्सुलेशन के लिए एक क्लासिक दृष्टिकोण क्लोजर है , जैसा कि कार्यात्मक प्रोग्रामिंग में उपयोग किया जाता है । यह OOP से काफी पुराना है लेकिन एक तरह से समतुल्य है। उदाहरण के लिए जावास्क्रिप्ट में हम इस तरह एक वस्तु बना सकते हैं:

function Adder(x) {
  this.add = function add(y) {
    return x + y;
  }
}

var plus2 = new Adder(2);
plus2.add(7);  //=> 9

उपरोक्त plus2वस्तु का कोई सदस्य नहीं है जो इसे सीधे पहुंच की अनुमति देगा x- यह पूरी तरह से समझाया गया है। add()विधि पर एक बंद है xचर।

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

#ifndef ADDER_H
#define ADDER_H

typedef struct AdderImpl *Adder;

Adder Adder_new(int x);
void Adder_free(Adder self);
int Adder_add(Adder self, int y);

#endif

अब हम इस कोड को लिख सकते हैं जो इस Adder इंटरफ़ेस का उपयोग करता है, बिना इसके क्षेत्रों तक पहुँच के, जैसे:

Adder plus2 = Adder_new(2);
if (!plus2) abort();
printf("%d\n", Adder_add(plus2, 7));  /* => 9 */
Adder_free(plus2);

और यहां पूरी तरह से समझाया गया कार्यान्वयन विवरण होगा:

#include "adder.h"

struct AdderImpl { int x; };

Adder Adder_new(int x) {
  Adder self = malloc(sizeof *self);
  if (!self) return NULL;
  self->x = x;
  return self;
}

void Adder_free(Adder self) {
  free(self);
}

int Adder_add(Adder self, int y) {
  return self->x + y;
}

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

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

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

Comments

में त्रुटि देखें Adder self = malloc(sizeof(Adder));? वहाँ एक कारण typedef- आईएनजी संकेत है और sizeof(TYPE)आमतौर पर पर frowned है।

— डेडुप्लिकेटर

आप सिर्फ लिख नहीं सकते sizeof(*Adder), क्योंकि *Adderएक प्रकार नहीं है, *int *जैसा कि एक प्रकार नहीं है। अभिव्यक्ति T t = malloc(sizeof *t)मुहावरेदार और सही दोनों है। मेरा संपादन देखें।

— मार्च 1941

पास्कल के पास इकाई चर थे जो उस इकाई के बाहर से नहीं देखे जा सकते थे। प्रभावी रूप से यूनिट चर private staticजावा में चर के बराबर थे । इसी तरह सी के लिए आप पास्कल में डेटा को पारित करने के लिए अपारदर्शी बिंदुओं का उपयोग कर सकते हैं बिना यह घोषित किए कि यह क्या था। क्लासिक MacOS ने बहुत सारे अपारदर्शी बिंदुओं का उपयोग किया क्योंकि सार्वजनिक और निजी रिकॉर्ड (डेटा संरचना) के कुछ हिस्सों को एक साथ पारित किया जा सकता है। मुझे याद है कि विंडो मैनेजर बहुत कुछ कर रहा था क्योंकि विंडो रिकॉर्ड के कुछ हिस्से सार्वजनिक थे लेकिन कुछ आंतरिक जानकारी भी शामिल थी।

— माइकल शोप्सिन

पास्कल की तुलना में शायद एक बेहतर उदाहरण पायथन है, जो ऑब्जेक्ट-ओरिएंटेशन का समर्थन करता है लेकिन कोई एनकैप्सुलेशन नहीं है, जो नाम देने योग्य सम्मेलनों का सहारा ले रहा है, जैसे कि , _private_memberऔर output_property_नक़ली वस्तुओं को बनाने के लिए और अधिक उन्नत तकनीकें।

— मेफि

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

— डेरेक एल्किंस

Answer 2

पहला, प्रक्रियात्मक बनाम वस्तु उन्मुख होने का सार्वजनिक बनाम निजी से कोई लेना-देना नहीं है। ऑब्जेक्ट ओरिएंटेड भाषाओं में एक्सेस कंट्रोल की कोई धारणा नहीं है।

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

foo.h:

struct queue;
struct queue* makeQueue();
void add2Queue(struct queue* q, int value);
...

foo.c:

struct queue {
    int* head;
    int* head;
};
struct queue* makeQueue() { .... }
void add2Queue(struct queue* q, int value) { ... }

विंडोज़ एसडीके को देखो! यह HANDLE और UINT_PTR का उपयोग करता है, और इस तरह की चीजें API में उपयोग की जाने वाली मेमोरी के लिए जेनेरिक हैंडल हैं - प्रभावी रूप से कार्यान्वयन को निजी बना रही हैं।

Comments

मेरे नमूने ने बेहतर (सी) दृष्टिकोण का प्रदर्शन किया - आगे घोषित संरचनाओं का उपयोग करते हुए। शून्य * दृष्टिकोण का उपयोग करने के लिए मैं टाइपसेफ्स का उपयोग करेगा: .h फ़ाइल में टाइप किए गए शून्य को * कतार कहें, और फिर हर जगह हमारे पास संरचनात्मक कतार थी बस कतार कहो; फिर .सी फ़ाइल में, स्ट्रक्चर कतार को स्ट्रक्चर कतार में नाम बदलें और किसी भी तर्क कतार बन जाता है (संरचना कतार का isntead *) और इस तरह के प्रत्येक फ़ंक्शन के लिए कोड की पहली पंक्ति संरचनात्मक कतार बन जाती है * qpl = (ढांचा कतार impl *) q

— लुईस प्रिंगल

हम्म। यह इसे निजी बनाता है क्योंकि आप इसके कार्यान्वयन (foo.cn) के अलावा कहीं से भी 'कतार ’के किसी भी क्षेत्र तक (पढ़ या लिख) नहीं सकते। आपको निजी से और क्या मतलब था? BTW - BOTH के लिए सच है टाइप किए गए शून्य * apporach और (बेहतर) आगे की घोषणा की संरचनात्मक दृष्टिकोण

— लुईस प्रिंगल

जब से मैंने smalltalk-80 पर किताब पढ़ी है, मुझे लगभग 40 साल हो गए हैं, लेकिन मुझे सार्वजनिक या निजी डेटा सदस्यों की कोई भी धारणा याद नहीं है। मुझे लगता है कि CLOS में भी ऐसी कोई धारणा नहीं थी। ऑब्जेक्ट पास्कल में ऐसी कोई धारणा नहीं थी। मुझे याद है कि सिमुला ने (शायद स्ट्रॉस्ट्रुप को विचार मिला था), और सी ओओ के बाद से अधिकांश ओओ भाषाएं हैं। किसी भी तरह - हम सहमत होते हैं और निजी डेटा अच्छे विचार हैं। उस बिंदु पर भी मूल प्रश्नकर्ता स्पष्ट था। वह सिर्फ पूछ रहा था - पूर्व-सी ++ भाषाओं में बूढ़े कैसे एनकैप्सुलेशन करते थे।

— लुईस प्रिंगल

@LewisPringle का स्मालटाक -80 में सार्वजनिक डेटा सदस्यों का कोई उल्लेख नहीं है क्योंकि सभी "उदाहरण चर" (डेटा सदस्य) निजी हैं, जब तक कि आप प्रतिबिंब का उपयोग नहीं करते हैं। AFAIU स्माल्टालकर्स हर चर के लिए एक सहायक लिखते हैं जिसे वे सार्वजनिक करना चाहते हैं।

— dcorking

इसके विपरीत @LewisPringle, सभी स्मालटाक "तरीके" (फंक्शन मेम्बर) सार्वजनिक हैं (इन्हें निजी रूप से चिह्नित करने के लिए अनाड़ी सम्मेलन हैं)

— dcorking

Answer 3

"ओपेक डेटा प्रकार" एक प्रसिद्ध अवधारणा थी जब मैंने 30 साल पहले अपने कंप्यूटर विज्ञान की डिग्री की थी। हमने ओओपी को कवर नहीं किया था क्योंकि यह उस समय आम उपयोग में नहीं था और "कार्यात्मक प्रोग्रामिंग" को अधिक सही माना जाता था।

मोडुला -2 का उनके लिए प्रत्यक्ष समर्थन था, https://www.modula2.org/reference/modules.php देखें ।

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

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

हर बड़े पैमाने पर परियोजना पर मैंने काम किया है, (इससे पहले कि मैं सी ++ पर चला गया फिर सी #) में "निजी" डेटा को गलत कोड द्वारा एक्सेस करने से रोकने के लिए एक प्रणाली थी। यह अब की तुलना में थोड़ा कम मानकीकृत था।

Answer 4

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

"निजी" चर तक पहुंचने के लिए इसे कठिन बनाने की तकनीकें हैं, जो कि PIMPL मुहावरा है । यह आपके निजी चर को एक अलग संरचना में रखता है, जिसमें आपकी सार्वजनिक हेडर फ़ाइलों में केवल एक पॉइंटर आवंटित किया गया है। इसका मतलब यह है कि किसी भी निजी चर को प्राप्त करने के लिए एक अतिरिक्त छूट और एक कास्ट, कुछ ऐसा है ((private_impl)(obj->private))->actual_value, जो कष्टप्रद हो जाता है, इसलिए व्यवहार में शायद ही कभी उपयोग किया जाता है।

Answer 5

डेटा संरचनाओं में "सदस्य" नहीं थे, केवल डेटा फ़ील्ड (यह एक रिकॉर्ड प्रकार था)। दृश्यता आमतौर पर पूरे प्रकार के लिए निर्धारित की गई थी। हालाँकि, यह उतना सीमित नहीं हो सकता जितना आप सोचते हैं, क्योंकि फ़ंक्शन रिकॉर्ड का हिस्सा नहीं थे।

चलिए वापस लौटते हैं और थोड़ा इतिहास यहाँ प्राप्त करते हैं ...

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

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

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

इसलिए मोडुला -2 और अदा (83) में आप किसी नाम स्थान निजी या सार्वजनिक किसी भी प्रकार की दिनचर्या, प्रकार, स्थिरांक या वस्तु की घोषणा कर सकते हैं, लेकिन यदि आपके पास एक रिकॉर्ड प्रकार था, तो कुछ रिकॉर्ड फ़ील्ड को सार्वजनिक करने का कोई आसान (आसान) तरीका नहीं था और अन्य निजी। या तो आपका पूरा रिकॉर्ड सार्वजनिक है, या यह नहीं है।

Comments

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

— डेविड

इसके अलावा, AFAIK अधिकांश OO भाषाएँ हुड के नीचे उसी तरह से काम करती हैं, अर्थात myWidget.getFoo () को वास्तव में getFoo (myWidget) के रूप में लागू किया जाता है। object.method()मंगलाचरण बस वाक्यात्मक चीनी है। महत्वपूर्ण आईएमएचओ - मेयर के यूनिफॉर्म एक्सेस / संदर्भ के सिद्धांत को देखें - लेकिन अभी भी केवल वाक्यात्मक चीनी।

— डेविड

@ दाविद - यह अडा 95 युग के दौरान वर्षों से एडीए समुदाय का तर्क था। मेरा मानना ​​है कि उन्होंने आखिरकार उन लोगों के object.method()लिए एक वैकल्पिक रूप की अनुमति देकर अपना तर्क साबित कर दिया, method(object, ...) जो वैचारिक छलांग नहीं लगा सकते थे।

— TED

Answer 6

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

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

शायद यह तनावपूर्ण है कि भाषा-निर्मित निर्माण के बजाय एक अच्छी तरह से मानकीकृत सम्मेलन के रूप में प्रतिबंध का उपयोग ठीक काम करता है (पायथन देखें)। उस के शीर्ष पर, ऑब्जेक्ट फ़ील्ड तक पहुंच को प्रतिबंधित करना केवल प्रोग्रामर की सुरक्षा के लिए जा रहा है जब निर्माण के बाद ऑब्जेक्ट के अंदर डेटा के मूल्य को बदलने की आवश्यकता होती है। जो पहले से ही एक कोड गंध है। तर्कपूर्ण रूप से, C और विशेष रूप से C + + का constकीवर्ड मेथड और फंक्शन आर्गुमेंट्स के लिए जावा के प्रोग्रामर की तुलना में कहीं अधिक मददगार है final।

Comments

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

— TED

Answer 7

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

मुझे उम्मीद है कि इस सफलता ने आपके सवाल का जवाब दिया।

Answer 8

यहाँ एक बहुत ही सरल काउंटर-उदाहरण है: जावा में, interfaceवस्तुओं को परिभाषित करते हैं, लेकिन classes नहीं। एक classसार डेटा प्रकार को परिभाषित करता है, एक वस्तु नहीं।

एर्गो, जब भी आप जावा privateमें उपयोग करते हैं class, तो आपके पास निजी सदस्यों के साथ डेटा संरचना का एक उदाहरण है जो ऑब्जेक्ट-ओरिएंटेड नहीं है।

Comments

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

— आमोन

मैंने इस जवाब से कुछ सीखा।

— छोटू

इंटरफेस वस्तुओं को "परिभाषित" नहीं करते हैं; वे संचालन / व्यवहार के लिए अनुबंध निर्दिष्ट करते हैं जो ऑब्जेक्ट कर सकते हैं या प्रदर्शन कर सकते हैं। विरासत आम तौर पर एक से वर्णन किया गया है वैसे ही जैसे एक है रिश्ते और रचना एक से एक है रिश्ते, इंटरफेस आम तौर पर द्वारा वर्णित हैं कर सकते हैं रिश्ते।

— code_dredd