क्या ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग वास्तव में वास्तविक दुनिया का मॉडल है? [बन्द है]


52

मैंने देखा है कि यह आमतौर पर ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग को वास्तविक दुनिया के मॉडलिंग पर आधारित है लेकिन क्या यह है?

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

जबकि कुछ वस्तुएं जो मैं बनाता हूं, वे वास्तविक दुनिया की वस्तुओं की मॉडलिंग कर रही हैं, क्या पूर्व-OOP कोड समान नहीं होगा? मुझे संदेह है कि OO अपने कोड बेस में ग्राहक जैसी अवधारणाओं को शामिल करने वाले पहले व्यक्ति थे। लेकिन OO वास्तव में चीजों को मॉडल करने के तरीके के बारे में है, और मॉडलिंग की वह विधि मुझे वास्तविक दुनिया से प्रेरित नहीं लगती है।

तो: क्या वस्तु-उन्मुख प्रोग्रामिंग वास्तव में वास्तविक दुनिया का मॉडल है?


85
वास्तविक दुनिया की वस्तुओं का प्रतिनिधित्व करने वाली OOP वस्तुओं के सादृश्य का उपयोग करने का विचार "झूठ-से-बच्चे" अवधारणा का एक प्रमुख उदाहरण है। हम उन लोगों को बताते हैं जो ओओपी सीखना शुरू कर रहे हैं क्योंकि यह मूल बातें प्राप्त करने का एक सहज तरीका है। जैसे ही उन्होंने उन मूल बातें सीख लीं, वे इस तथ्य को अवशोषित करने के लिए तैयार हैं कि उन्हें जो भी पता है वह गलत है; चीजें वास्तव में उससे अधिक जटिल हैं। यह स्कूल में भौतिकी की तरह है: मुट्ठी चीजें नीचे गिरती हैं, फिर चीजें बड़ी चीजों के लिए तैयार होती हैं, फिर बड़ी चीजें अंतरिक्ष में झुकती हैं, फिर अंत में हमें बताया जाता है कि हम वास्तव में कुछ भी नहीं जानते हैं कि चीजें कैसे काम करती हैं।
दुष्टकांडबाग

4
असली विवाद यहाँ क्या है? क्या यह है कि कुछ वास्तविक विश्व संस्थाएं हैं जिन्हें कभी भी ओओ तकनीकों द्वारा पर्याप्त रूप से मॉडलिंग नहीं किया जा सकता है? या यह है कि मॉडलिंग यानी एक सरलीकृत समझ का उपयोग करके दुनिया को पर्याप्त रूप से फिट नहीं किया जाता है एक बुरा विचार है जो काम नहीं करता है?
दीपन मेहता

1
@DipanMehta, विवाद यह है कि OO को वास्तविक दुनिया के रूप में वर्णित करने से ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग का दिल छूट जाता है। सभी प्रोग्रामिंग तकनीक वास्तविक दुनिया (एक डिग्री या किसी अन्य) को मॉडल करते हैं, यही वह नहीं है जो ओओ को अद्वितीय बनाता है।
विंस्टन एवर्ट

@ अच्छी तरह से, वास्तव में OO को अलग modeling the real worldनहीं किया जा सकता है । शायद। लेकिन मैं निश्चित रूप से विश्वास नहीं करता कि आप OO में भी ऐसा करने में असफल होंगे। आपको कौन सा प्रतिमान या तकनीक लगता है कि यह OO से बेहतर है?
दीपन मेहता

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

जवाबों:


50

नहीं, बिलकुल नहीं।

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


शानदार रसीला जवाब। परिभाषा के अनुसार आप मॉडल में कुछ विवरण खो देते हैं।
मैथअटैक

क्षमा करें, मुझे यह उत्तर पसंद नहीं है। ओओपी के साथ आप वास्तविक दुनिया के कुछ पहलुओं (कुछ पहलुओं) को मॉडल कर सकते हैं।
क्लेम

33

किसी भी प्रकार के मॉडल, वास्तविक दुनिया का मॉडल नहीं बनाते हैं, पूरी तरह से नहीं।

वे चयनित भागों को मॉडल करते हैं, जो हाथ में आवेदन के लिए प्रासंगिक हैं।

आप किस बारे में बात कर रहे हैं (पर्यवेक्षक, प्रबंधक, कारखाने आदि ...) बुनियादी ढांचा है जो आपको अमूर्त अधिकार प्राप्त करने में मदद करने और दृढ़ता जैसे आवश्यक कार्यों का समर्थन करने के लिए है।


15
मेरा तर्क है कि "मॉडलिंग" का अर्थ पहले से ही कुछ पहलुओं की नकल करना है (जबकि दूसरों को छोड़ना)। उस अर्थ में, OO वास्तविक दुनिया की मॉडलिंग के लिए अनुमति देता है।
तमसे सजेलेई

OO द्वारा आपकी समस्या के किन हिस्सों को अच्छी तरह से चित्रित किया गया है? कुछ समस्याएं OO मॉडल के लिए अच्छी तरह से मैप नहीं होती हैं, जलवायु मॉडल दिमाग में आते हैं। कई व्यावसायिक समस्याएं OO के लिए अच्छा मैप करती हैं, यही वजह है कि मॉडल का व्यापक रूप से उपयोग किया जाता है।
माइकल शोप्सिन

@MichaelShopsin - क्या आपका मतलब है कि आपकी टिप्पणी मेरे उत्तर के बजाय प्रश्न पर होगी ?
ओडेड

@ मुझे आपका जवाब पसंद है; मेरी टिप्पणी "मॉडल चयनित भागों" का विस्तार है। OO पैटर्न बहुत सारी समस्याओं को मॉडल करता है, यह सुनिश्चित करने का मामला है कि वे समस्या को हाथ से मेल खाते हैं।
माइकल शोप्सिन

31

एक मॉडल क्या है, वैसे भी:
एक मॉडल एक सरलीकृत प्रतिनिधित्व है जिसका उपयोग वास्तविक दुनिया प्रणाली या घटना के कामकाज को समझाने के लिए किया जाता है

क्या ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग आपको वास्तविक दुनिया को मॉडल करने की अनुमति देता है?

निश्चित रूप से हाँ

वास्तविक दुनिया से मिलान करने के लिए सिस्टम को मॉडल करना लगभग असंभव है।

क्या मुझे हमेशा वास्तविक दुनिया के बाद सॉफ़्टवेयर को मॉडल करना होगा?

नहीं

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

बेशक ऐसी संस्थाएँ हैं जो वास्तव में मौजूद नहीं हैं, लेकिन केवल मॉडलिंग के माध्यम से हम वास्तव में अच्छी तरह से अवधारणा कर सकते हैं।


9
" एक मॉडल क्या है? " निजी लोगों का एक दुखी थोड़ा ढेर। लेकिन पर्याप्त कोड, आप पर है!
बेन ब्रोका

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

19

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

क्या सिखाया जाना चाहिए कि कक्षाएं अमूर्त वस्तुओं को मॉडल करती हैं, जैसे आपका मस्तिष्क करता है। आपके पास अपने सिर में "कार" की एक अमूर्त अवधारणा है जो किसी विशेष भौतिक कार के लिए मैप नहीं करती है, यह पुन: प्रयोज्य है, कार का विशिष्ट कार्यान्वयन इससे विरासत में मिल सकता है। आपका मस्तिष्क आपके लिए मेटा-मॉडल अवधारणाओं को भी पूरा करता है। आपके पास एक मानसिक मॉडल है कि क्या सोचा है, एक अवधारणा क्या है।

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


+1 ऐसा अद्भुत और अतिरिक्त-सामान्य दृष्टिकोण। इसे साझा करने के लिए धन्यवाद! मैं सोच रहा हूं कि क्या आपने कोई पुस्तक तैयार की है या नहीं? मैं निश्चित रूप से उस पुस्तक को पढ़ना पसंद करूंगा।
महदी

8

... ऑब्जेक्ट-ओरिएंटेड सिंटैक्स के साथ व्यक्त की जा सकने वाली दुनिया की तुलना में अधिक समृद्ध है।

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

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

स्रोत: विक्टोरिया Livschitz, प्रोग्रामिंग में अगला कदम


2
यह एक अजीब लग रहा है जब आप इस तरह के एक सम्मोहक मामले को देखते हैं जिसे आप अभी भी असहमत हैं। मुझे उद्धरण के लिए प्रेरणा मिलती है, और इसे बेहतर ढंग से बोलना कठिन होगा। मुझे नहीं पता कि यह हमारी समस्याओं को उसी तरह से मॉडल करने की गलती है जैसे कि हमारे प्रतीकात्मक, रिश्ते-उन्मुख विचार प्रक्रियाएं करते हैं।
menacingly

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

13
this.MoveTo(Environment.Find<Bathroom>().OrderBy(b=>b.Distance(this)).First()); this.SitOn(Environment.Find<Toilet>().Where(t=>!t.IsOccupied).OrderBy(t=>t.Distance(this)).First().Component<Seat>()); this.DiscardWaste(HumanWasteType.All);
एडम रॉबिन्सन

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

1
OO के पास अनुक्रमण, या राज्य की कोई अवधारणा नहीं है । ऐसी बकवास। OOP में अनुक्रमण और स्थिति की कोई अवधारणा नहीं है? OO
clime

5

हां, ओओ का उपयोग अक्सर वास्तविक विश्व संस्थाओं को मॉडल करने के लिए किया जा सकता है।

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

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

एक इकाई को अलग करने के लिए हम उस इकाई को उसके वास्तविक विश्व समकक्ष के बाद मॉडल कर सकते हैं। उदाहरण के लिए, यदि हमारे पास एक गिटार है तो एक गिटार वर्ग एक वास्तविक विश्व गिटार के व्यवहार और गुणों को कूटबद्ध करता है। हम गिटार को और भी सार कर सकते हैं, जैसे, IInventoryItemबहुरूपता और वंशानुक्रम के माध्यम से कोड के पुन: उपयोग की क्षमता का लाभ उठाने के लिए।

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

इसका मतलब यह नहीं है कि OO को वास्तविक दुनिया का मॉडल बनाना है, और न ही ऐसा करने के लिए यह हमेशा सबसे इष्टतम समाधान है। बस, कि अंगूठे के एक नियम के रूप में "वास्तविक दुनिया मॉडलिंग" OO सही समझ में आता है।


5

यह निर्भर करता है कि आप किस वास्तविक दुनिया के बारे में बात कर रहे हैं।

जॉर्ज लुइस बोर्गेस ने एक कहानी "ट्लॉन, उकबार, ओर्बिस टर्टियस" लिखी, जहां के निवासियों में से एक को अपनी वास्तविक दुनिया काफी अलग लगती है:

[...] काल्पनिक Tlön के लोग [...] बर्कलेयियन आदर्शवाद का एक चरम रूप धारण करते हैं, दुनिया की वास्तविकता को नकारते हुए। उनकी दुनिया को समझा जाता है "अंतरिक्ष में वस्तुओं की सहमति के रूप में नहीं, बल्कि स्वतंत्र कृत्यों की एक विषम श्रृंखला के रूप में।" Tlön की कल्पना की गई भाषाओं में से एक में संज्ञाओं का अभाव है। इसकी केंद्रीय इकाइयाँ हैं "अवैयक्तिक क्रियाएं जो मोनोसैलिक प्रत्ययों या उपसर्गों द्वारा योग्य होती हैं जिनमें क्रियाविशेषण का बल होता है।" बोर्गेस ने एक टोलनिक को "पानी के ऊपर चाँद उगने" के बराबर सूची दी: hlör u fang axaxaxas mlö, जिसका शाब्दिक अर्थ है "ऊपर की ओर पीछे की ओर यह चन्द्रमा"। [...] ट्लोन की एक अन्य भाषा में, "मूल इकाई क्रिया नहीं है, बल्कि एककोशिकीय विशेषण है,", जो दो या अधिक के संयोजन में संज्ञा-स्वरूप हैं: "चंद्रमा" "गोल हवादार-प्रकाश" बन जाता है। अंधेरा "या"

( किताब के बारे में विकिपीडिया आर्टिस से कॉपी )

मेरे लिए, बिंदु इतना अधिक नहीं है कि दुनिया को हम जो करते हैं, उससे अलग माना जा सकता है, जो थोड़े क्लिच है, लेकिन वास्तविकता की संरचना की यह धारणा हमारे द्वारा बोली जाने वाली भाषा पर निर्भर करती है, यह एक स्वाभाविक या एक प्रोग्रामिंग भाषा है। Tlönese लिस्प के साथ बहुत खुश हो सकता है, और बहुत अस्वाभाविक के रूप में जावा (AKA द किंगडम ऑफ नाउन ) को देख सकता है, जबकि अधिकांश टेरान प्रोग्रामर कार्यात्मक भाषाओं पर उन्मुख वस्तु का पक्ष लेते हैं। मुझे दोनों शैलियों पसंद हैं, क्योंकि मुझे लगता है कि यह मुख्य रूप से परिप्रेक्ष्य का मामला है। कुछ समस्याओं को कार्यात्मक के साथ सबसे अच्छा हमला किया जाता है, कुछ अन्य वस्तु उन्मुख प्रोग्रामिंग तकनीकों के साथ। एक अच्छा प्रोग्रामर हमेशा विभिन्न कोणों से एक कठिन समस्या को देखता है, इससे पहले कि वह समाधान का प्रयास करे। या, एलन के के रूप में इसे रखा: देखने का बिंदु 80 IQ अंक के लायक है

तो, आपके प्रश्न का मेरा उत्तर है: आप किस वास्तविक दुनिया की बात कर रहे हैं? और कैसे?


"वास्तविकता की संरचना की यह धारणा हमारे द्वारा बोली जाने वाली भाषा पर निर्भर करती है, यह एक स्वाभाविक या एक प्रोग्रामिंग भाषा है"। यह वाकई में सच है!
जलवायु

4

जबकि मेरे द्वारा बनाई गई कुछ वस्तुएं वास्तविक दुनिया की वस्तुओं को मॉडलिंग कर रही हैं, क्या पूर्व-OOP कोड ऐसा नहीं करेंगे?

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


मुझे लगता है कि आप का मतलब है प्रक्रियात्मक कार्यात्मक नहीं।
विंस्टन एवर्ट

हाँ, सही है। मैं इसे बदल दूँगा
फुसफुसाएँ

3

मैंने देखा है कि आमतौर पर ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग को वास्तविक दुनिया में मॉडलिंग पर आधारित दोहराया जाता है, लेकिन क्या ऐसा है?

हाँ। यहां जोर पर आधारित है । OOP वास्तविक दुनिया का मॉडल नहीं बनाता है (यदि ऐसा होता है, तो संयोगवश) और यह माना नहीं जाता है। OOP हमें मॉडल प्रोग्रामिंग समस्याओं की अनुमति देता है जिस तरह से हम वास्तविक दुनिया को मॉडल करते हैं: संस्थाओं की एक प्रणाली के रूप में जो हमारे व्यवहार के हमारे अमूर्तन के माध्यम से परिभाषित होती है।


3
हाँ - तो यह वास्तविक दुनिया के मॉडलिंग पर आधारित नहीं है, है ना?
लेफ्टरनबाउट

3

OO कोड आमतौर पर वास्तविक दुनिया का मॉडल नहीं बनाता है - कम से कम यह लक्ष्य नहीं है, यह बस आपको अपने कोड के बारे में सोचने की अनुमति देता है जो अधिक प्राकृतिक है, जिस तरह से आप वास्तविक दुनिया में चीजों के बारे में सोचते हैं - यह वही है जो कहने की कोशिश कर रहा है।


3

यह हमारी दुनिया का मॉडल नहीं है, लेकिन यह हमारी दुनिया की मानवीय व्याख्या को दर्शाता है। मनुष्य स्वाभाविक रूप से वस्तुओं के रूप में चीजों को अलग कर लेता है। OO प्रभावी है क्योंकि यह मनुष्यों को उनके सोचने के तरीके को प्रोग्राम करने की अनुमति देता है।


2

ओओपी वास्तविक दुनिया और वहां निहित वस्तुओं का एक आदर्श मॉडल नहीं हो सकता है, लेकिन यह एक पद्धति है जो वास्तविक जीवन सॉफ्टवेयर की बढ़ती जटिलता से निपटने में मदद करती है। यह तार्किक रूप से संबंधित विखंडू को तोड़कर, कोड को बेहतर लिखने में भी मदद करता है।

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

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

मुझे लगता है कि ओओपी एक सिद्ध सहायता की तरह है जो आपको वास्तविक जीवन प्रणाली की सभी जटिलताओं से प्रभावी तरीके से निपटने की सुविधा देता है। इसलिए, जबकि यह वास्तविक दुनिया का बहुत गहन मॉडल नहीं हो सकता है, यह काफी करीब है और आपको सामान प्राप्त करने में मदद करता है, जो कि IMHO अंत में मायने रखता है।


2

मैंने देखा है कि आमतौर पर ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग को वास्तविक दुनिया में मॉडलिंग पर आधारित दोहराया जाता है, लेकिन क्या ऐसा है?

यह मुझे लगता है कि व्यापार परत के बाहर किसी भी चीज का सच नहीं है।

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

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

मॉडलिंग में, हम केवल उस मॉडल के पहलुओं पर ध्यान केंद्रित करते हैं जो हाथ में काम करने के लिए सार्थक हैं। यदि हम एक टाइम एंट्री सिस्टम डिजाइन कर रहे हैं, तो हम शायद कर्मचारी वर्ग के कुछ प्रकार चाहते हैं, लेकिन उस वर्ग को कर्मचारी के पसंदीदा रंग को व्यक्त करने के लिए संपत्ति की आवश्यकता नहीं है।

इसलिए, मॉडल को "वास्तविक दुनिया" का पूरी तरह से प्रतिनिधित्व करने का प्रयास (या बहाना) नहीं करना चाहिए।

जबकि मेरे द्वारा बनाई गई कुछ वस्तुएं वास्तविक दुनिया की वस्तुओं को मॉडलिंग कर रही हैं, क्या पूर्व-OOP कोड ऐसा नहीं करेंगे? मुझे संदेह है कि OO अपने कोड बेस में ग्राहक जैसी अवधारणाओं को शामिल करने वाले पहले व्यक्ति थे।

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

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

OOP और गैर-OOP के बीच सबसे बड़ा अंतर यह है कि OOP कोड को डेटा से बांधता है। इसलिए इस तरह से कॉलिंग कोड के बजाय:

verb(noun);

हम इसके बजाय ऐसा करते हैं:

noun->verb();

हालांकि यह एक व्याकरणिक अंतर की तरह लग सकता है, अंतर वास्तव में मानसिकता में है। हम वस्तुओं को बताते हैं कि क्या करना है, और आमतौर पर इस बात की परवाह नहीं करते हैं कि ऑब्जेक्ट की आंतरिक स्थिति या कामकाज क्या हैं। किसी वस्तु का वर्णन करते समय, हमें केवल उसके साथ काम करने के लिए सार्वजनिक इंटरफ़ेस का वर्णन करना होगा।


2

क्या ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग वास्तव में वास्तविक दुनिया का मॉडल है?

पूरी तरह से नहीं।

अच्छी तरह से वास्तविक दुनिया में, हम वास्तविक समस्याओं का सामना करते हैं। हम एक प्रतिमान का उपयोग करके इस समस्या को हल करना चाहते हैं जो उस प्रणाली की नकल करता है जिसे हम बनाना चाहते हैं जो मॉडल बन जाता है।

उदाहरण के लिए, यदि शॉपिंग कार्ट एप्लिकेशन हाथ में समस्या थी, तो हमारे पास अलग-अलग इकाइयां हैं

  1. उत्पाद जो एक अमूर्त शब्द है जिसमें कई सदस्य हो सकते हैं जैसे Books, Gadgets, Cars जो फिर से विभाजित हो सकते हैं।

  2. टैक्स क्राइटेरिया जैसे (सेल्स टैक्स) उस स्थान पर निर्भर करेगा जहां सॉफ्टवेयर को लागू किया जाता है क्योंकि यह सरकार की नीतियों के आधार पर परिवर्तन के अधीन है।

  3. टैक्स को इस आधार पर माना जाता है कि क्या उत्पाद कर मानदंडों के साथ आयात किया गया था।

  4. उपयोगकर्ता के पास शॉपिंग कार्ट हो सकती है जिसमें उत्पादों की सूची हो आदि।

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


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

2

मुझे लगता है कि आप एक बहुत ही समृद्ध, ऐतिहासिक, कथन के रूप में पढ़ रहे हैं। OO प्रोग्रामिंग, कक्षाएं, बहुरूपता, आभासी कार्यों इत्यादि के कई विचार, सिमुला भाषा में पेश किए गए, 1960 के दशक में वापस (http://en.wikipedia.org/wiki/Simula)। जैसा कि नाम से पता चलता है, सिमूला सिमुलेशन लिखने के लिए एक भाषा होने के लिए डिज़ाइन किया गया था। इसलिए ऐतिहासिक रूप से, हाँ, ओओ विचारों को "वास्तविक दुनिया" के मॉडल के प्रयास में पेश किया गया था। क्या वे अन्य शैलियों से अधिक सफल होते हैं, यह बहस का विषय है।


2

जबकि मेरे द्वारा बनाई गई कुछ वस्तुएं वास्तविक दुनिया की वस्तुओं को मॉडलिंग कर रही हैं, क्या पूर्व-OOP कोड ऐसा नहीं करेंगे?

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

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

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

लेकिन OO वास्तव में चीजों को मॉडल करने के तरीके के बारे में है, और मॉडलिंग की वह विधि मुझे वास्तविक दुनिया से प्रेरित नहीं लगती है।

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

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

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


1

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

इस विषय पर विकिपीडिया का लेख इसे अच्छी तरह से प्रस्तुत करता है:

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

जब तक आपका कार्यक्रम ब्रह्मांड सिमुलेशन नहीं है, तब तक आप केवल वास्तविक दुनिया के कुछ हिस्सों की परवाह करते हैं - इसलिए "मॉडल"। यह है कि मॉडल किस लिए हैं, वे आपको संरचना और कार्यक्षमता प्रदान करते हैं जिन्हें आपको प्रदर्शित करने की आवश्यकता है।

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

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


1

अपने उचित संदर्भ में ऑब्जेक्ट-ओरिएंटेशन के बारे में सोचने के लिए, आइए हम एब्सट्रैक्शन के एक स्तर को आगे बढ़ाएं और सामान्य रूप से प्रोग्रामिंग के बारे में बात करें, ठीक है?

भले ही आप ओओ या कार्यात्मक दृष्टिकोण अपनाएं, आपके कार्यक्रम को कुछ करना है, है ना? कार्यक्रम का पूरा बिंदु उत्तेजनाओं के एक निश्चित सेट को देखते हुए कुछ व्यवहारों का प्रदर्शन करना है। इसलिए कि कार्यक्रम सभी पर मौजूद हैं, क्योंकि वे कुछ करते हैं। यहाँ प्रमुख शब्द व्यवहार है

किसी प्रोग्राम को किन व्यवहारों को लागू करना चाहिए, इस पर विचार करने के अलावा, आपके प्रोग्राम को आमतौर पर कुछ गुणों का प्रदर्शन करने की आवश्यकता होती है। उदाहरण के लिए, हृदय-निगरानी कार्यक्रम के लिए यह आवश्यक नहीं है कि इसके लिए आवश्यक व्यवहार हों - यह आमतौर पर वास्तविक समय में काम करने के लिए जल्दी से पर्याप्त रूप से निष्पादित करने की आवश्यकता होती है। अन्य "गुण" जिन्हें एक कार्यक्रम को प्रदर्शित करने की आवश्यकता हो सकती है: सुरक्षा, लचीलापन, प्रतिरूपकता, विस्तारशीलता, पठनीयता, और इसी तरह। हम इन वास्तुकला गुणवत्ता गुण कहते हैं । इसलिए हम कह सकते हैं कि हमारे कार्यक्रम को कुछ व्यवहार (कार्यात्मक) लक्ष्यों के साथ-साथ कुछ गुणों (गैर-कार्यात्मक) का प्रदर्शन करने की आवश्यकता है।

अब तक, इसमें से किसी ने भी ओओ के बारे में बात नहीं की है, है? चलो अब वही करते हैं।

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

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

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

जब आप "पर्यवेक्षकों, प्रबंधकों, कारखानों, आदि" जैसी चीजों के बारे में पढ़ते हैं, तो आप OO पैटर्न लागू कर रहे हैं जो आपके प्रोग्राम को कुछ गुणों को प्रदर्शित करने में मदद करता है जो उपयोगी होने के लिए आवश्यक हो सकते हैं। वे "सिद्ध प्राप्तकर्ता" हैं जो "काम करते हैं", यह देखते हुए कि आपकी ज़रूरतें उस समस्या से मेल खाती हैं जो पैटर्न हल करती है।

मुझे आशा है कि आपको यह समझने में मदद मिलेगी कि OO और कार्यात्मक प्रतिमानों के बीच बहुत पक्षपाती दिखने के बिना OO क्या है।


1

ओओपी प्रोग्रामिंग दृष्टिकोण से एक अच्छा मॉडल बनाता है, यह वास्तविक दुनिया को प्रतिबिंबित नहीं करता है।

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

apply_discount_of 5.percent:
         when order.Total > 1000 and customer.IsPreferred
         when order.Total > 10000

suggest_registered_to_preferred:
         when order.Total  > 100 and not customer.IsPreferred

एक अन्य उदाहरण घेरकिन भाषा के आधार पर स्वचालित उपयोगकर्ता स्वीकृति परीक्षण ढांचा होगा ।

Feature: Some terse yet descriptive text of what is desired
    In order to realize a named business value
    As an explicit system actor
    I want to gain some beneficial outcome which furthers the goal

Scenario: Some determinable business situation
    Given some precondition
        And some other precondition
    When some action by the actor
        And some other action
        And yet another action
    Then some testable outcome is achieved
        And something else we can check happens too

0

यह आप पर निर्भर है, आखिरकार। लेकिन OOP एक सटीक तरीका है जो संरचित या प्रक्रिया-उन्मुख प्रोग्रामिंग जैसी अन्य कार्यप्रणालियों की तुलना में ऐसा करता है। प्रक्रियात्मक प्रक्रिया संभवतः आपकी समस्याओं को हल कर सकती है लेकिन OOP का पालन करने से आप जीवन को अधिक आसान बना सकते हैं।

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