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

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

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

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

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

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

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

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

5. ऑब्जेक्ट-ओरिएंटेड एब्स्ट्रैक्शन कुछ विशिष्ट प्रकार के प्रोग्रामों के डोमेन पर बड़े करीने से मैप करते हैं, जैसे सिमुलेशन और सीएडी सिस्टम।

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

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