आर्क विशेष रूप से वस्तु-उन्मुख नहीं है

जनवरी 2001

वर्तमान में वस्तु-उन्मुख प्रोग्रामिंग के लिए एक प्रकार की मनोविकृति है, लेकिन मेरे जानने वाले कुछ सबसे बुद्धिमान प्रोग्रामर इसके बारे में सबसे कम उत्साहित हैं।

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

मुझे लगता है कि वस्तु-उन्मुख प्रोग्रामिंग को लोग पसंद करते हैं, और उनमें से तीन और आधा बुरा है:

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

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

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

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

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

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

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