क्या गैर-ओओपी प्रतिमान एन्कैप्सुलेशन जैसी अवधारणाओं का समर्थन करते हैं?


12

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

यह मुझे लगता है कि, एनकैप्सुलेशन और अन्य ओओपी सिद्धांतों के बारे में क्या है? क्या वे गलत हैं?

क्या यह है कि OOP गलत है? उदाहरण के लिए एलन के को OOPSLA'97 कीनोट में कहने के लिए जाना जाता है: "मैंने ऑब्जेक्ट-ओरिएंटेड शब्द का आविष्कार किया था, और मैं आपको बता सकता हूं कि मेरे मन में C ++ नहीं था।"

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




2
मैं कहूंगा कि पहले प्रश्न को स्पष्ट करने की आवश्यकता है कि एनकैप्सुलेशन का क्या मतलब है और इसका समर्थन करने के लिए भाषा का क्या अर्थ है।
व्योम

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

1
रॉबर्ट मार्टिन ने एक बार कहा था कि ओओपी ने एनकैप्सुलेशन को दूर ले लिया और फिर इसे भयानक हैक के साथ वापस पैच किया। "हमारे पास oo से पहले सही एनकैप्सुलेशन था"। बेशक वह अतिशयोक्तिपूर्ण हो रहा था, लेकिन अब हर बार मैं किसी को यह कहते हुए देखता हूं कि ऊ, मैं चाचा बॉब को याद करता हूं।
GnP

जवाबों:


15

मुझे लगता है कि आप जिस जाल में गिरे हैं वह सोच रहा है कि किसी भी प्रोग्रामिंग प्रतिमान (संरचित, वस्तु-उन्मुख, कार्यात्मक, एट अल।) की एक कठोर परिभाषा है।

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

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

क्या यह है कि OOP गलत है?

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

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


10

हालांकि, हाल ही में सॉफ्टवेयर दुनिया कार्यात्मक प्रोग्रामिंग जैसे अन्य प्रतिमानों के पक्ष में झुकती हुई प्रतीत होती है।

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

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

यह मुझे लगता है कि, एनकैप्सुलेशन और अन्य ओओपी सिद्धांतों के बारे में क्या है? क्या वे गलत हैं?

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

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

क्या यह है कि OOP गलत है? उदाहरण के लिए एलन के को OOPSLA'97 कीनोट में कहने के लिए जाना जाता है: "मैंने ऑब्जेक्ट-ओरिएंटेड शब्द का आविष्कार किया था, और मैं आपको बता सकता हूं कि मेरे मन में C ++ नहीं था।"

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

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

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


1
Im को यकीन नहीं है कि OO GUI के लिए बेहतर है, OO और GUI एक ही समय में उभरे हैं। हालांकि, मैकार्थी / जावास्क्रिप्ट के लिए +1;)
jk।

1
निष्पक्ष होने के लिए, कुछ लोग सुझाव देते हैं कि मौजूदा दृष्टिकोण त्रुटिपूर्ण हैं और उन्हें किसी अन्य चीज़ से बदला जा सकता है । मुझे नहीं पता कि क्या मैं उस "विस्तार" को कॉल करूंगा या टूलबॉक्स को "बेहतर" करूंगा :)
एंड्रेस एफ।

1
@AndresF। यह एक शानदार पढ़ा है। जब मेरे पास कुछ समय होता है, तो मैं उस कागज पर विस्तार से जाने की योजना बनाता हूं।
रॉबर्ट हार्वे

4

बेशक:

struct Foo
{
    string bar;
    int bux;
}

मुझे पता है कि आप क्या कहने जा रहे हैं: "लेकिन यह भी व्यवहार को बढ़ावा नहीं देता है!" खैर, मैं इस पर जो आर्मस्ट्रांग के साथ हूं: आप कभी भी प्रथम श्रेणी की वस्तुओं की आवश्यकता के बिना पूरे कार्यक्रम या ऑपरेटिंग सिस्टम लिख सकते हैं। लिनक्स साबित करता है कि।

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


3
आप सिर्फ चम्मच से गंदगी की पहाड़ी को भी फावड़ा कर सकते हैं। लेकिन जो कोई भी दावा करता है कि ऐसा करने का इष्टतम तरीका है उसे संदेह के साथ देखा जाना चाहिए।
जश्न

6
मैंने कभी नहीं कहा कि यह इष्टतम था, और यही नहीं ओपी वैसे भी पूछ रहा है। अन्य समाचारों में, मुझे यह पता चल रहा है कि लिनक्स एक चम्मच के साथ फावड़ा गंदगी के रूप में योग्य है।
रॉबर्ट हार्वे

2
@jk। बेशक। तो सी करता है, एक तरह से।
रॉबर्ट हार्वे

1
वास्तव में यह इस प्रकार है
जे.के.

4
मैं सी संरचनाओं को 'एनकैप्सुलेशन' नहीं कहूंगा। वे न तो डेटा की रक्षा करते हैं और न ही इसे एक्सेस करने के लिए कोई मानकीकृत तरीका प्रदान करते हैं। वे सिर्फ आपको मैनुअल पॉइंटर अंकगणित करने से बचाते हैं। उदाहरण के लिए नेटवर्किंग कोड ढूंढना बहुत ही आम बात है जो संरचनाओं में क्रमबद्ध पैकेटों को ढंकता है और इसके विपरीत। नेटवर्क बाइट ऑर्डर को गलत और मजेदार तरीके से प्राप्त करें।
david25272

2

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

सबसे पहले परिभाषा आप कर रहे हैं खोजने के लिए जा रहा है

एनकैप्सुलेशन एक अवधारणा है जो डेटा और फ़ंक्शन को एक साथ बांधती है जो डेटा में हेरफेर करती है ...

यदि यह आपकी परिभाषा है, तो अधिकांश भाषाओं में समूह डेटा, और उस डेटा को कक्षाओं, मॉड्यूल, लाइब्रेरी, नेमस्पेस, आदि में कार्य करने का तरीका है।

लेकिन मैं तर्क दूंगा कि इनकैप्सुलेशन का मुख्य उद्देश्य नहीं है, क्योंकि यह परिभाषा जारी है:

..., और यह दोनों बाहरी हस्तक्षेप और दुरुपयोग से सुरक्षित रखता है।

विकिपीडिया भी इस पर सहमत है:

ऑब्जेक्ट के कुछ घटकों तक सीधी पहुंच को सीमित करने के लिए एक भाषा तंत्र।

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

पहला यह है कि डेटा को म्यूट किया जा सकता है, जिसमें गुंजाइश सीमित करना डेवलपर के सर्वोत्तम हित में है। जिस तरह से अक्सर मूल्य निर्धारित होने से पहले / बाद में तर्क की आवश्यकता होती है। और केवल सीमित संख्या में ऐसे स्थान जहाँ मूल्य निर्धारित किया जा सकता है, अत्यंत मूल्यवान है। ओओपी भाषाओं में यह कक्षाओं का उपयोग करके किया जा सकता है। "उत्परिवर्तनीय" कार्यात्मक भाषाओं में क्लोजर समान उद्देश्य पूरा करते हैं। और क्योंकि हम कक्षाओं = बंदों को जानते हैं , यह परस्पर विरोधी कार्यात्मक भाषाओं की तुलना में भी भिन्न है, OOP के लिए अलग-अलग "प्रतिमान" हैं।

लेकिन अपरिवर्तनीय भाषाओं का क्या? इसमें परिवर्तनशील चरों की समस्या नहीं है। यह वह जगह है जहां दूसरा मुद्दा आता है: बंधन कार्य और डेटा उस डेटा को राज्य में रखने की अनुमति देता है जो वैध है। कल्पना कीजिए कि आपके पास अपरिवर्तनीय संरचना है Email। इस संरचना में एकल stringक्षेत्र है। हमारी आवश्यकताएं हैं कि यदि आपके पास प्रकार का मूल्य है Emailतो उस क्षेत्र में मान्य पता होता है। ओओपी के एनकैप्सुलेशन में, यह आसानी से उस क्षेत्र को घोषित करने private, केवल Getविधि प्रदान करने और होने के द्वारा किया जाता हैconstructor methodयह केवल तभी सफल होता है जब स्ट्रिंग में पास किया गया वैध पता हो। बंदों के साथ भी ऐसी ही बात। अब, अपरिवर्तनीय भाषा के लिए, इसे यह कहने की आवश्यकता होगी कि संरचना को केवल विशिष्ट फ़ंक्शन के माध्यम से आरंभ किया जा सकता है और ऐसा फ़ंक्शन विफल हो सकता है। और मुझे ऐसी किसी भी भाषा के बारे में जानकारी नहीं है जो उस मानदंड के अनुकूल होगी (हो सकता है कि टिप्पणी में कोई मुझे बताए)।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.