वस्तुओं के बिना जीवन

(अनुवाद)

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

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


जब मैं इस विषय के बारे में सोचता हूं, तो मैं समझता हूं कि मेरी सोच में कोई तेज बदलाव नहीं था। समय के साथ सुविधाओं का लाभ धीरे-धीरे घट रहा है। जिस तरह से मैं अब वस्तुओं का उपयोग करता हूं वह उस तरह से अलग है जैसे मैंने युवा और अनुभवहीन होने पर उनका उपयोग किया था। इस पोस्ट में, मैं OOP की अपनी समझ में इन परिवर्तनों को प्रकट करना चाहूंगा।

OOP वादा करता है

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

व्यावसायिक घटकों का पुन: उपयोग नहीं किया जा सकता है

यह जल्द ही स्पष्ट हो गया कि पुन: प्रयोज्य व्यापार घटकों को बनाने की क्षमता एक गिरावट थी। हर व्यवसाय हर किसी से अलग है, यहां तक ​​कि एक उद्योग में भी। प्रत्येक समान परियोजना बहुत विशिष्ट व्यावसायिक तर्क पर काम करती है।

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

पैटर्न के साथ संरचित सॉफ्टवेयर न बनाएं

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

केवल हाल ही में प्रोग्रामर ने पैटर्न का सार्थक रूप से उपयोग करना सीखा है। जिस तरह से आप मॉडल को समझते हैं, उसे कोड लिखना बहुत आसान है। और इसे अलेक्जेंड्रेस्कु की किताब से कुछ सामान्यीकृत पैटर्न में सार करने की कोशिश न करें।

पुन: उपयोग के लिए कक्षा और घटक रूपरेखा बहुत कुशल नहीं हैं।

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

इस तरह के भारी ढांचे जल्दी से मर जाते हैं और अधिक हल्के पुस्तकालयों और हल्के पुस्तकालयों के सेट द्वारा प्रतिस्थापित किए जाते हैं। यह स्पष्ट हो गया कि कार्यक्रमों को इतने निकट से संबंधित वर्गों के सेट से बनाना आसान है जो आप अपनी आवश्यकताओं के आधार पर एक साथ रख सकते हैं। आपको वास्तव में विभिन्न वर्गों के घनिष्ठ एकीकरण की आवश्यकता नहीं है।

वंशानुक्रम नाजुक सॉफ्टवेयर की ओर जाता है

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

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

उल्लंघन उल्लंघन

OOP का एक और मूल सिद्धांत एक राज्य को घेरने और एक राज्य के साथ काम करने के लिए व्यवहारिक तरीके प्रदान करने की क्षमता है। दुर्भाग्य से, यह पता चला कि ज्यादातर मामलों में हमें संपूर्ण ऑब्जेक्ट डेटा की आवश्यकता होती है, न कि उनके साथ काम करने के तरीकों की।

उदाहरण के लिए, किसी ऑब्जेक्ट को HTML में रेंडर करने के लिए कहना हास्यास्पद है। इस मामले में HTML रेंडर करने के बारे में जानकारी परियोजना पर फैली हुई है और रेंडरिंग कोड में एक छोटा सा बदलाव कई वर्गों में बदलाव को दर्शाता है। HTML रेंडरिंग के किसी अलग कंपोनेंट में ऑब्जेक्ट को पास करना ज्यादा सही होगा। और यह घटक सबसे पहले ऑब्जेक्ट से ब्याज के सभी मूल्यों को निकालेगा।

यहां तक ​​कि एंटीपैटर्न भी हैं जो आपको व्यवहारिक तरीकों (जावा बीन्स, डेटा ट्रांसफर ऑब्जेक्ट्स, आदि) के बिना एक समझाया स्थिति के साथ ऑब्जेक्ट बनाने की अनुमति देते हैं। अगर हम ऐसी वस्तुएं बनाते हैं, तो वस्तुओं के बजाय सिर्फ संरचनाओं का उपयोग क्यों नहीं करते?

परिवर्तनीय स्थिति - समस्याओं का कारण

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

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

वस्तुओं के बिना जीवन

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

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

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

शायद मुझे लगता है कि मैं शुद्ध OOP से बहुत आगे निकल गया हूं। मैं विश्वास के साथ कह सकता हूं कि अब मैं पहले की तुलना में अधिक कॉम्पैक्ट, अधिक समझने योग्य और बेहतर संरचित कोड लिख रहा हूं।

(अनुवादक का नोट: इस लेख में मैं ओओपी के प्रति एक अनुभवी ओओपी प्रोग्रामर के रवैये पर ध्यान देना चाहूंगा। मैं स्काला भाषा से परिचित नहीं हूं, और तदनुसार, स्काला-विशिष्ट शब्दों के साथ।

तेजी से, मैं उन स्थितियों को देखता हूं जहां अनुभवी प्रोग्रामर ओओपी में निराश होने की बात करते हैं।

स्काला की संभावनाओं के बारे में। जाहिर है, वे वास्तव में उन मामलों की पूरी श्रृंखला को कवर करते हैं जिन्हें ओओपी से निपटना है। मैं जोड़ना चाहूंगा कि एर्लैंग या हास्केल की क्षमताओं को इससे कोई ख़राब नहीं होना चाहिए।
)