यदि आपने कभी रूबी ऑन रेल्स का उपयोग किया है, तो आप शायद कंसर्न की अवधारणा से परिचित हैं। जब भी आप एक नया रेल्स प्रोजेक्ट शुरू करते हैं, तो आपको एक डायरेक्टरी app/controllers/concerns और app/models/concerns मिलती है। लेकिन कंसर्न क्या हैं? और रेल्स समुदाय के लोग कभी-कभी उनके बारे में बुरा क्यों बोलते हैं?

त्वरित अवलोकन

एक रेल्स कंसर्न कोई भी मॉड्यूल है जो ActiveSupport::Concern मॉड्यूल को बढ़ाता है। आप पूछ सकते हैं - कंसर्न मॉड्यूल से कैसे अलग हैं? मुख्य अंतर यह है कि रेल्स कंसर्न आपको थोड़ा जादू करने की अनुमति देते हैं, जैसे:

# app/models/concerns/trashable.rb module Trashable extend ActiveSupport::Concern included do scope :existing, -> { where(trashed: false) } scope :trashed, -> { where(trashed: true) } end def trash update_attribute :trashed, true end end

आप उस शब्द included को देखते हैं। यह एक रूबी मॉड्यूल पर छिड़के गए रेल्स कार्बोहाइड्रेट का एक सा है। ActiveSupport::Concern आपके लिए क्या करता है यह आपको उस कोड को रखने की अनुमति देता है जिसे आप included ब्लॉक के अंदर मूल्यांकन करना चाहते हैं। उदाहरण के लिए, आप अपने मॉडल से ट्रैशिंग तर्क को निकालना चाहते हैं। included आपको वह करने की अनुमति देता है जो हमने किया और बाद में अपने मॉडल के कंसर्न को इस तरह शामिल करें:

class Song < ApplicationRecord include Trashable has_many :authors # ... end

काफी आसान और इस बिंदु पर भोला, है ना? मॉडल ने थोड़ा वजन कम किया और ट्रैशिंग को अब अन्य मॉडलों में पुन: उपयोग किया जा सकता है, न कि केवल हमारे Song मॉडल में। खैर, चीजें जटिल हो सकती हैं। आइए गोता लगाकर पता लगाएं।

मिक्सिन का एक क्लासिक उदाहरण

इससे पहले कि हम कंसर्न की गहराई में आगे बढ़ें, आइए उनके लिए एक और व्याख्या जोड़ें। जब आप include SomeModule या extend AnotherModule देखते हैं, तो इन्हें मिक्सिन कहा जाता है। एक मिक्सिन कोड का एक सेट है जिसे अन्य क्लासेस में जोड़ा जा सकता है। और, जैसा कि हम सभी रूबी दस्तावेज़ से जानते हैं, एक मॉड्यूल मेथड्स और स्थिरांक का एक संग्रह है। तो हम यहां जो कर रहे हैं वह मेथड्स और स्थिरांक वाले मॉड्यूल को विभिन्न क्लासेस में शामिल कर रहा है ताकि वे उनका उपयोग कर सकें।

यह ठीक वही है जो हमने Trashable कंसर्न के साथ किया था। हमने एक मॉड्यूल ऑब्जेक्ट को ट्रैश करने के आसपास सामान्य तर्क को एक मॉड्यूल में निकाला। इस मॉड्यूल को बाद में अन्य स्थानों में शामिल किया जा सकता है। तो, मिक्सिन एक डिज़ाइन पैटर्न है जिसका उपयोग न केवल रूबी और रेल्स में किया जाता है। लेकिन, जहां भी इसका उपयोग किया जाता है, लोग या तो इसे पसंद करते हैं और सोचते हैं कि यह अच्छा है, या वे इससे नफरत करते हैं और सोचते हैं कि यह आसानी से नियंत्रण से बाहर हो सकता है।

इसे बेहतर ढंग से समझने के लिए, हम उनके उपयोग के कुछ फायदे और नुकसान के माध्यम से जाएंगे। उम्मीद है, ऐसा करके, हम यह समझ हासिल कर सकते हैं कि कंसर्न का उपयोग कब या करना चाहिए या नहीं।

मेरे पास सब कुछ है

जब आप किसी चीज़ को कंसर्न में निकालने का फैसला करते हैं, जैसे Trashable कंसर्न, तो अब आपके पास उस सब की कार्यक्षमता तक पहुंच है जहां Trashable शामिल है। यह बड़ी शक्ति लाता है, लेकिन जैसा कि रिचर्ड श्नेमैन ने इस विषय पर अपने ब्लॉग पोस्ट में कहा था - "महान शक्ति के साथ जटिल कोड बनाने की बड़ी क्षमता आती है"। उनका मतलब उस कोड को जटिल बनाना था जिस पर आप भरोसा कर सकते हैं, कुछ ऐसा जो आपके कंसर्न में माना जाता है।

अगर हम Trashable पर एक बार फिर नज़र डालें:

module Trashable extend ActiveSupport::Concern included do scope :existing, -> { where(trashed: false) } scope :trashed, -> { where(trashed: true) } end def trash update_attribute :trashed, true end end

कंसर्न का तर्क इस तथ्य पर निर्भर करता है कि trashed फ़ील्ड वहां मौजूद है जहां कंसर्न शामिल है। सही? कोई बड़ी बात नहीं, आखिर यही हम चाहते हैं। लेकिन, जो मैं होता हुआ देखता हूं वह यह है कि लोग मॉडल से अन्य चीजों को कंसर्न में खींचने के लिए ललचाते हैं। इसकी तस्वीर बनाने के लिए कि यह कैसे हो सकता है, आइए कल्पना करें कि Song मॉडल में एक और मेथड featured_authors है:

class Song < ApplicationRecord include Trashable has_many :authors def featured_authors authors.where(featured: true) end # ... end class Album < ApplicationRecord include Trashable has_many :authors def featured_authors authors.where(featured: true) end # ... end

बेहतर ढंग से चित्रित करने के लिए, मैंने एक Album मॉडल जोड़ा जो Trashable को भी शामिल करता है। मान लें कि हम गाने और एल्बम के ट्रैश होने पर फीचर्ड लेखकों को सूचित करना चाहते हैं। लोग इस तर्क को कंसर्न के अंदर रखने के लिए ललचाएंगे जैसे:

module Trashable extend ActiveSupport::Concern included do scope :existing, -> { where(trashed: false) } scope :trashed, -> { where(trashed: true) } end def trash update_attribute :trashed, true notify(featured_authors) end def notify(authors) # ... end end

यहीं, चीजें थोड़ी जटिल होने लगी हैं। चूंकि हमारे Song मॉडल के बाहर ट्रैशिंग तर्क है, हम कंसर्न में नोटिफाई करने को रखने के लिए ललचा सकते हैं। वहां, कुछ "गलत" होता है। featured_authors को Song मॉडल से लिया जाता है। ठीक है, मान लें कि यह पुल रिक्वेस्ट समीक्षा और CI चेक पास करता है।

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

class Song < ApplicationRecord include Trashable has_many :authors def featured_authors authors.where(featured: true).where(region: 'Europe') end # ... end class Album < ApplicationRecord include Trashable has_many :authors # ... end

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

यहां जोखिम भरा है कि कंसर्न (मिक्सिन) उस मॉडल के बारे में बहुत कुछ जानता है जिसमें यह शामिल होता है। इसे सर्कुलर डिपेंडेंसी कहा जाता है। Song और Album ट्रैशिंग के लिए Trashable पर निर्भर करते हैं, Trashable उन दोनों पर featured_authors परिभाषा के लिए निर्भर करता है। वही कहा जा सकता है इस तथ्य के लिए कि Trashable कंसर्न के काम करने के लिए दोनों मॉडल में trashed फ़ील्ड मौजूद होना चाहिए।

यही कारण है कि नो-कंसर्न क्लब इसके खिलाफ हो सकता है, और प्रो-कंसर्न क्लब इसके पक्ष में है। मैं कहूंगा, Trashable का पहला संस्करण वह है जिसे मैं अपने कोडबेस में चुनूंगा। आइए देखें कि नोटिफाई करने वाले दूसरे संस्करण को कैसे बेहतर बनाया जाए।

तुम सब कहां से आते हो

नोटिफाई करने वाले हमारे Trashable को देखते हुए, हमें इसके बारे में कुछ करना होगा। एक और चीज जो कंसर्न का उपयोग करते समय होती है वह यह है कि हम चीजों को ओवर-डीआरवाई करते हैं। आइए प्रदर्शन उद्देश्यों के लिए, हमारे मौजूदा मॉडल के साथ ऐसा करने का प्रयास करें, एक और कंसर्न बनाकर (इस पर मेरे साथ बने रहें):

module Authorable has_many :authors def featured_authors authors.where(featured: true) end end

तब, हमारे Song और Album इस तरह दिखेंगे:

class Song < ApplicationRecord include Trashable include Authorable # ... end class Album < ApplicationRecord include Trashable include Authorable # ... end

हमने सब कुछ सुखा दिया, लेकिन अब यूरोप से फीचर्ड लेखकों की आवश्यकता पूरी नहीं होती। चीजों को बदतर बनाने के लिए, अब Trashable कंसर्न और मॉडल Authorable पर निर्भर करते हैं। क्या बकवास है? बिल्कुल मेरा सवाल जब मैं कुछ समय पहले कंसर्न के साथ काम कर रहा था। यह ट्रैक करना कठिन है कि मेथड्स कहां से आ रहे हैं।

इस सब का मेरा समाधान featured_authors को मॉडल के जितना संभव हो उतना करीब रखना होगा। notify मेथड को Trashable कंसर्न का हिस्सा नहीं होना चाहिए। प्रत्येक मॉडल को अपने दम पर इसका ध्यान रखना चाहिए, खासकर यदि वे अलग-अलग उपसमूहों को सूचित करते हैं। आइए देखें कि इसे कम दर्दनाक तरीके से कैसे करें:

 # कंसर्न module Trashable extend ActiveSupport::Concern included do scope :existing, -> { where(trashed: false) } scope :trashed, -> { where(trashed: true) } end def trash update_attribute :trashed, true end end module Authorable has_many :authors # अन्य उपयोगी मेथड्स जो मॉडल में लेखकों से संबंधित हैं। # यदि कोई नहीं हैं, तो कंसर्न को छोड़ दें। end # मॉडल class Song < ApplicationRecord include Trashable include Authorable def featured_authors authors.where(featured: true).where(region: 'Europe') end # ... end class Album < ApplicationRecord include Trashable include Authorable def featured_authors authors.where(featured: true) end # ... end

ऐसे कंसर्न प्रबंधनीय हैं और बहुत जटिल नहीं हैं। मैंने पहले वर्णित notify कार्यक्षमता को छोड़ दिया क्योंकि यह किसी अन्य दिन का विषय हो सकता है।

द फाइनल बॉस

Basecamp के लिए, रेल्स के निर्माता, कंसर्न का अन्य कंसर्न को संदर्भ देना DHH द्वारा कुछ समय पहले एक ट्वीट में दिखाए अनुसार पूरी तरह से ठीक लगता है:

कोड स्क्रीनशॉट को देखकर, आप या तो विस्मय में या घृणा में अपना मुंह खोल रहे हैं। मुझे लगता है कि यहां कोई बीच का रास्ता नहीं है। अगर मुझे इस कोड को संपादित करने का मौका मिला, तो मैं इसे "फाइनल कंसर्न बॉस फाइट" के रूप में कल्पना करूंगा। लेकिन मजाक एक तरफ, यहां दिलचस्प बात यह है कि ऐसी टिप्पणियां हैं जो कहती हैं कि कौन सा कंसर्न किस पर निर्भर करता है। देखें:

 # ... include Subscribable # Depends on Readable include Eventable # Depends on Recordables # ...

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

कुछ ऐसा ही DHH ने चर्चा के अंदर एक टिप्पणी में साझा किया। एक रिस्पांस ट्वीट के अंदर पूछा गया कि इस कोडबेस के साथ काम करने वाले लोग कंसर्न जैसे इनके साथ कैसे इंटरैक्ट करने वाले हैं। DHH जवाब देता है कि उनके पास अधिक लिखित डॉक्स नहीं हैं, वे शायद ही कभी हायर करते हैं इसलिए उनकी टीम इनसे अच्छी तरह परिचित है।

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

निष्कर्ष

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

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

कोई समाधान पूर्ण नहीं है, और मुझे आशा है कि आपको ब्लॉग पोस्ट में रेल्स कंसर्न के काम करने के तरीके को समझने का मौका मिला। हमेशा की तरह, अपने निर्णय का उपयोग करें और फायदे और नुकसान से अवगत रहें।

अगली बार तक, चीयर्स!

P.S. यदि आप रूबी मैजिक पोस्ट को प्रेस से निकलते ही पढ़ना चाहते हैं, तो हमारे रूबी मैजिक न्यूज़लेटर की सदस्यता लें और कभी भी एक भी पोस्ट मिस न करें!