क्यों आर्क विशेष रूप से ऑब्जेक्ट-ओरिएंटेड नहीं है

जनवरी 2001

इस समय ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के लिए एक प्रकार की उन्माद है, लेकिन कुछ स्मार्ट प्रोग्रामर जिन्हें मैं जानता हूं, वे इसके बारे में सबसे कम उत्साहित हैं।

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

मुझे लगता है कि लोग ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग को पसंद करने के पांच कारण हैं, और उनमें से तीन और आधे बुरे हैं:

ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग रोमांचक है यदि आपके पास एक स्थिर-प्रकार की भाषा है जिसमें लेक्सिकल क्लोजर या मैक्रोज़ नहीं हैं। यह कुछ हद तक इन सीमाओं के चारों ओर एक तरीका प्रदान करता है। (देखें ग्रीन्सपुन का दसवां नियम।)

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

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

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

ऑब्जेक्ट-ओरिएंटेड अमूर्तताएँ कुछ विशिष्ट प्रकार के कार्यक्रमों के क्षेत्रों पर अच्छी तरह से मैप होती हैं, जैसे सिमुलेशन और सीएडी सिस्टम।

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

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