ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के लिए विकल्प?


83

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

  • न केवल सिद्धांत में, बल्कि व्यवहार में भी उपयोग किया गया है।
  • ओओपी के साथ प्रतिस्पर्धा कर सकता है , इसलिए इसका उपयोग बड़ी परियोजना में कम से कम दर्द के साथ किया जा सकता है।
  • व्यापार तर्क, डेटाबेस, आदि के साथ एक डेस्कटॉप ऐप विकसित करने के लिए इस्तेमाल किया जा सकता है।
  • OOP के साथ उपयोग नहीं किया जाता है, लेकिन OOP के प्रतिस्थापन के रूप में।

और यदि कोई है, तो इसके पक्ष / विपक्ष क्या हैं, यह ओओपी से बेहतर / बदतर क्यों है, इसका उपयोग करने के लिए कौन सी भाषाएं सबसे अच्छी हैं, लोकप्रिय भाषाओं में इसका उपयोग करने के बारे में क्या है, क्या इसका कोई डिज़ाइन पैटर्न है, और क्या यह कर सकता है पूरी तरह से OOP की जगह?


1
@ जस्टिन अर्दिनी: मुझे पता है कि कई हैं, लेकिन जो ऊप से मुकाबला कर सकता है? @Tobiasopdenbrouw और मैक्रोज़: ठीक है, बदल गया।
डेरियस वोज्नियाक

ओओपी लोकप्रिय है क्योंकि यह लोकप्रिय है, अगर आप ओओपी को नहीं निगलते हैं तो आपके पास काम करने के लिए कोई प्रोजेक्ट नहीं होगा ...
aoeu256

डेटा ओरिएंटेड प्रोग्रामिंग आसान है, जहां आप सिंगल ऑब्जेक्ट्स के बजाय ऑब्जेक्ट कलेक्शन और उनके रिश्तों की परवाह करते हैं, जहां "डीबी ऑब्जेक्ट" के तरीके डिसफंक्शन प्रदान करते हैं। JSON और sexpressions SQL, CSS, HTML, Excel को स्वीट करते हैं, शेल स्क्रिप्ट लोकप्रिय और उपयोगी हैं, लेकिन "प्रोग्रामिंग" का अर्थ है ओओपी या प्रक्रियात्मक। OOP कोड का 20% होने के बावजूद पायथन को पायथन / जावास्क्रिप्ट कार्यक्रमों के लिए बनाए रखने के लिए धन्यवाद दिया जाता है। क्लोज़र और JSON का उपयोग वस्तुओं के स्थान पर 90% समय के लिए किया जा सकता है और उपयोग करने में सरल और आसान है।
aoeu256

जवाबों:


51

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

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

उद्योग में उपयोग किए जाने वाले कार्यात्मक प्रोग्रामिंग का एक अच्छा उदाहरण एरलांग है । यह ज्यादातर दूरसंचार, वितरित और दोष सहिष्णु प्रणालियों में उपयोग किया जाता है। प्रस्तुति एर्लैंग देखें - जो आर्मस्ट्रांग द्वारा एक समवर्ती दुनिया के लिए सॉफ्टवेयर

नई कार्यात्मक प्रोग्रामिंग भाषाएं भी हैं जो OOP के साथ कार्यात्मक प्रोग्रामिंग को जोड़ती हैं। .NET प्लेटफॉर्म के लिए दो अच्छे उदाहरण हैं # और जावा प्लेटफॉर्म के लिए स्काला ; वे अक्सर अन्य भाषाओं में लिखे गए मंच पर मौजूदा पुस्तकालयों का उपयोग कर सकते हैं।

नई प्रोग्रामिंग भाषाओं का चलन अब बहु-प्रतिमान है , जहां ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग और कार्यात्मक प्रोग्रामिंग जैसे कई प्रतिमानों को एक ही भाषा में संयोजित किया जाता है।


4
स्काला का उद्देश्य वस्तु-उन्मुख और कार्यात्मक भाषाओं की सुविधाओं को एकीकृत करना है।
फिलिप

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

1
@ ventr1s: हां, कार्यात्मक प्रोग्रामिंग OOP को प्रतिस्थापित कर सकती है लेकिन इसका उपयोग Oala के साथ Scala और F # जैसी भाषाओं में एक साथ किए जाने की संभावना है।
जोनास

1
@ ventr1s: उद्योग में कार्यात्मक प्रोग्रामिंग का एक अच्छा उदाहरण है वितरित NoSQL डेटाबेस RIAK जो Erlang में लिखा गया है। riak.basho.com
जोनास

2
@ ventr1s: कार्यात्मक प्रोग्रामिंग और डिज़ाइन पैटर्न के बारे में यह प्रश्न देखें: stackoverflow.com/questions/327955/…
जोनास

12

OOP के चालू होने से पहले प्रक्रियात्मक प्रसंस्करण सब कुछ था, कुछ बड़े वास्तविक दुनिया अनुप्रयोगों का उत्पादन किया है (वास्तव में, उनमें से ज्यादातर मूल रूप से) और कई ऑपरेटिंग सिस्टम।

यह निश्चित रूप से बड़े पैमाने पर उत्पादों में न्यूनतम दर्द और अधिकतम प्रदर्शन के साथ उपयोग किया जा सकता है


4
हाँ, और अनगिनत मेट्रिक्स अध्ययनों से पता चला है कि यह लगभग 150K LOC पर गैस से चलता है। पेटीज के विंडोज एसडीके सर्का समय को देखें कि किस तरह से जटिल भार के तहत संरचित प्रोग्रामिंग विघटित होती है: 8 तर्कों के साथ 2, 6-10 सदस्यों के साथ संरचनाएं हैं। गणना की प्रत्येक इकाई के भीतर और बाहर डेटा धक्का अंततः काम नहीं करता है।
रॉब

2
ठीक है, लेकिन कितने अनुप्रयोग इस बड़े हो? OOP के साथ समस्या यह समझना बहुत जटिल है, और विशाल अनुप्रयोगों के लिए डिज़ाइन किया गया है - लेकिन यह छोटे लोगों के लिए भी डिफ़ॉल्ट है। यह जरूरी छोटे एप्लिकेशन को जटिल करने के विपरीत प्रभाव है।
नीको

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

8 तर्कों के साथ कार्य - कभी डिफ़ॉल्ट तर्कों के बारे में सुना? HashTables के लिए प्रक्रियात्मक + प्रथम श्रेणी के समर्थन के बारे में क्या + जावास्क्रिप्ट, अजगर, आदि की तरह बंद ...? उनके पास OOP के कई फायदे हैं जितने बिना कोड के।
aoeu256

4

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


4

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

PHP पर एक नजर उदाहरण के लिए:

  • OOP के कई तत्व हैं (संस्करण 5 से)
  • पहले ज्यादातर प्रक्रियात्मक था
  • घोषणात्मक प्रोग्रामिंग के तत्व हैं (उदाहरण के लिए फ़ंक्शन)
  • कार्यात्मक प्रोग्रामिंग के कई तत्वों को लागू किया गया (संस्करण 5.4 से)

मूल रूप से PHP बहुत सारे अलग-अलग प्रतिमानों को एक साथ जोड़ रहा है (और "गोंद भाषा" है)।

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

प्रोग्रामिंग भाषाओं की सूची विकिपीडिया: https://en.wikipedia.org/wiki/List_of_programming_languages_by_type#Imperative_languages (100% सटीक नहीं) पर देखें।

फ़ंक्शनल प्रोग्रामिंग (डेसिटिव प्रोग्रामिंग का सबसेट)

  • वाइडली व्यवहार में उपयोग किया जाता है (यह PHP , जैसे जावा और कई अन्य लोगों ने कार्यात्मक प्रोग्रामिंग की अवधारणाओं को लागू किया है)
  • कई विचार LISP में उत्पन्न होते हैं जो निश्चित रूप से देखने लायक है
  • आप पूरे अनुप्रयोगों का निर्माण कर सकते हैं जैसे हास्केल के साथ इसलिए यह ओओपी को "प्रतिस्थापित" कर सकता है

प्रक्रियात्मक प्रोग्रामिंग

  • सी (ज्यादातर प्रक्रियात्मक भाषा के रूप में) अभी भी सबसे अधिक इस्तेमाल की जाने वाली भाषाओं में से एक है
  • कई आधुनिक गोंद-भाषाएं शुरुआत में प्रक्रियात्मक थीं
  • अभी भी कई कार्यक्रम ज्यादातर प्रक्रियात्मक हैं (इसलिए यदि आप चाहते हैं कि यह "ओओपी" को "प्रतिस्थापित" कर सकता है)

तार्किक प्रोग्रामिंग

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

सामान्य रूप से घोषणा / डोमेन-विशिष्ट भाषाएँ

  • अपनी परियोजनाओं में एसक्यूएल का उपयोग? फिर वे विशुद्ध रूप से OOP नहीं हैं, SQL अनिवार्य रूप से घोषणात्मक है।
  • कई डोमेन-विशिष्ट भाषाएं (जैसे सीएसएस) घोषणात्मक हैं

सामान्य रूप से इंपीरियल प्रोग्रामिंग

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

आमतौर पर OOP को मॉडलिंग डेटा के दौरान बड़े, जटिल संबंधों को संरचित करने के लिए एक अच्छा विकल्प माना जाता है। हमेशा कई अन्य कार्यों के लिए जाना प्रतिमान नहीं है।


1

FP - फंक्शनल प्रोग्रामिंग एक अत्यंत लोकप्रिय प्रोग्रामिंग प्रतिमान है जो बहुत लंबे समय के लिए रहा है और हाल के वर्षों में, अधिक से अधिक प्रमुख बनने लगा है। FP बिना किसी साइड इफ़ेक्ट के म्यूटेबिलिटी, रिकर्सन और फ़ंक्शंस पर अपरिवर्तनीयता का पक्षधर है। लोकप्रिय fp भाषाओं के कुछ उदाहरण Erlang, Scala, F #, Haskell और Lisp (दूसरों के बीच) हैं।


-6

वर्तमान में कोई प्रतिमान नहीं है जो वास्तव में ओओपी की जगह ले सकता है। OOP (लाभ) के साथ मुद्दा यह है कि यह आपके लिए बड़ी मात्रा में काम करता है- स्वचालित रूप से संसाधनों को जारी करना, डेटा को मान्य करना, आदि, और यह कोड को मान्य करना आसान बनाता है- यह उल्लेख करने के लिए नहीं कि दुनिया के मौजूदा पुस्तकालयों का विशाल बहुमत C ++, C # या Java जैसी OOP भाषा में लिखे गए हैं। इस तरह के बड़े पैमाने पर पुस्तकालयों के बिना होने की वास्तविकता और इस तरह संदेहजनक है।

आला या अकादमिक दुनिया में, आपको बहुत सारे कार्यात्मक प्रोग्रामिंग मिलेंगे। हालांकि, यदि आप वास्तव में एक बड़ी परियोजना करना चाहते हैं, तो OOP जाने का एकमात्र तरीका है।

मुझे लगता है कि जेनेरिक प्रोग्रामिंग एक नए प्रतिमान के रूप में सामने आने वाली है। हालाँकि, यह वास्तव में अभी भी विकास के चरण में है और केवल C ++ / D वास्तव में अच्छी जेनेरिक प्रोग्रामिंग प्रदान करते हैं।


3
OOP उन चीजों में से कोई भी नहीं करता है। यह उन्हें आसान बना सकता है, लेकिन केवल तभी जब ओओ फ्रेमवर्क के डिजाइन में उन्हें शामिल किया गया है, जैसे कि .Net, या यदि आप उन्हें लिखने के लिए तैयार हैं।
मैट एलेन

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

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