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

" मुझे नहीं पता कि ओओपी " जैसे लेखों की उपस्थिति के बाद - स्पष्ट करने की इच्छा है, "आंसुओं को ढंकना" और "सच्चाई की तह तक पहुंचना"।

ऑब्जेक्ट ओरिएंटेशन सिद्धांत

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

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

"विधियों" के आगमन के साथ, कार्यक्षमता के संगठन के बारे में एक और सुखद क्षण सामने आया: नामों के क्रॉस-डुप्लिकेट किए गए पहले और दूसरे हिस्सों के साथ 900 कार्यों को बनाने के बजाय (वर्डबैसिक याद रखें?), आप प्रत्येक में 30 विधियों के साथ 30 कक्षाएं बना सकते हैं।

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

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

आलोचना। विरासत। इंटरफेस का जन्म

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

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

एक अन्य इंटरफ़ेस अच्छा है कि यह एक गैर-कार्यात्मक भाषा के लिए एक कार्यात्मक प्रतिमान को लागू करता है, जिससे आप वास्तव में एक तर्क के रूप में एल्गोरिदम का एक सेट पास कर सकते हैं।

आलोचना। क्यों कुछ "वास्तविक" कक्षाएं हैं। बहु प्रेषण। "प्रबंधकों" का जन्म और डोमेन ऑब्जेक्ट्स से उनका अलगाव। एकमात्र

यह माना जाता है कि एक वर्ग गुण "व्यवहार" का एक सेट है। मैं VisualBasic 5 की मदद से 1998 में पढ़े गए शब्दों को याद करता हूं, कुछ इस तरह है: “विधि वह है जो आप ऑब्जेक्ट को करने के लिए कहते हैं। घटना वह है जो वस्तु आपको बताती है कि उस पर क्या किया गया है । " तो "व्यवहार" के बारे में क्या अभी भी एक सवाल है - एक विधि या कुछ और।

डिज़ाइन व्यवहार तब शुरू होता है जब "व्यवहार" में दो या अधिक वर्ग शामिल होते हैं। यहाँ टिप्पणी के रूप में - "ऊँचाई, वजन, आयु - गुण। चलने के लिए, cn (p) व्यवहार है। "यहाँ, अक्षर" p "के साथ मॉडलिंग व्यवहार के मामले में, More Than और कहाँ हैं (और" walk "भी - जहाँ भी है)। सामान्य तौर पर, जब ऑब्जेक्ट मॉडल का विकास करते समय कई गैर-आदिम वर्ग कार्रवाई में शामिल होते हैं, तो सवाल उठता है - दो, तीन, चार, आदि में से कौन सा। कक्षाएं - इस मामले में, "कौन", "द्वारा" या "कहां" - क्या इस क्रिया को मॉडलिंग करने का तरीका होना चाहिए? और किसी भी मामले में, यह सबसे अधिक संभावना है कि यह तंग युग्मन होगा और सिस्टम के आगे निर्माण की प्रक्रिया में (और लगातार पूरा होने, विस्तार और सुधार को एक नियमित रूप से माना जाना चाहिए, न कि एक असाधारण स्थिति) "बग़ल में बाहर आ जाएगा"।

इस समस्या को एक विशेष इकाई - " प्रबंधक " को उजागर करके हल किया जाता है। नतीजतन, "बैंक खाते" के प्रकार के पास ट्रांसफर_ऑन (खाता, राशि) के लिए एक विधि नहीं है, लेकिन इसके बजाय "खाता प्रबंधक" टाइप की वस्तु में ट्रांसफर_एस_ना (s_account, to_account, राशि) का एक तरीका है।

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

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

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

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

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

आलोचना। "मुझे एक पुनर्निर्मित निर्माता चाहिए।" फ़ैक्टरी

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

कारखाने में कुछ और फायदे हैं: 1) यह शून्य और 2 वापस कर सकता है) यह एक ही वस्तु को कई बार वापस कर सकता है।

आलोचना। आदिम और अन्य मूल्य वस्तुएं। Immutabelnost। Internizatsiya।

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

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

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

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

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

IRL वर्ग। आलोचना। "कुछ कक्षाएं दूसरों की तुलना में अधिक समान हैं"

"समानता" की कक्षाओं के पिरामिड के शीर्ष के करीब और कक्षाओं की समानता का उल्लंघन किया जाता है। खासकर तब जब आप खुद को "ऑब्जेक्ट ओरिएंटेड" रनटाइम वातावरण में लपेटना चाहते हैं।

जावा में, सभी वर्गों के लिए रूट क्लास ऑब्जेक्ट क्लास है। लेकिन ऑब्जेक्ट क्लास में एक getClass () विधि होती है जो टाइप क्लास की एक ऑब्जेक्ट लौटाती है, और एक StString () विधि जो टाइप स्ट्रिंग की ऑब्जेक्ट लौटाती है। इसके अलावा CloneNotSupportedException, InterruptedException, IllegalArgumentException और Throwable फेंकने के तरीके हैं। इसी समय, क्लास, थ्रोएबल और स्ट्रिंग क्लासेज ऑब्जेक्ट क्लास के डायरेक्ट वंशज हैं, और CloneNotSupportedException, InterruptedException और IllegalArgumentException और भी अधिक अप्रत्यक्ष हैं। सामान्य तौर पर, एक वर्ग जिसके पास अपने कुख्यात वंशजों के लिए आधे तरीके और लिंक होते हैं, अक्सर अप्रत्यक्ष होता है, एक खराब डिजाइन (किसी चक्रीय निर्भरता की तरह), लेकिन "यदि आप नहीं कर सकते हैं, लेकिन वास्तव में इसकी आवश्यकता है, तो आप एक बार कर सकते हैं।" और अपवादों और त्रुटियों के लिए जड़ वर्ग - थ्रोबेबल - में इसके अप्रत्यक्ष वंशजों के संदर्भ भी शामिल हैं: IllegalStateException और IllegalArgumentException, इसलिए, फिर से, एक सीमित खुराक में "एक हठधर्मिता नहीं"।

हालांकि, स्ट्रिंग और क्लास कक्षाएं अंतिम हैं, अर्थात्। वंशज नहीं हो सकते हैं, जो ऑब्जेक्ट क्लास में उनके उपयोग के "अपराधीत्व" को कम करता है।

IRL वर्ग। आखिरकार उन्होंने क्या किया

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

वंशानुक्रम, साथ ही एक डोमेन ऑब्जेक्ट के वर्ग के लिए एल्गोरिदम का लगाव, तंग युग्मन और बुरे अभ्यास के रूप में पहचाना जाता है, और इसे खुराक में सख्ती से लागू किया जाता है। विशेष रूप से, विभिन्न सामाजिक नेटवर्क के साथ काम करने वाले एक कार्यक्रम के लिए "सोशल अकाउंट" इकाई को लागू करने का पसंदीदा तरीका एफबीएक्वाइन, वीकेएकाउंट और ट्विटरएक्वांट के वंशज के साथ एक एब्सट्रैक्ट सोशलएक्ाउंट क्लास बनाना नहीं है, बल्कि एक सामान्य सोशलएक्वाइन डोमेन वर्ग और कारखानों को डेटा से परिवर्तित करना है। विभिन्न सामाजिक नेटवर्कों से, शायद JSON-to-SocialAccount-कन्वर्टर्स से भी। ORM की याद दिलाता है? इसलिए लगभग 10 साल पहले सब कुछ वापस आ गया था: डीबी-दृढ़ता मंच वितरित किए गए थे जिसमें डेटाबेस के पढ़ने / लिखने का तर्क खुद को लगातार कक्षाओं के तरीकों में था, जिसके कारण उन्हें कुछ डीबीईएक्सएक्टिव ऑबजेक्ट जैसे विशेष वर्ग से विरासत में मिला था। इसके बाद, "जैसा कि आप जानते हैं," उन्होंने इसे मना कर दिया।

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

और "सामान्य", "शास्त्रीय" गुण, विधियों और विरासत वाले वर्ग मुख्य रूप से एप्लिकेशन सर्वर और अन्य पुस्तकालयों में पाए जाते हैं।

UPD : टिप्पणियों ने सही ढंग से सुझाव दिया कि "सख्त" टाइपिंग के बारे में नहीं, बल्कि "स्थिर" के बारे में बोलना आवश्यक था। मैं नियमित रूप से भ्रमित करता हूं, और एक नहीं।