यदि आपके ग्राहक को ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग का उपयोग न करने की आवश्यकता हो तो आप क्या करेंगे?


31

मैं चींटियों की गतिविधि को एक ग्रिड (पीडीएफ) में अनुकरण करने के लिए एक कार्यक्रम लिख रहा हूं । चींटी चारों ओर घूम सकती है, चीजों को उठा सकती है और चीजों को गिरा सकती है।

समस्या यह है कि चींटियों की क्रिया और प्रत्येक चींटी के पदों को वर्गीय विशेषताओं द्वारा आसानी से ट्रैक किया जा सकता है (और हम आसानी से इस तरह की चींटियों के कई उदाहरण बना सकते हैं) मेरे मुवक्किल ने कहा कि चूंकि उनके पास कार्यात्मक प्रोग्रामिंग में पृष्ठभूमि है, इसलिए वह चाहेंगे कार्यात्मक प्रोग्रामिंग का उपयोग करके बनाया जाने वाला सिमुलेशन।

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

हालाँकि, मुझे लगता है कि इस सवाल पर विशेष रूप से एक कार्यात्मक प्रोग्रामिंग आवश्यकता के बारे में ध्यान केंद्रित करना फायदेमंद है, बस "इसे अनिवार्य रूप से करना"।

आप इस स्थिति को कैसे संभालेंगे? क्या आप अपने क्लाइंट को यह समझाने की कोशिश करेंगे कि ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग का उपयोग करना ज्यादा साफ-सुथरा है, उसके लिए जो आवश्यक है उसे फॉलो करने की कोशिश करें और उसे खराब-गुणवत्ता वाला कोड दें, या कुछ और करें?


9
एक बात जो उनके दिमाग को बदल सकती है, वह यह है कि यदि आप ऐसा करने की लागत अधिक है (यदि आप एक कार्यात्मक प्रोग्रामिंग भाषा की तुलना में ओओ भाषाओं में अधिक कुशल हैं)।
होल्गर

रिच हिके के एंट सिमुलेशन कोड ( gist.github.com/1093917 ) की तुलना करना दिलचस्प हो सकता है - क्लोज़र में मूल रूप से कार्यात्मक है, हालांकि सिमुलेशन मुख्य रूप से एसटीएम के उपयोग को प्रदर्शित करने के लिए डिज़ाइन किया गया था।
मीका

13
टिप्पणीकार: टिप्पणियों में यहाँ एक उत्तर न छोड़ें। अपना जवाब लिखो। टिप्पणियाँ प्रश्न के विभिन्न संभावित उत्तरों पर चर्चा करने के लिए एक स्थान नहीं हैं: या तो अपने सुझाव को एक उत्तर के रूप में सामने रखें या पहले इसे बाहर ले जाने के लिए चैट करें।

6
बस यह सुनिश्चित करना चाहते हैं कि आपने N3dst4 के बिंदु को देखा कि "कार्यात्मक प्रोग्रामिंग" एक विशेष प्रोग्रामिंग अनुशासन है। प्रोग्रामिंग जो ऑब्जेक्ट ओरिएंटेड नहीं है, उसे आमतौर पर "प्रक्रियात्मक प्रोग्रामिंग" के रूप में वर्णित किया जाता है।
डीजेकेवर्थ

1
आपको क्यों लगता है कि ऑब्जेक्ट-ओरिएंटेड कार्यान्वयन "ज्यादा क्लिनर" होगा? सबसे अधिक संभावना है कि यह उचित कार्यात्मक समाधान की तुलना में बहुत कम पठनीय होगा।
एसके-लॉजिक

जवाबों:


201

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


83
+1 के लिए "आप बस कुछ सीख सकते हैं जिसकी आपको उम्मीद नहीं थी"!
केनेथ

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

8
+1 के लिए "आप बस कुछ सीख सकते हैं जिसकी आपको उम्मीद नहीं थी" !, लेकिन: अगर ओपी को कार्यात्मक प्रोग्रामिंग में बहुत अनुभव नहीं है और ग्राहक को एक अच्छे और सस्ते समाधान की उम्मीद है, तो यह एक में गोता लगाने के बजाय जोखिम भरा होगा समस्याओं को हल करने का नया तरीका।
मोर्ट

3
@mort - इस मामले में ग्राहक कुछ युक्ति चाहता है, लगता है कि वे वास्तव में जानने के लिए पर्याप्त हैं कि वे क्या चाहते हैं, इसलिए यदि वे जिस व्यक्ति को काम पर रखते हैं वह इसे अपनी समस्या नहीं कर सकता है। मुझे लगता है कि मैं जो कह रहा हूं वह तथ्य यह है कि ग्राहक कुछ "अच्छा और सस्ता" चाहता है और कहता है कि उन्होंने उस गलत व्यक्ति को काम पर रखा है जो ग्राहक की गलती नहीं कर सकता है, न कि लेखक की गलती वह नहीं जानता कि वह कैसे सस्ता प्रदान करेगा इस समस्या के लिए अच्छा कार्यात्मक प्रोग्रामिंग समाधान। इसके लायक लेखक में से एक ग्राहक जो चाहता है, उसे प्रदान करने की कोशिश कर रहा है क्योंकि ऐसा करने का कोई तकनीकी कारण नहीं है।
रामहाउंड

2
प्रश्न में कहीं भी ओपी ने "अच्छा और सस्ता" शब्द नहीं कहा। इच्छा "तेज और अच्छी" (तीनों में से: तेज, अच्छी, सस्ती) हो सकती है। यह सब अप्रासंगिक है, बिना ओपी मार्गदर्शन के, क्योंकि "स्पेसिफिकेशन्स" का कहना है कि "कार्यात्मक प्रोग्रामिंग का उपयोग करें"।
वर्नरसीडी

68

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

शायद वह कोड रखने और बाद में खुद इसे बनाए रखने का इरादा रखता है।

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

मैं उनसे पूछूंगा कि वे कार्यात्मक शैली में कोड क्यों चाहते हैं और यदि समय ऐसा नहीं है तो मैं कुछ अतिरिक्त दिनों के लिए कार्यात्मक प्रोग्रामिंग के साथ गति प्राप्त करने के लिए कहूंगा। (सीखने के लिए भुगतान पाने के लिए तूफान!)

यदि अन्य सभी यह बताते हैं कि यह आपको OO शैली में करने में बहुत कम समय लगेगा।


@downvoter क्या आप कुछ प्रतिक्रिया देंगे?
थानोस पपथनसीउ

3
मैं समझता हूं कि टीएल; ड्रॉ संकेतन के लायक है, कुछ को
स्वतंत्र

1
क्या अक्सर पूछे जाने वाले प्रश्न या सहायता पृष्ठों में "tl; ड्र?" का उपयोग करने के लिए कुछ भी है? या यह सिर्फ कुछ दुष्ट उपयोगकर्ता है जो इसे पसंद नहीं करते हैं? मुझे लगता है कि एक उत्तर के एक संक्षिप्त सारांश को जोड़ना केवल एक अच्छी बात हो सकती है, इसलिए मैं कल्पना नहीं कर सकता कि इसे एक मूल्य के रूप में क्यों माना जाएगा।
बेन ली

1
@ मुझे लगता है कि tl; dr संकेतन उपयोगकर्ता के लिए मेरा जवाब पढ़ने की कोशिश कर रहा था। मतलब यह है कि भले ही आप बाकी को छोड़ दें, अगर आप इसे पढ़ते हैं तो आपको उत्तर का पता चलता है। आप जो कह रहे हैं, उससे आपका क्या मतलब है?
थानोस पपथनसीउ 19

1
हम में से बूढ़े लोगों को कोई पता नहीं है कि क्या tl? Dr का मतलब है (मैंने इसे देखा था लेकिन कोई भी इस तरह के बकवास का इस्तेमाल क्यों करेगा?)
HLGEM

55

क्या आप जानते हैं कि कार्यात्मक प्रोग्रामिंग का अर्थ "कक्षाओं के बिना प्रोग्रामिंग" नहीं है?

पूर्ण विद्वान के लिए इसके बारे में विकिपीडिया लेख देखें , लेकिन संक्षेप में ...

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

कार्यात्मक प्रोग्रामिंग एक प्रोग्रामिंग प्रतिमान है, जैसे OO एक प्रोग्रामिंग प्रतिमान है।

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

आपके लिए सौभाग्य से, पायथन में कार्यात्मक प्रोग्रामिंग के लिए उत्कृष्ट उपकरण हैं (सबसे महत्वपूर्ण यह है कि फ़ंक्शन प्रथम श्रेणी के हैं)।

पायथन फंक्शनल प्रोग्रामिंग HOWTO


इसे बाहर निकालने के लिए +1। यह वास्तव में प्रश्न में स्पष्ट किया जाना चाहिए।
ब्राच

क्या आप जानते हैं कि आपके पास ऐसी भाषाएँ हो सकती हैं जो OO और कार्यात्मक दोनों हैं? वे दो आयोजन सिद्धांत हैं जो वास्तव में एक दूसरे के लिए काफी हद तक रूढ़िवादी हैं। माना जाता है कि बहुत सी ओओ भाषाएं संरचित भाषाएं भी हैं, लेकिन उन लोगों को मजबूती से जोड़ने का कोई सैद्धांतिक आधार नहीं है।
डोनाल्ड फेलो 20

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

22

अपने क्लाइंट को समझाएं कि यदि वह कार्यात्मक प्रोग्रामिंग चाहता है, तो उसे किसी ऐसे व्यक्ति को नियुक्त करना चाहिए जो उस में माहिर हो। कार्यात्मक प्रोग्रामिंग ओओपी से बहुत अलग है, और आपको गलत लगेगा यदि आपको लगता है कि आप इसे आसानी से उठा सकते हैं और उच्च गुणवत्ता का एक जटिल समाधान प्रदान कर सकते हैं।


इस बात से सहमत। यह सिर्फ सामान्य ज्ञान है।
मिस्टर स्मिथ

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

@Andres F: एक नई भाषा (और प्रतिमान) से निपटना आसान नहीं है। जल्द ही या बाद में क्लाइंट को समस्या पर पुनर्विचार करना होगा। बाद में जल्द ही बेहतर होगा।
मिस्टर स्मिथ

4
@ मिस्टर स्मिथ: मैं आपसे पूरी तरह सहमत हूं। मैं सिर्फ प्रदाता (यानी प्रोग्रामर) से इस तरह की ईमानदारी कह रहा हूं हमेशा आगामी नहीं है। अनिवार्य रूप से आप ग्राहक को किसी और को किराए पर लेने के लिए कह रहे हैं, जो दुनिया में सभी समझ में आता है, लेकिन फिर भी दर्दनाक है।
एंड्रेस एफ।

13

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

और ध्यान रखें कि "ऑब्जेक्ट्स" को किसी क्लोजर की कार्यात्मक अवधारणा द्वारा इंटरचेंज किया जा सकता है, क्योंकि ऑब्जेक्ट्स खराब आदमी की क्लोजर हैं, गरीब आदमी की ऑब्जेक्ट्स हैं ...; ;-):

https://stackoverflow.com/questions/2497801/closures-are-poor-mans-objects-and-vice-versa-what-does-this-mean

https://stackoverflow.com/questions/501023/closures-and-objects


+1 फंक्शनल प्रोग्रामिंग और ओओपी ऑर्थोगोनल अवधारणाएं हैं। OCaml, Scala, Clojure, python को उन भाषाओं के लिए देखें जो दोनों को संभाल सकती हैं।
आरडीएस

वे दो लिंक अकेले एक मूल्य के हैं ...
वेन वर्नर

8

क्लाइंट के साथ इस पर बात करने के बाद, अगर वह अभी भी अपना रास्ता चाहता है, तो आप या तो एक पेशेवर काम करते हैं, या यदि आप नहीं कर सकते हैं, तो आप अनुबंध नहीं लेते हैं या इसके बारे में कोई रास्ता नहीं ढूंढते हैं।

"गंदे कोड" का उत्पादन सिर्फ इसलिए कि आप असहमत हैं, अत्यधिक अव्यवसायिक होगा।


8
  1. हम सभी क्यों मान रहे हैं कि ग्राहक कार्यात्मक और अनिवार्य प्रोग्रामिंग के बीच अंतर जानता है? बहुत से लोग नॉन ओओ प्रोग्रामिंग प्रतिमानों के नाम या बारीकियों को नहीं जानते हैं और "प्रक्रियात्मक" "जरूरी" और "कार्यात्मक" जैसे आसानी से इंटरचेंज शब्द करेंगे।

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

  3. यदि क्लाइंट कल्पना लिखता है तो कल्पना को लागू करें, अन्यथा आप कल्पना लिखें और अपनी कल्पना को कार्यान्वित करें

  4. ग्राहकों के निर्णयों को प्रभावित करने की सबसे अच्छी रणनीति अवांछनीय विकल्प को काफी अधिक महंगा बनाना है। यह हर काम करता है।

  5. यदि आप विशेषज्ञ (क्लाइंट के रिश्तेदार) हैं, तो आपको उन्हें मनाने में सक्षम होना चाहिए।

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

  7. यह दोनों तरीके क्यों नहीं करते हैं तो ग्राहक को दोनों कार्यान्वयन देखने दें और तय करें कि कौन सा रखरखाव करना आसान है। बस अपने प्रोजेक्ट अनुमान में यह सब कारक है ताकि आप भुगतान प्राप्त करते समय सीखने की अवस्था का आनंद ले सकें।


+1 के लिए "हम सभी क्यों मान रहे हैं कि ग्राहक कार्यात्मक और अनिवार्य प्रोग्रामिंग के बीच अंतर जानता है?"। क्लाइंट का मतलब कुछ ऐसा हो सकता है जैसे "मैं नहीं चाहता कि यह दोहराव वाला हो, इसलिए हर चीज को कार्यों में तोड़ दें", जो डेवलपर्स के लिए सामान्य ज्ञान है। एक ग्राहक यह सामान्य ज्ञान नहीं सोच सकता है, इसलिए वह आपको बता रहा है।
एलेक्स वेबब्र

1
+1, वास्तविकता में ग्राहक को पता नहीं है कि कार्यात्मक प्रोग्रामिंग क्या है जो या तो नवीनतम buzz शब्दों द्वारा संचालित है या क्योंकि उन्होंने बीस साल पहले ऐसा किया था और अभी भी खुद को तकनीकी समझते हैं।
बेनामी टाइप

5

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

उदाहरण के लिए, कई लोग विचार कर सकते थे

class C {
public:
  C();
  void f( int );
  void g();
};

एक शास्त्रीय वस्तु-उन्मुख दृष्टिकोण होना, लेकिन

struct C;
void construct( C ** );
void f( C *obj, int arg);
void g( C *obj );

नहीं (भले ही दोनों समान रूप से ऑब्जेक्ट-ओरिएंटेड हों जहां तक ​​कि शास्त्रीय डेटा "एक साथ कार्य करता है जो उस पर काम करता है" परिभाषा जाती है)।


2
OOP के सटीक अर्थ के बारे में तर्क क्यों? यह पूछना बेहतर होगा कि ग्राहक क्यों सोचता है कि उसका सिमुलेशन कार्यात्मक प्रोग्रामिंग के लिए बेहतर है। ग्राहक सही हो सकता है ... मुझे "कार्यात्मक" से गंभीरता से संदेह है कि वह आपके दूसरे सी उदाहरण का मतलब है, या वह "कार्यात्मक" "भ्रामक" के साथ भ्रमित कर रहा था।
एंड्रेस एफ।

@Andres F .: मैंने दावा नहीं किया कि 'कार्यात्मक' से उनका मतलब मेरा दूसरा C उदाहरण है। मैं सिर्फ इशारा कर रहा था कि कुछ लोग इसे OOP मानते हैं जबकि अन्य नहीं। इसलिए तर्क शुरू करने से पहले, किसी भी गलतफहमी से बचना अच्छा होगा। शायद पहली बार में कोई असहमति नहीं है। हो सकता है कि बॉस, जब से उन्होंने कहा कि वह खुद से परिचित नहीं हैं, तो मानते हैं कि ओओपी में कुछ गुण हैं (जैसे ओपी ने स्पष्ट रूप से माना कि कार्यात्मक प्रोग्रामिंग में कुछ गुण थे)।
फ्रिविच राबे

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

5

क्या आप अपने क्लाइंट को यह समझाने की कोशिश करेंगे कि ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग का उपयोग करना ज्यादा साफ है?

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

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

या क्या आप उसका पालन करने की कोशिश करेंगे जो उसे चाहिए और उसे भद्दा कोड दे?

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

ऑब्जेक्ट ओरिएंटेशन प्रक्रियात्मक और मॉड्यूलर प्रोग्रामिंग का विस्तार है। ऑब्जेक्ट-ओरिएंटेशन बस आपको उपकरण देता है, जो उचित रूप से उपयोग किए जाने पर, आपको बेहतर तंत्र देता है जिसके साथ एन्कैप्सुलेशन, युग्मन, सामंजस्य और कोड-पुन: उपयोग / एक्स्टेंसिबिलिटी मुद्दों से निपटने के लिए।

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

=========

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

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

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

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


3

आप डेटा-स्ट्रक्चर्स और ऑब्जेक्ट-ओरिएंटेड-प्रोग्रामिंग को मिला रहे हैं (इस OO से प्रभावित दुनिया में एक आम भ्रम)

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

ओओ में जिन चीजों को करना आसान है, वे रफ टफ हैं

  • वर्ग आधारित विरासत (एक नया वर्ग बनाने में आसान है जो पुराना होने का ढोंग करता है)
  • वर्ग आधारित बहुरूपता (बाद में अनुकरण करने के लिए नए प्रकार की चींटी को जोड़ना आसान है)

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


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

@ मार्सीन: इसका सही अर्थ है कि आधुनिक एफपी भाषाएँ काफी शक्तिशाली हैं। मैं वास्तव में डेटा-संरचनाकारों /
ADTs

लेकिन OO वास्तव में सिर्फ ADTs प्लस ऑब्जेक्ट-नियंत्रित विधि प्रेषण है। बाकी सब कुछ उसी के ऊपर बनता है। (खैर, अक्सर प्रेषण पर वस्तु द्वारा केवल नियंत्रण वस्तु के प्रकार द्वारा होता है, लेकिन यह एक शोधन है।)
डोनल फैलो

3

मेरे मुवक्किल ने कहा कि चूंकि उनके पास कार्यात्मक प्रोग्रामिंग में एक पृष्ठभूमि है, इसलिए वे चाहते हैं कि कार्यात्मक प्रोग्रामिंग का उपयोग करके अनुकरण किया जाए।

(यह अभी तक एक तकनीकी / डिजाइन मुद्दे के लिए गलत सामाजिक मुद्दे का एक और उदाहरण है।)

यहां दो संभावनाएं हैं:

  1. आपका क्लाइंट आपके द्वारा लिखे गए कोड को लेने में सक्षम होने की उम्मीद कर रहा है और आपके द्वारा इसे लिखने के बाद स्वयं को बनाए रखने या इसे बनाए रखने में सक्षम है। यदि हां, तो आपको "हाउस स्टाइल" के बारे में बहुत कुछ पता होना चाहिए - कार्यात्मक बनाम ओओ केवल हिमशैल का टिप है। आपको या तो अपने आप को प्रोग्रामिंग की एक शैली तक सीमित करने की आवश्यकता होगी जिसे आपका ग्राहक समझता है, या आपको अपने ग्राहक को अपनी पसंद की शैलियों में शिक्षित करने की आवश्यकता होगी। (एक बार, मुझे सीजीआई के साथ एक वेब ऐप बनाने के लिए कहा गया, बिना टेंपलेटिंग या लाइब्रेरी का उपयोग किए, क्योंकि क्लाइंट बदलाव करना चाह सकता है।)

  2. आपका ग्राहक कुछ एजेंडे के कारण विकास को नियंत्रित करने की कोशिश कर रहा है। यह पागल से भरा एक बैग है जिसे आप कुछ नहीं करना चाहते हैं। यदि आप वास्तव में "टर्नकी" सॉफ़्टवेयर प्रदान कर रहे हैं, तो क्लाइंट को परवाह नहीं करनी चाहिए कि यह पहियों पर चलने वाले हैम्स्टर से बना है, जब तक यह मज़बूती से काम करता है। अपने आप को इस तरह से micromanaged होने की अनुमति देना बस दर्द के लिए पूछ रहा है।

यह आप पर निर्भर है कि आप किस स्थिति में हैं और उसी के अनुसार कार्य करते हैं।


3

उम्म ... क्या मैं यहां केवल एक ही सोच रहा हूं "यह स्पष्ट रूप से एक परीक्षण नौकरी / असाइनमेंट है"?

सबसे पहले - असाइनमेंट स्वयं प्रकृति में "अकादमिक" तरह का है (चींटियों के व्यवहार के एक पहलू का अनुकरण)।

दूसरी बात - "क्लाइंट" की एक बहुत विशिष्ट प्रोग्रामिंग प्रतिमान गंध का उपयोग करके (या परहेज) आवश्यकताओं को लागू करने का अनुरोध जो कोड पढ़ सकते हैं और इस तरह के दावे कर सकते हैं।

यदि यह मामला है, तो आप बेहतर वही करते हैं जो आपके लिए आवश्यक है - यह सीखने का अच्छा अनुभव होगा और यदि आप इसे कर सकते हैं, तो आप इस प्रक्रिया में बहुत कुछ सीखेंगे ...

यदि यह मामला नहीं है, तो आपको वास्तव में असाइनमेंट के बारे में तर्क के लिए खुद और / या ग्राहक से पूछना चाहिए। यदि तर्क ठोस है, तो इसे करें - आप सीखेंगे और अनुभव के लिए प्रोग्रामर के रूप में बेहतर होंगे। कौन जानता है - आप भी OO पर कार्यात्मक शैली पसंद करना सीख सकते हैं।

यदि स्पष्टीकरण की कमी है, तो सभी दांव बंद हैं .. मैं आपको सलाह नहीं दे सकता कि क्या करना है।

आप कार्यात्मक भाषा / शैली में आवश्यकताओं को लागू करने की परवाह किए बिना प्रयास करना चाह सकते हैं या यदि आप कुछ गड़बड़ समझते हैं तो आप विनम्रता से प्रस्ताव को ठुकरा सकते हैं।

मुख्य बात यह है - एक बार जब आप आवश्यकताओं के पीछे की प्रेरणा को समझ लेते हैं, तो कार्रवाई का उचित पाठ्यक्रम स्पष्ट हो जाता है।

EDIT: संदर्भित पीडीएफ पर विकर्ण रूप लेने के बाद, वहां वर्णित एल्गोरिदम निश्चित रूप से OO के बजाय कार्यात्मक शैली के लिए एक अच्छा फिट लगते हैं।


2

कार्यात्मक प्रोग्रामिंग का उपयोग करने के उनके अनुरोध में कई अच्छे पहलू हैं:

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

लेकिन कुछ खतरनाक संकेत भी हैं:

  1. आप इसे कार्यात्मक प्रोग्रामिंग में लागू करने के लिए तैयार नहीं लगते हैं। आप पहले से ही अपने कौशल में थोड़े आउटडेटेड हैं और परिवर्तनों के साथ नहीं रख सकते।
  2. या ग्राहक आपसे बेहतर प्रोग्रामर होने की अपेक्षा कर रहे हैं। इसका मतलब है कि आपको उनकी आवश्यकताओं को कम करने की आवश्यकता हो सकती है जब तक कि आप इसे ठीक से नहीं कर सकते।

-1 निहितार्थ धारणा के लिए कि FP OOP से बेहतर है।
रसेल बोरोगोव

@ tp1 1) आप मानते हैं कि ग्राहक तकनीकी रूप से प्रोग्रामर की तुलना में अधिक स्मार्ट है, जो कि ग्राहक के बस की बात नहीं है। 2) FP OOP से पुराना है और जबकि यह हाल ही में बहुत अधिक प्रेस हो रहा है, OOP में कुछ भी गलत नहीं है और आपको FP 3 का उपयोग करने की आवश्यकता नहीं है) इसका सबसे बुरा हिस्सा यह है कि FP बेहतर है और उपयोग कर रहा है एफपी आपको एक बेहतर प्रोग्रामर बनाता है, केवल मामले में एक मामले में सच है और इस मामले में यह सच नहीं है।
जो टाईमन

@ जोए टाइमन: ठीक है, यह मानना ​​होगा कि लोग मूर्ख नहीं हैं, या अन्यथा ग्राहक एक पल में चले जाते हैं। मैं यह कहने की कोशिश नहीं कर रहा था कि ऊप खराब है या बदतर है, लेकिन इसके बजाय यह मानते हुए कि कार्यात्मक इस स्थिति में अनुचित आवश्यकता हो सकती है - शायद क्लाइंट को प्रोग्रामर के कौशल का पता नहीं है, या इससे भी बदतर, प्रोग्रामर अपनी तकनीक को बदलने की कोशिश कर रहे हैं।
tp1

@ जोए टाइमन: इसके अलावा, सबसे खराब स्थिति जो मेरे मन में थी, वह यह थी कि ग्राहकों को वास्तव में ऐसे लोगों की आवश्यकता होती है जो श्रेणी सिद्धांत जैसे कुछ उन्नत कार्यात्मक प्रोग्रामिंग कर सकते हैं, और वे एक टीम खोजने की कोशिश कर रहे हैं जो यह कर सकती है - यही कारण है कि अनुरोध उनके लिए अनुचित हो सकता है।
tp1

1

उपरोक्त प्रतिक्रियाओं को सुरक्षित रखने के लिए कि शायद OO सबसे अच्छा समाधान नहीं है जिस स्थिति में ग्राहक के पास एक बिंदु हो सकता है।

AI चैलेंज पर एक नज़र डालें, जो यहां दिए गए कुछ व्यवहारों के बारे में विस्तृत विवरण http://aichallenge.org और फिर स्टार्टर पैकेजों की विविधता पर एक नज़र डालते हैं - http://aichallenge.org/starter_packages.php/ सबसे ऐसी भाषाएँ हैं जिन्हें मैं OO प्रतिमान के भीतर नहीं रखूँगा।


1

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

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


0

क्लाइंट "कूद" कहता है, आपका उत्तर है: __ _ ?

मेरे लिए, मैं इसे समझाने का प्रयास करूँगा अगर यह समझ में आता है (नई परियोजना), लेकिन मेरे पास 10 yr पुराने VB6 ऐप के साथ एक ग्राहक भी है जिसे मैं कभी-कभार अपग्रेड करता हूं ... उन्हें समझाने के लिए नहीं।


तकनीकी रूप से हालांकि VB6 ऐप ठीक है, यह लगभग OO है, और अगर यह चालू OS पर ठीक काम करता है तो .NET में "अपग्रेड" क्यों करें। जब तक आप नई कार्यक्षमता का लाभ नहीं उठाना चाहते, तब तक इसका कोई मतलब नहीं है।
बेनामी टाइप

हां, लेकिन क्या आपने हाल ही में vb6 का उपयोग करने की कोशिश की है? यह बहुत दर्दनाक है;)
बूमहाउर

हाँ। हम मौजूदा ऐप्स को बनाए रखने के लिए इसका भरपूर उपयोग करते हैं जिन्हें अभी तक java या .net के अपडेट के लिए बजट नहीं दिया गया है। यह दर्दनाक है (एक आधुनिक आईडीई की तुलना में) लेकिन यह भी सापेक्ष है। किसी भी भाषा की तरह (लिपियों सहित) एक बार आपके अच्छे होने पर आपकी दर्द की परिभाषा अधिक व्यक्तिपरक हो जाती है।
बेनामी टाइप

0

अपने ग्राहक को थोड़ा पार करें (एक गैर-टकराव वाले तरीके से):

क्या ग्राहक वास्तव में OOP और कार्यात्मक प्रोग्रामिंग के बीच अंतर जानता है? क्या ग्राहक की चिंता / अनुरोध वैध हैं?

अगर हाँ': यदि आप योग्य हैं, तो वही करें जो वे चाहते हैं और अपना पैसा लें। यदि आप योग्य नहीं हैं, तो उन्हें बताएं और उन्हें निर्णय लेने दें कि क्या करना है।

Else: हाय-पूंछ यह वहाँ से बाहर!


0
double dist(Point p1, Point p2) 
{
  //return distance
}

यह फ़ंक्शन तब तक कार्यात्मक है जब तक यह फ़ंक्शन के बाहर कुछ भी नहीं पढ़ता / लिखता है। यदि फ़ंक्शन ने एक वर्ग चर को छुआ है तो यह "कार्यात्मक" नहीं होगा। कार्यात्मक शैली का लाभ यह है कि बदलने या अमान्य स्थिति से अधिक बग नहीं हैं। बड़ी संख्या में कार्य सिर्फ गणितीय सूत्र हैं। यह संक्षेप में कार्यात्मक प्रोग्रामिंग है।

BTW आप एक वस्तु आधारित या उन्मुख डिजाइन के भीतर एक कार्यात्मक शैली को जोड़ सकते हैं। उदाहरण के लिए दो "प्वाइंट" चर राज्य के साथ ऑब्जेक्ट हैं। और फ़ंक्शन अभी भी कार्यात्मक है! वाह!!

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