एक कार्यक्रम को कई वर्गों में विभाजित करना क्यों अच्छा है? [बन्द है]


62

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

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

यह परियोजना जावा में थी और मैं इस रिकॉर्ड पर काम करने वाला एकमात्र व्यक्ति हूं।


1
सॉफ्टवेयर के प्रत्येक टुकड़े को और अधिक सरल बनाने के लिए! infoq.com/pretations/Simple-Made-Easy-QCon-London-2012
TehShrike

49
जब आप अपनी किताबें पढ़ते हैं, तो क्या वे अध्यायों और वर्गों में विभाजित थे? हम चीजों को व्यवस्थित करने के लिए एक कार्यक्रम को कक्षाओं में विभाजित करते हैं, जैसे किताबें चीजों को व्यवस्थित करने के लिए पाठ को अध्यायों में विभाजित करती हैं।
रिवालक

12
रोमन कहा करते थे: विभाजित ई तप।
जियोर्जियो

7
@ जियोर्जियो: या अंग्रेजी में, क्योंकि लैटिन में अब किसी भी तरह का उपयोग नहीं किया जाता है: विभाजन और जीत
Matthieu M.

40
ध्यान में रखते हुए आप 10 वीं कक्षा में हैं, और पहले से ही एक बुद्धिमान प्रश्न बनाने में सक्षम हैं, जो अच्छे उत्तरों के लिए आवश्यक सभी विवरण प्रदान करते हैं, संदर्भ प्रदान करते हैं, और आपके रिश्तेदार अनुभव, साथ ही पृष्ठभूमि की जानकारी भी पूछते हैं कि आप सवाल क्यों पूछ रहे हैं; आप पहले से ही ऐसे कई लोगों से अधिक योग्य हैं, जिनके साथ मैं वर्तमान में काम करता हूं ...
कैफ़ीक गीन

जवाबों:


71

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

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

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


7
प्रोग्रामिंग में बहुत सी अवधारणाएं / विचार (OO- सिद्धांत, वितरित स्रोत नियंत्रण, कोडिंग मानक) केवल तभी समझ में आते हैं जब आप किसी टीम में अपेक्षाकृत बड़ी परियोजनाओं पर काम करते हैं। जब आप वास्तव में इस तरह की परियोजनाओं पर काम करेंगे तो आपको समझ में आएगा।
joshin4colours

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

2
कुछ प्रमुख शब्द "युग्मन" या "डिकॉप्लिंग", "एनकैप्सुलेशन", "सूचना छिपाना" होगा।
मार्कतानी

@ ब्रेनलैंग, मैं सहमत हूं और मैं यह भी जोड़ूंगा कि एनकैप्सुलेशन लगभग असंभव है। जब तक आप पाठ्यक्रम के अलग-अलग कार्यक्रम नहीं लिख रहे हैं ... लेकिन आमतौर पर कई भाग ऐसे होते हैं जो एक-दूसरे पर निर्भर नहीं होते हैं, लेकिन केवल निर्भरताएं साझा होती हैं
जो तो

29

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

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

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


12

यह अच्छा प्रश्न है! सरल और अच्छी तरह से पूछा। खैर ... इसका उत्तर किसी ऐसे छात्र के लिए समझना इतना आसान नहीं है जो कंप्यूटर साइंस की पढ़ाई कर रहा है और शायद उसे गहरे ओओ में नहीं पता है और शायद उसके पास अनुभव भी नहीं है।

इसलिए, मैं एक परिदृश्य का वर्णन करके और आपको यह कल्पना करने पर जवाब दे सकता हूं कि बहु-स्तरीय सॉफ़्टवेयर अखंड सॉफ़्टवेयर से बेहतर कैसे है (केवल एक वर्ग द्वारा बनाया गया है):

  • पठनीयता : कई छोटी और संगठित फाइलों की तुलना में 10000 लाइनों वाली फाइल के अंदर कोड को ब्राउज़ करना और लिखना बहुत कठिन है।
  • पुन: प्रयोज्य : यदि आप एक एकल वर्ग लिखते हैं, तो आप कोड दोहराव में फिसल सकते हैं । इसका मतलब है कोड की अधिक लाइनें और शायद अधिक बग (!)
  • परीक्षण क्षमता : एक एकल कार्यक्षमता के परीक्षण के बारे में क्या? यदि आप एक कक्षा में एक तर्क कार्यक्षमता को अलग करते हैं, तो आपका जीवन आसान हो जाएगा।
  • कोड अनुरक्षण : आप एक बग को ठीक कर सकते हैं या एक ही स्थान पर मल्टीप्लाई कक्षाओं के साथ कार्यक्षमता बढ़ा सकते हैं: अच्छी छोटी कक्षाएं।
  • प्रोजेक्ट संरचना : oooooh आप कल्पना कर सकते हैं कि केवल एक स्रोत फ़ाइल वाली परियोजना कितनी बदसूरत दिखाई देगी?

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

मैं कहूंगा कि चिंताओं को अलग करना, सामंजस्य और पतन एक अवधारणा है जो ओओपी के अनुशासन की तुलना में उच्च गुंजाइश पर है। इम्पीरेटिव, लॉजिकल और फंक्शनल प्रोग्रामर समान रूप से उच्च सामंजस्य और कम युग्मन के लिए सभी प्रयास करते हैं।
सारा

8

यहाँ बहुत सारे अच्छे उत्तर हैं, और मैं निश्चित रूप से उनसे सहमत हूँ, लेकिन मुझे लगता है कि कुछ और ध्यान देने योग्य बात है।

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

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

किसी के सिर में एक कार्यक्रम धारण करना। जियोर्जियो से लिंक


1
+1: टीम वर्क भी महत्वपूर्ण है! उदाहरण के लिए देखें paulgraham.com/head.html और शीर्षक के साथ पैरा "कोड के समान टुकड़े को संपादित करने वाले कई लोग नहीं हैं।"
गियोर्जियो

@ जियोर्जियो I केवल इसके माध्यम से स्किम्ड है, लेकिन एक भयानक संसाधन की तरह लगता है! मैं इसे केवल अपने उत्तर में जोड़ूंगा क्योंकि कुछ लोग टिप्पणी अनुभाग में नहीं दिख सकते हैं। निश्चित रूप से इसे और अधिक पूरी तरह से कुछ समय देने के लिए जा रहा है।
सेपल्हिया

यह संशोधन नियंत्रण पर भी लागू होता है - अलग-अलग फ़ाइलों पर काम करने का मतलब कम संघर्ष और विलय है।
मोनिका

7

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

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

जैसा कि गेराल्ड सूसमैन ने कहा कि हमारे कार्यक्रमों को पहले लिखा जाना चाहिए ताकि लोग इसे पढ़ सकें और दूसरा ताकि कंप्यूटर इसे चला सकें। (और यदि आपने nto read किया है "तो कंप्यूटर प्रोग्राम्स की संरचना और व्याख्या अभी तक आपको चाहिए)


4

एक से अधिक वर्गों का उपयोग करता है क्योंकि जब आप बड़े सामान में आते हैं तो आप पाएंगे कि कोई भी तरीका नहीं है जब आप कोड का एक बड़ा ढेर लगाते हैं तो आप हर चीज पर नज़र रख सकते हैं।

आपको बस इसे संभालने के लिए विभाजित और जीतना है।


3

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

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

तब सभी सबरूटीन्स इसी तरह से टूट जाती हैं जब तक कि कोड की कुछ पंक्तियाँ बिना किसी विधि कॉल के काम नहीं करेंगी। एक मुख्य कार्यक्रम जो कुछ विधियों को कॉल करता है, जिनमें से प्रत्येक कुछ विधियों को कॉल करता है, जिनमें से प्रत्येक .... काम करने वाले छोटे सरल तरीकों के लिए। इस तरह, आप एक बहुत बड़े कार्यक्रम (या छोटे कार्यक्रम) के किसी भी हिस्से को देख सकते हैं और जल्दी से समझ सकते हैं कि यह क्या करता है।

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

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


0

लाभों में से एक पुन: प्रयोज्य है। एक कार्यक्रम मूल रूप से एक गुच्छा निर्देश है जिसे एक साथ समूहीकृत किया गया है। आप पाएंगे कि उनमें से कुछ निर्देश अन्य कार्यक्रमों के लिए भी उपयुक्त हैं।

मान लीजिए कि आप एक कूदने का खेल बनाते हैं। बाद में जब आप एक तोप का खेल बनाने का फैसला करते हैं, तो आप पाते हैं कि कूदने के खेल में आपके द्वारा उपयोग की गई भौतिकी गणना यहाँ काम आती है।

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


0

सबसे पहले, ध्यान दें कि मैं एक सी ++ और पायथन हूं, जावा नहीं, इसलिए यह कुछ पूरी तरह से लागू नहीं हो सकता है। कृपया मुझे सही करें अगर मैं जावा में कक्षाएं कैसे काम करता हूं, इसके बारे में कुछ गलत धारणाएं हैं।

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

हालाँकि, यह वह जगह नहीं है जहाँ कक्षाएं चमकती हैं। Stringकक्षा पर विचार करें : आपके पास charसरणियों और कुछ स्थिर कार्यों का उपयोग करके सभी समान विशेषताएं हो सकती हैं । इस बिंदु पर, फ़ंक्शन आपको थोड़ी अतिरिक्त सुरक्षा और सिंटैक्टिक चीनी देते हैं। आप string.length()इसके बजाय लिख सकते हैं length(char_array); यह बहुत बड़ी बात नहीं है, लेकिन बहुत से लोग अभी भी इसे पसंद करते हैं। इसके अलावा, आप जानते हैं कि अगर किसी ने आपको एक दिया String, तो यह Stringनिर्माणकर्ता के साथ बनाया गया था और यह lengthफ़ंक्शन के साथ काम करना चाहिए - यदि सरणी संस्करण कुछ वर्ण को संभाल नहीं सकता है, तो आपको इसे वहां डालने से रोकने का कोई तरीका नहीं है। ।

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

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


0

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


0

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

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

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