वह सब जो हमें घेरता है - वस्तु

मैं 1993 में ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में आया, जब मैंने सामान्य पास्कल से ऑब्जेक्ट संस्करण पर स्विच किया। बाद में मैंने C ++, जावा, php, जावास्क्रिप्ट के साथ काम किया, जिसमें से केवल जावा में यह तुरंत स्पष्ट था "यहाँ केवल ऑब्जेक्ट हैं और साइड में कोई कदम नहीं हैं।"


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

• स्पष्ट सीमाओं और उनके आंतरिक संप्रभु लोकतंत्र के साथ वस्तुओं का रहने का स्थान
• काम करने के तर्क को बदलने और परियोजना को तोड़ने के बिना मौजूदा प्रथाओं (पहले किए गए) का विस्तार करने की क्षमता

जैसे ही मुझे पता चला कि php और जावास्क्रिप्ट में OOP का उपयोग करना संभव है, मैंने इसका उपयोग करना शुरू कर दिया।

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

कई और प्लस हैं:

1. परियोजना का एक स्पष्ट नक्शा (हाँ, यह अभी मौजूद है! - "शहर" - "देश" -प्रोजेक्ट के अंदर स्थित) - समझने की जटिलता कम "यह कैसे काम करता है"
2. तैयार किए गए "क्यूब्स" के पुन: उपयोग की संभावना
3. एक (वर्ष के बाद) और दूसरे के (OOP) कोड की तेज और स्पष्ट समझ, इसका रखरखाव।
4. आंतरिक एल्गोरिदम का संरक्षण और अनैच्छिक परिवर्तनों से डेटा - "ब्लैक बॉक्स"

ये चार मुख्य थे, जो अंत में: परियोजना के विकास और समर्थन के समय को कम करते हैं, मस्तिष्क को "गैर-कोर शोर" से उतारते हैं और जब परियोजना "दलिया" में बदल जाती है, तो सीमाओं को धक्का देते हैं।

हाल ही में Habré पर मुझे "प्रक्रियात्मक बनाम OOP" की शैली में लिखे गए लेखों से मिलना शुरू हुआ।
यह संभवतः लोगों के लिए एक वास्तविक समस्या (OOP - for / खिलाफ) है, क्योंकि ऐसे विषय सामने आते हैं। लेकिन व्यक्तिगत रूप से, यदि संभव हो तो, मैं ओओपी चुनता हूं।
मेरे लिए काम करना अधिक सुविधाजनक और आसान है। यह समझना महत्वपूर्ण है कि OOP केवल एक उपकरण है।
और उपकरण का उपयोग करने के लिए, हमेशा एक निश्चित स्तर की योग्यता होनी चाहिए।

वैसे, 1993 में हंसपेटर मॉसेनबेक ने पहले ही अपने लेख "लागत और लाभ के ओओपी" में पेशेवरों और विपक्षों पर विचार किया।