📍 🔰 💭 तस्वीरों में ओ.ओ.पी. 📵 🤹🏻 🦔

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

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

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

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

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

वर्ग और वस्तुएँ

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

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

इस प्रकार, एक वर्ग इस बात का वर्णन है कि किसी वस्तु के पास क्या गुण और व्यवहार होगा। और एक वस्तु इन गुणों की अपनी स्थिति के साथ एक उदाहरण है।

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

कुल मिलाकर, हमारे पास ऐसे तरीके और गुण हैं जो कि विशेषता हैं। विशेषताओं के साथ कैसे काम करें? अधिकांश PLs में, विशेषता संदर्भ ऑपरेटर बिंदु है (PHP और पर्ल को छोड़कर)। यह कुछ इस तरह दिखता है (छद्म कोड):

//       class class Transformer(){ //   x int x //    (     0) function constructor(int x){ //   x // (  0    ) this.x = x } //   run function run(){ //      this this.x += 1 } } //    : //        0 optimus = new Transformer(0) optimus.run() //    print optimus.x //  1 optimus.run() //      print optimus.x //  2

तस्वीरों में मैं निम्नलिखित संकेतन का उपयोग करूंगा:

मैंने UML चित्र का उपयोग नहीं किया, उन्हें अपर्याप्त रूप से देखते हुए, अधिक लचीलेपन के साथ।

एनीमेशन नंबर 1

हम कोड से क्या देखते हैं?

1. यह एक विशेष स्थानीय चर (तरीकों के अंदर) है जो किसी वस्तु को अपने तरीकों से अपनी विशेषताओं तक पहुंचने की अनुमति देता है। मैं आपका ध्यान केवल अपनी ओर आकर्षित करता हूं, अर्थात, जब ट्रांसफार्मर अपनी स्वयं की विधि कहता है, या अपनी स्थिति बदलता है। यदि कॉल बाहर से optimus.x जैसा दिखता है, तो अंदर से, यदि ऑप्टिमस अपने क्षेत्र x को स्वयं संदर्भित करना चाहता है, तो उसकी विधि में कॉल इस तरह दिखाई देगा। x , अर्थात, " I (ऑप्टिमस) मेरे विशेषता x को संदर्भित करता है "। अधिकांश भाषाओं में, इस चर को यह कहा जाता है, लेकिन अपवाद हैं (उदा। स्व)

2. कंस्ट्रक्टर एक विशेष विधि है जिसे किसी ऑब्जेक्ट के बनने पर स्वचालित रूप से कहा जाता है। निर्माता किसी भी अन्य विधि की तरह, किसी भी तर्क को स्वीकार कर सकता है। प्रत्येक भाषा में, एक निर्माता को उसके नाम से संकेत दिया जाता है। कहीं ये विशेष रूप से __construct या __init__ जैसे आरक्षित नाम हैं, और कहीं निर्माणकर्ता का नाम वर्ग के नाम से मेल खाना चाहिए। कंस्ट्रक्टरों का उद्देश्य ऑब्जेक्ट को इनिशियलाइज़ करना है, आवश्यक फ़ील्ड भरना है।

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

4. कंस्ट्रक्टर और रन विधियां आंतरिक स्थिति के साथ काम करती हैं, लेकिन अन्य सभी मामलों में सामान्य कार्यों से भिन्न नहीं होती हैं । यहां तक कि घोषणा के वाक्य विन्यास से भी मेल खाता है।

5. कक्षाओं में वे विधियाँ हो सकती हैं, जिनमें राज्य की आवश्यकता नहीं होती है और परिणामस्वरूप, एक वस्तु बनाते हैं। इस स्थिति में, विधि स्थिर है ।

SRP

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

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

की एसोसिएशन

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

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

 class Gun(){ //    int ammo_count //    function constructor(){ //  this.reload() //    "" } function fire(){ //    "" this.ammo_count -= 1 //      } function reload(){ //   "" this.ammo_count = 10 //     } } class Transformer(){ //    Gun gun_left //   " "   Gun gun_right //   " "    /*            ,    */ function constructor(Gun gun_left, Gun gun_right){ this.gun_left = gun_left //      this.gun_right = gun_right //      } //    "",   ... function fire(){ //  ,    "" this.gun_left.fire() //    ,     "" this.gun_right.fire() } } gun1 = new Gun() //    gun2 = new Gun() //    optimus = new Transformer(gun1, gun2) //  ,

एनिमेशन नंबर २

this.gun_left.fire () और this.gun_right.fire () चाइल्ड ऑब्जेक्ट्स के लिए कॉल होते हैं जो डॉट्स के माध्यम से भी होते हैं। पहले बिंदु पर, हम बंदूक की वस्तु को प्राप्त करते हुए अपने आप को (this.gun_right) की विशेषता की ओर मोड़ते हैं, और दूसरे बिंदु पर, हम बंदूक वस्तु (this.gun_right.fire ()) की विधि की ओर मुड़ते हैं।

नीचे पंक्ति: रोबोट बनाया गया था, सेवा हथियार जारी किया गया था, अब हम यह पता लगाएंगे कि यहां क्या हो रहा है। इस कोड में, एक ऑब्जेक्ट किसी अन्य ऑब्जेक्ट का एक अभिन्न अंग बन गया है। यह संघ है। यह, बदले में, दो प्रकार का होता है:

1. रचना - ट्रांसफार्मर कारखाने में, ऑप्टिमस इकट्ठा करते समय, दोनों बंदूकें नाखूनों के साथ अपने हाथों को कसकर पिन की जाती हैं, और ऑप्टिमस की मृत्यु के बाद, बंदूकें उसके साथ मर जाती हैं। दूसरे शब्दों में, बच्चे का जीवन चक्र माता-पिता के जीवन चक्र के समान है।

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

रूढ़िवादी ओओपी चर्च हमें एक मौलिक त्रिमूर्ति का प्रचार करता है - इनकैप्सुलेशन, बहुरूपता और विरासत , जिस पर संपूर्ण वस्तु-उन्मुख दृष्टिकोण आधारित है। क्रम में उन्हें क्रमबद्ध करें।

विरासत

वंशानुक्रम एक तंत्र तंत्र है जो अनुमति देता है, हालांकि इसके विस्तार या संशोधन के लिए कुछ वर्गों द्वारा अन्य वर्गों के गुणों और व्यवहार को विरासत में देने के लिए विरोधाभास हो सकता है।

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

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

 class Transformer(){ //   function run(){ // ,    } function fire(){ // ,    } } class Autobot(Transformer){ //  ,   Transformer function transform(){ // ,      } } class Decepticon(Transformer){ //  ,   Transformer function transform(){ // ,      } } optimus = new Autobot() megatron = new Decepticon()

एनिमेशन नंबर 3

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

अधिभार

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

अनुचित उपयोग

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

दो संस्थाओं के संबंधों का वर्णन करते समय, यह निर्धारित करना कैसे संभव है कि विरासत कब उपयुक्त है और कब रचना उपयुक्त है? आप लोकप्रिय धोखा शीट का उपयोग कर सकते हैं: अपने आप से पूछें, ए ए इकाई बी है ? यदि ऐसा है, तो सबसे अधिक संभावना विरासत उपयुक्त है। यदि इकाई A इकाई B का हिस्सा है , तो हमारी पसंद रचना है।

हमारी स्थिति के संबंध में, यह इस तरह लगेगा:

ऑटोबोट ट्रांसफार्मर है? हाँ, तो हम विरासत चुनते हैं।
क्या बंदूक ट्रांसफार्मर का हिस्सा है? हां, इसका मतलब है कि रचना।

एक आत्म-परीक्षण के लिए, रिवर्स संयोजन का प्रयास करें, आपको कचरा मिलता है। यह चीट शीट ज्यादातर मामलों में मदद करता है, लेकिन ऐसे अन्य कारक हैं जो आपको रचना और विरासत के बीच चयन करते समय भरोसा करना चाहिए। इसके अलावा, इन तरीकों को विभिन्न प्रकार की समस्याओं को हल करने के लिए जोड़ा जा सकता है।

वंशानुक्रम स्टेटिक है

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

एकाधिक वंशानुक्रम

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

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

सार वर्ग

सामान्य वर्गों के अलावा, कुछ भाषाओं में अमूर्त भाषाएं मौजूद हैं। वे सामान्य वर्गों से भिन्न होते हैं, आप ऐसी कक्षा का एक ऑब्जेक्ट नहीं बना सकते हैं। हमें ऐसे वर्ग की आवश्यकता क्यों है, पाठक पूछेगा? इसकी आवश्यकता है ताकि वंशजों को इससे विरासत में मिले - सामान्य वर्ग जिनकी वस्तुओं को पहले ही बनाया जा सकता है।

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

बहुरूपता

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

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

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

कैप्सूलीकरण

एनकैप्सुलेशन एक वस्तु के क्षेत्रों और तरीकों तक पहुंच का नियंत्रण है। अभिगम नियंत्रण का तात्पर्य न केवल संभव / असंगत है, बल्कि विभिन्न सत्यापन, भार, गणना और अन्य गतिशील व्यवहार भी है।

कई भाषाओं में, डेटा एन्क्रिप्शन एनकैप्सुलेशन का हिस्सा है। इसके लिए, एक्सेस मॉडिफायर हैं (हम उनका वर्णन करते हैं जो लगभग सभी ओओपी भाषाओं में हैं):

publi - कोई भी विशेषता तक पहुँच सकता है
निजी - इस वर्ग की केवल विधियाँ विशेषता तक पहुँच सकती हैं
संरक्षित - निजी के समान, केवल वर्ग के वारिसों को ही एक्सेस मिलता है, जिसमें शामिल हैं

 class Transformer(){ public function constructor(){ } protected function setup(){ } private function dance(){ } }

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

एक्सेसर्स (गेटर्स एंड सेटर्स)

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

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

इंटरफेस

इंटरफ़ेस का कार्य एक दूसरे पर संस्थाओं की निर्भरता के स्तर को कम करना है, और अधिक अमूर्तता को जोड़ना।

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

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

इंटरफेस वाली कक्षाएं कई-कई संबंधों से मिलकर बनती हैं: एक एकल वर्ग कई इंटरफेस को लागू कर सकता है, और प्रत्येक इंटरफ़ेस, बदले में, कई वर्गों द्वारा लागू किया जा सकता है।

इंटरफ़ेस में दो तरफा उपयोग है:

इंटरफ़ेस के एक तरफ इस इंटरफ़ेस को लागू करने वाली कक्षाएं हैं।
दूसरी तरफ वे उपभोक्ता हैं जो इस इंटरफ़ेस का उपयोग उस डेटा के प्रकार के विवरण के रूप में करते हैं जिसके साथ वे (उपभोक्ता) काम करते हैं।

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

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

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

 //  : interface IWeapon{ function fire() {} //    .   } interface IEnergyGenerator{ //    ,     : function generate_energy() {} //  function load_fuel() {} //  } interface IScanner{ function scan() {} } // ,  : class RocketLauncher() : IWeapon { function fire(){ //    } } class LaserGun() : IWeapon { function fire(){ //    } } class NuclearReactor() : IEnergyGenerator { function generate_energy(){ //      } function load_fuel(){ //     } } class RITEG() : IEnergyGenerator { function generate_energy(){ //     } function load_fuel(){ //   - } } class Radar() : IScanner { function scan(){ //    } } class Lidar() : IScanner { function scan(){ //     } } //  - : class Transformer() { // , : IWeapon slot_weapon //      . IEnergyGenerator slot_energy_generator //     , IScanner slot_scanner //     /*         ,      ,   : */ function install_weapon(IWeapon weapon){ this.slot_weapon = weapon } function install_energy_generator(IEnergyGenerator energy_generator){ this.slot_energy_generator = energy_generator } function install_scanner(IScanner scanner){ this.slot_scanner = scanner } } //   class TransformerFactory(){ function build_some_transformer() { transformer = new Transformer() laser_gun = new LaserGun() nuclear_reactor = new NuclearReactor() radar = new Radar() transformer.install_weapon(laser_gun) transformer.install_energy_generator(nuclear_reactor) transformer.install_scanner(radar) return transformer } } //  transformer_factory = new TransformerFactory() oleg = transformer_factory.build_some_transformer()

एनिमेशन नंबर 4

दुर्भाग्य से, कारखाना तस्वीर में फिट नहीं था, लेकिन यह अभी भी वैकल्पिक है, ट्रांसफार्मर को यार्ड में भी इकट्ठा किया जा सकता है।

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

इस कोड में, हम स्वयं ट्रांसफॉर्मर के चित्र को प्रभावित किए बिना ट्रांसफार्मर के लिए नए घटक बना सकते हैं। उसी समय और इसके विपरीत, हम मौजूदा घटकों के संयोजन से नए ट्रांसफार्मर बना सकते हैं, या मौजूदा घटकों को बदलने के बिना नए घटकों को जोड़ सकते हैं।

बतख टाइपिंग

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

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

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

आईएसपी

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

मतिहीनता

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

अमूर्तता का स्तर

यहां कोई भी एक प्रसिद्ध मजाक को उद्धृत करने में विफल नहीं हो सकता है:
- अमूर्त की एक अतिरिक्त परत को जोड़कर किसी भी वास्तुशिल्प समस्या को हल किया जा सकता है, बड़ी संख्या में सार की समस्या को छोड़कर।

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

अमूर्त के स्तर का गलत चयन दो समस्याओं में से एक की ओर जाता है:

, , , ( )
, , , , . ( )

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

आइए एक काल्पनिक गेम "ट्रांसफार्मर-ऑनलाइन" के उदाहरण पर संभावित विकल्पों में से अमूर्तता के स्तर की परिभाषा को देखें। इस मामले में, अमूर्तता का स्तर परतों के रूप में कार्य करेगा, विचाराधीन प्रत्येक बाद की परत पिछले एक के ऊपर बिछेगी, इसमें से कार्यात्मक का हिस्सा लेगा।

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

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

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

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

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

डिजाइन पैटर्न

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

अमूर्त की तरह डिजाइन पैटर्न, ओओपी विकास के ही नहीं, बल्कि अन्य प्रतिमानों की भी विशेषता है। सामान्य तौर पर, पैटर्न का विषय इस लेख के दायरे से परे है, लेकिन मैं एक युवा डेवलपर को चेतावनी देना चाहूंगा जो केवल पैटर्न से परिचित होने का इरादा रखता है। यह एक जाल है! अब मैं समझाऊंगा कि क्यों।

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

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

निष्कर्ष

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

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

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

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

तस्वीरों में ओ.ओ.पी.