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

जनवरी 2001

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

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

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

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

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

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

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

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

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

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