केवल संरचनात्मक और वस्तु प्रोग्रामिंग प्रतिमान हैं

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

कई लोगों के लिए इस विषय का शीर्षक अब बहुत विवादास्पद (और जानबूझकर उत्तेजक, लेकिन व्यापार के लिए :)) दिखा सकता है। लेकिन फिर भी, हम इसे यहाँ सही ठहराने की कोशिश करेंगे और यह समझेंगे कि एक प्रोग्रामिंग प्रतिमान में कौन से गुण होने चाहिए, जिन्हें एक प्रतिमान कहा जा सकता है।

मैं केवल पूछता हूं कि क्या आप तिरछे पढ़ते हैं - संयमित टिप्पणी।



फ़्लॉइड हमें प्रतिमानों के बारे में क्या बताता है?

"प्रोग्रामिंग प्रतिमान" शब्द को रॉबर्ट फ्लॉयड ('' आरडब्ल्यू फ्लोयड। '' [Http://www.ias.ac.in/resonance/May2005/pdf/May2005Classics.pdf प्रोग्रामिंग के प्रतिमान] '' ACM के संचार '' द्वारा तैयार किया गया था। ', २२ (,): ४५५-४६०, १ ९ 22 ९। पुस्तक में रूसी अनुवाद देखें: लेक्चरस फ्रॉम ट्यूरिंग प्राइज़ लॉरेट्स फ़ॉर द फर्स्ट ट्वेंटी ईयर्स (१ ९६६-१९ )५), मॉस्को: एमआईआर, १ ९९ ३।)। 1979 में अपने व्याख्यान में, वे निम्नलिखित के बारे में बात करते हैं:

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

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

'' 'संरचनात्मक प्रोग्रामिंग प्रतिमान' '' की तुलना में उच्च स्तर के अमूर्तता के प्रतिमान '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ ’’ की की कृति से उच्च स्तरीय अमूर्तता का प्रतिमान '' '' '' '' '' '' '' '' '' '' '' '' 'ट्रान्जेक्शनल प्रोग्रामिंग प्रतिमान ’’ की तुलना में, भाषाओं के एक पदानुक्रम का निर्माण, जहाँ अमूर्त वस्तुओं के उच्चतम स्तर की भाषा में कार्यक्रम होते हैं, और अगले निचले स्तर की भाषा के कार्यक्रमों में उनका अनुवाद करते हैं। स्तर।

उच्च स्तरीय प्रतिमानों की विशेषताएं

फिलहाल, सॉफ्टवेयर बनाते समय सभी संभावित प्रतिमानों को एक ही स्तर पर संभव विकल्पों पर विचार करने की प्रवृत्ति है। लेकिन ऐसा है नहीं। प्रतिमान विनिमेय नहीं हैं।

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

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

लेकिन हमारे सवाल पर वापस: विभिन्न विषयों पर प्रतिमान क्या लागू होता है? लेकिन इसका उत्तर देने के लिए हमें एक ऐतिहासिक भ्रमण करने की आवश्यकता है।

संरचनात्मक प्रोग्रामिंग प्रतिमान की बुनियादी बातों

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

लेकिन सिद्धांत एक बात है, और अभ्यास एक और है। इस लिहाज से यह विचार करने की जरूरत है कि 1975 तक क्या स्थिति थी। यह स्पष्ट रूप से ई। योडान ([http://www.az-design.ru/index.shtml?Projects&AzBook&src/005/02YE000 Yodan E. की संरचना और कार्यक्रमों का निर्माण, 1975: 1975) में देखा गया है। इस पर विचार करना महत्वपूर्ण है क्योंकि अब, 30 से अधिक वर्षों के बाद, सिद्धांत पहले से ही अच्छी तरह से ज्ञात हैं, अब फिर से खोजे गए हैं, और एक नए रैंक पर उठाए गए हैं। लेकिन एक ही समय में, ऐतिहासिक संदर्भ खो जाता है, और इन सिद्धांतों के महत्व का पदानुक्रम प्राथमिक है और प्राथमिक क्या है। यह अनाकार स्थिति बहुत अच्छी तरह से प्रोग्रामिंग की वर्तमान स्थिति का वर्णन करती है।

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

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

उल्लेखनीय, प्रोग्रामर के बीच एक काफी विशेषता विवाद:
* प्रोग्रामर ए: "मेरा कार्यक्रम आपकी तुलना में दस गुना तेज है, और यह तीन गुना कम मेमोरी लेता है!"
* प्रोग्रामर बी: "हाँ, लेकिन आपका कार्यक्रम काम नहीं कर रहा है, और मेरा काम कर रहा है!"

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

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

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

इसके अलावा, ध्यान मॉड्यूल के आकार और अपरिवर्तनीयता पर था। इसके अलावा, मॉड्यूल की अपरिहार्यता के संबंध में, इसकी संपूर्णता पर विचार नहीं किया गया था, लेकिन व्यक्तिगत कारकों के आवंटन के साथ:
1. कार्यक्रम की तार्किक संरचना, अर्थात एक एल्गोरिथ्म। यदि पूरा कार्यक्रम कुछ विशेष दृष्टिकोण पर निर्भर करता है, तो एल्गोरिथ्म को बदलते समय कितने मॉड्यूल में बदलाव करना आवश्यक होगा?
2. मॉड्यूल के तर्क, या पैरामीटर। यानी इंटरफ़ेस विनिर्देशन परिवर्तन
3. आंतरिक तालिका चर और स्थिरांक। कई मॉड्यूल सामान्य तालिकाओं पर निर्भर करते हैं, अगर ऐसी तालिकाओं की संरचना बदल जाती है, तो हम उम्मीद कर सकते हैं कि मॉड्यूल भी बदल जाएंगे।
4. डेटाबेस की संरचना और प्रारूप। अधिक हद तक, यह निर्भरता ऊपर उल्लिखित सामान्य चर और तालिकाओं पर निर्भरता के समान है, इस अंतर के साथ कि व्यावहारिक दृष्टिकोण से यह कार्यक्रम के स्वतंत्र डेटाबेस पर विचार करने के लिए अधिक सुविधाजनक है।
5. कार्यक्रम प्रबंधन की मॉड्यूलर संरचना। कुछ लोग वास्तव में यह कैसे उपयोग किया जाएगा के बारे में सोचने के बिना एक मॉड्यूल लिखते हैं। लेकिन अगर आवश्यकताएं बदल गई हैं। मॉड्यूल की तार्किक संरचना के किस हिस्से को हमें बदलना होगा?

ये और कई अन्य पहलू (जिन्हें हमने यहां नहीं माना है) सामान्य रूप से संरचनात्मक प्रोग्रामिंग का विचार तैयार करते हैं। इन पहलुओं की देखभाल संरचनात्मक प्रोग्रामिंग को उच्च-स्तरीय प्रतिमान बनाती है।

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग पैराडाइम के मूल

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

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

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

प्रोग्रामिंग डेवलपमेंट के प्रत्येक चरण में, कार्यक्रमों की बढ़ती जटिलता को रोकने के लिए तरीके और उपकरण दिखाई दिए। और ऐसे प्रत्येक चरण में, नए दृष्टिकोण ने पिछले वाले से सभी को अवशोषित किया, प्रोग्रामिंग में प्रगति को चिह्नित किया। OOP के बारे में भी यही कहा जा सकता है। ओओपी से पहले, कई परियोजनाएं (और कभी-कभी पार हो गई) की सीमा से परे प्रोग्रामिंग के लिए संरचनात्मक दृष्टिकोण निष्क्रिय हो गया। इसलिए, कार्यक्रमों की जटिलता से जुड़ी कठिनाइयों को दूर करने के लिए, OOP की आवश्यकता उत्पन्न हुई। ((http://www.williamspublishing.com/Books/978-5-8459-1684-6.html हर्बर्ट शिल्ड्ट, सी # 4.0 संपूर्ण गाइड, 2011]]

इस कारण को समझने के लिए कि ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग ने अधिक जटिल प्रोग्राम लिखना और व्यावहारिक रूप से जटिलता की सीमा की समस्या को समाप्त करना संभव बना दिया है, हम OOP, ग्रैडी बुचु ([http://www.helloworld.ru/texts/comp/other] के संस्थापकों में से एक की ओर मुड़ते हैं। /up/index.htm ग्रैडी बुच, ऑब्जेक्ट ओरिएंटेड एनालिसिस एंड डिज़ाइन])। उन्होंने ओओपी के बारे में अपने स्पष्टीकरण की शुरुआत की कि किस जटिलता का मतलब है और किन प्रणालियों को जटिल माना जा सकता है। यही है, उद्देश्यपूर्ण रूप से जटिल कार्यक्रमों को लिखने के मुद्दे पर पहुंचता है। इसके बाद, हम इस जटिलता को समझने के लिए जटिलता और मानवीय क्षमताओं के संबंध के प्रश्न की ओर मुड़ते हैं:

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

फिर वह सड़ने की बात करता है:

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

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

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

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

मॉडलिंग प्रकृति की नकल है, इसके कुछ गुणों को ध्यान में रखते हुए। ? - ? नहीं। , . , , . , , , , . , , , . , . , : , , , , , «» , -. . , , , . . . : , , , , , . ( « », , 1967)

इस प्रकार, एस। लेम मॉडलिंग के आधार के रूप में अमूर्तता की बात करता है। इसी समय, अमूर्तता एक वस्तु-उन्मुख प्रतिमान की मुख्य विशेषता है। श्री बुच इस बारे में लिखते हैं:

, , — . : « . ». ? «» , , , . , , « , ». . : « … , — , — , — , — , , , — ».

और फिर वह उन महत्वपूर्ण सार को चुनने की बात करता है जिनकी हमें आवश्यकता है:

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

, : . , : , . , , , . , «, , »; — . , , , , , , . , .

— .

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

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

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