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