Beyond Objects
यह शोध पत्र यह तर्क देता है कि सिस्टम की कार्यक्षमता को सीधे समस्या-डोमेन के व्यक्तियों से जोड़ने का मूल ऑब्जेक्ट-ओरिएंटेड सिद्धांत स्वाभाविक रूप से त्रुटिपूर्ण है और विखंडन की ओर ले जाता है, तथा इसके बजाय डोमेन व्यक्तियों को कार्यात्मक मॉड्यूल से अलग करने वाले एक दृष्टिकोण के पक्ष में ऑब्जेक्ट ओरिएंटेशन को त्यागने का प्रस्ताव देता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
यहाँ डैनियल जैक्सन के पेपर, "बियॉन्ड ऑब्जेक्ट्स" (Beyond Objects) की व्याख्या सरल भाषा और उपमाओं के माध्यम से दी गई है।
मुख्य विचार: "एक ही आकार सबके लिए" (One-Size-Fits-All) वाली गलती
कल्पना कीजिए कि आप एक घर बना रहे हैं। पिछले 50 वर्षों से, सॉफ्टवेयर निर्माण का मानक नियम यह रहा है: "घर के हर कमरे का प्रबंधन उस व्यक्ति द्वारा किया जाना चाहिए जो वहां रहता है।"
सॉफ्टवेयर की दुनिया में इसे ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग (OOP) कहा जाता है। विचार यह है कि यदि वास्तविक दुनिया में आपका एक "यूजर" (User) है, तो आप कोड में एक "यूजर ऑब्जेक्ट" बनाते हैं। उस ऑब्जेक्ट को उस यूजर के बारे में सारा डेटा (उनका नाम, पासवर्ड) रखना चाहिए और उनसे संबंधित सारा काम (लॉग इन करना, समीक्षा लिखना, टेबल बुक करना) भी करना चाहिए।
डैनियल जैक्सन का तर्क है कि यह नियम एक जाल है। यह सुनने में तार्किक लगता है, लेकिन व्यवहार में, यह सॉफ्टवेयर को एक उलझे हुए ढेर में बदल देता है। वे सुझाव देते हैं कि हमें हर काम को "व्यक्ति" में ठूँसने की कोशिश छोड़ देनी चाहिए और इसके बजाय सॉफ्टवेयर को इस आधार पर व्यवस्थित करना चाहिए कि क्या हो रहा है (क्रियाएं/actions), न कि इस आधार पर कि इसे कौन कर रहा है (व्यक्ति/individuals)।
समस्या: "स्विस आर्मी नाइफ" बनाम "विशेष उपकरण"
जैक्सन का कहना है कि हर काम को एक एकल "यूजर ऑब्जेक्ट" पर थोपने से दो मुख्य सिरदर्द होते हैं:
1. "स्विस आर्मी नाइफ" की समस्या (Conflation - संलयन)
कल्पना कीजिए कि एक यूजर ऑब्जेक्ट एक स्विस आर्मी नाइफ है। इसमें एक ब्लेड, एक पेचकस, एक कॉर्कस्क्रू और एक टूथपिक है।
- समस्या: यदि आप कॉर्कस्क्रू का उपयोग करना चाहते हैं (यूजर के पासवर्ड को संभालने के लिए), तो आपको पूरा भारी चाकू अपने साथ ले जाना पड़ता है। यदि आप ब्लेड को बदलना चाहते हैं (रिव्यू सिस्टम में बग ठीक करना), तो आप अनजाने में कॉर्कस्क्रू को तोड़ सकते हैं।
- सॉफ्टवेयर में: एक "यूजर" ऑब्जेक्ट में यूजर का पासवर्ड, उनका रिव्यू इतिहास, उनकी नोटिफिकेशन सेटिंग्स और उनका बुकिंग लॉजिक—सब कुछ एक ही विशाल फाइल में समा जाता है। यदि आप रिव्यूज के काम करने के तरीके को बदलना चाहते हैं, तो आपको पासवर्ड के कोड के बीच में खुदाई करनी पड़ेगी। यह अव्यवस्थित और ठीक करने में कठिन है।
2. "बहुत सारे हाथ" की समस्या (Fragmentation - विखंडन)
"टेबल रिजर्व करने" जैसे कार्य की कल्पना करें।
- समस्या: इसे किसे करना चाहिए? यूजर को? रेस्टोरेंट को? टेबल को? या रिजर्वेशन को?
- सॉफ्टवेयर में: क्योंकि नियम कहता है कि "काम को ऑब्जेक्ट को सौंप दें," इसलिए कोड अलग-अलग हिस्सों में बंट जाता है। "यूजर" ऑब्जेक्ट चेक करता है कि उनके पास बुकिंग है या नहीं। "रेस्टोरेंट" ऑब्जेक्ट चेक करता है कि टेबल खाली है या नहीं। "रिजर्वेशन" ऑब्जेक्ट टिकट बनाता है।
- परिणाम: एक सिंगल रिजर्वेशन करने के लिए, कंप्यूटर को तीन अलग-अलग लोगों को तीन अलग-अलग कमरों में चलाना पड़ता है और उन्हें आपस में बात करनी पड़ती है। यदि एक व्यक्ति दूसरे को बताना भूल जाता है, तो सिस्टम टूट जाता है। इसे विखंडन (fragmentation) कहा जाता है।
उपमा: रेस्टोरेंट रिजर्वेशन
जैक्सन इसे समझाने के लिए एक रेस्टोरेंट का उदाहरण देते हैं।
पुराना तरीका (ऑब्जेक्ट-ओरिएंटेड):
आपके पास एक "यूजर" ऑब्जेक्ट और एक "रेस्टोरेंट" ऑब्जेक्ट है।
- जब एलिस एक टेबल बुक करना चाहती है, तो वह अपने "यूजर" ऑब्जेक्ट से पूछती है।
- यूजर ऑब्जेक्ट "रेस्टोरेंट" ऑब्जेक्ट से पूछता है कि क्या टेबल खाली है।
- रेस्टोरेंट ऑब्जेक्ट "स्लॉट" (Slot) ऑब्जेक्ट से पूछता है।
- एक "रिजर्वेशन" ऑब्जेक्ट बनाया जाता है।
- अव्यवस्था: यदि आप नियम बदलना चाहते हैं कि "एलिस एक बार में दो टेबल बुक नहीं कर सकती," तो आपको यूजर ऑब्जेक्ट, रेस्टोरेंट ऑब्जेक्ट और रिजर्वेशन ऑब्जेक्ट—तीनों को अपडेट करना होगा। वे सब आपस में उलझे हुए हैं।
नया तरीका (कॉन्सेप्ट्स/अवधारणाएं):
"इसका मालिक कौन है?" पूछने के बजाय, हम पूछते हैं "यह नियमों का समूह किस बारे में है?"
जैक्सन सॉफ्टवेयर को कॉन्सेप्ट्स (Concepts) में व्यवस्थित करने का प्रस्ताव देते हैं। एक कॉन्सेप्ट को एक कंपनी में एक विशेष टीम या विभाग के रूप में सोचें, न कि एक व्यक्ति के रूप में।
- कॉन्सेप्ट 1: "रिजर्विंग" (Reserving)
- यह टीम प्रतिबद्धता (commitments) करने के सभी नियमों को संभालती है। इसे इस बात की परवाह नहीं है कि यूजर कौन है; इसे केवल रिजर्व करने की क्रिया से मतलब है। यह इस सूची को रखता है कि किसने क्या बुक किया है।
- कॉन्सेप्ट 2: "उपलब्धता" (Availability)
- यह टीम टेबल खाली है या नहीं, यह चेक करने की क्रिया को संभालती है। इसे इस बात की परवाह नहीं है कि कौन बुक कर रहा है; इसे केवल स्लॉट्स से मतलब है।
- कॉन्सेप्ट 3: "यूजर ऑथेंटिकेशन" (User Authentication)
- यह टीम बस यह जांचती है कि व्यक्ति वही है जो वह होने का दावा कर रहा है।
वे कैसे मिलकर काम करते हैं:
यूजर ऑब्जेक्ट द्वारा रेस्टोरेंट ऑब्जेक्ट को कॉल करने के बजाय, ये "कॉन्सेप्ट्स" सिंक्रोनाइज़ेशन (Synchronizations) (जैसे ट्रैफिक लाइट) के माध्यम से एक-दूसरे से बात करते हैं।
- नियम: "जब एक रिक्वेस्ट (Request) आती है, तो चेक करें कि क्या Availability कहती है 'हाँ', और यदि Authentication कहती है 'जाओ', तो Reserving बुकिंग कर सकता है।"
यह बेहतर क्यों है
- उलझे हुए गांठें नहीं: "रिजर्विंग" टीम को यह जानने की आवश्यकता नहीं है कि पासवर्ड कैसे चेक किया जाए। "ऑथेंटिकेशन" टीम को टेबल चेक करने की आवश्यकता नहीं है। वे अलग हैं।
- "इसका मालिक कौन है?" वाले विवाद नहीं: आपको यह बहस करने की ज़रूरत नहीं है कि "कैंसिल" बटन यूजर का है या रिजर्वेशन का। आप बस कैंसिल करने के लॉजिक को उस कॉन्सेप्ट में डाल देते हैं जो रिजर्वेशन की स्थिति (state) को प्रबंधित करता है।
- स्पष्ट मानचित्र: यदि आप कोड को देखते हैं, तो आप स्पष्ट रूप से बिजनेस रूल्स (Reserving, Availability) देखते हैं, न कि यह भ्रमित करने वाला नक्शा कि किसका क्या स्वामित्व है।
"कॉन्सेप्ट" बनाम "ऑब्जेक्ट"
- ऑब्जेक्ट: एक छोटी मशीन जो सब कुछ बनने की कोशिश करती है (डेटा + लॉजिक + पहचान)। यह एक ऐसे व्यक्ति की तरह है जो एक ही समय में शेफ, वेटर और कैशियर बनने की कोशिश कर रहा है।
- कॉन्सेप्ट: एक विशिष्ट काम या संबंध को संभालने वाला मॉड्यूल। यह एक विशेष विभाग की तरह है। "शेफ विभाग" खाना पकाने को संभालता है; "वेटर विभाग" परोसने को संभालता है। वे समन्वय करते हैं, लेकिन वे एक ही व्यक्ति में विलीन नहीं होते।
निष्कर्ष
जैक्सन यह नहीं कह रहे हैं कि हमें सारा सॉफ्टवेयर फेंक देना चाहिए। वे कह रहे हैं कि ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग का मूल नियम—"हर काम को उस व्यक्ति को सौंप दें जिससे वह संबंधित है"—ही समस्या की जड़ है।
कॉन्सेप्ट्स की ओर स्विच करके, हम सॉफ्टवेयर को लोगों के संग्रह की तरह दिखने के लिए मजबूर करना बंद कर देते हैं। इसके बजाय, हम इसे नियमों और संबंधों के संग्रह के रूप में व्यवस्थित करते हैं। यह कोड को पढ़ने में आसान, ठीक करने में आसान और किसी एक छोटी चीज़ को बदलने पर टूटने की संभावना कम बनाता है।
यह सोचने के एक पुराने, सरल तरीके (जैसे रिलेशनल डेटाबेस) की ओर वापसी है, लेकिन आधुनिक सॉफ्टवेयर की जरूरतों के लिए अपडेट किया गया है, जिससे हम ऐसे सिस्टम बना सकें जो कम नाजुक और अधिक तार्किक हों।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।