यदि आपने कभी रूबी ऑन रेल्स का उपयोग किया है, तो आप शायद चिंताओं की अवधारणा में आ गए हैं। जब भी आप एक नई रेल परियोजना शुरू करते हैं, तो आपको एक निर्देशिका 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

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

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

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

मिश्रण का एक उत्कृष्ट उदाहरण

इससे पहले कि हम चिंताओं की गहराई में आगे बढ़ें, आइए उनमें से एक और स्पष्टीकरण जोड़ें। जब आप देखते हैं 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

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

फिर, सड़क के कुछ महीने बाद, एक नई आवश्यकता निर्धारित की जाती है जहां डेवलपर को हमारे प्रस्तुत करने के तरीके को बदलने की आवश्यकता होती है 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 . के लिए उन दोनों पर निर्भर करता है परिभाषा। इस तथ्य के लिए भी यही कहा जा सकता है कि एक trashed Trashable . रखने के लिए फ़ील्ड को दोनों मॉडलों में मौजूद होना आवश्यक है काम करने की चिंता।

यही कारण है कि एक नो-चिंता क्लब के खिलाफ हो सकता है, और चिंता-समर्थक क्लब के लिए है। मैं कहूंगा, पहला 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 . रखें संभव के रूप में themodels के करीब। notify विधि नहीं होनी चाहिए Trashable . का हिस्सा बनें बिल्कुल चिंता। प्रत्येक मॉडल को इसका स्वयं ध्यान रखना चाहिए, खासकर यदि वे विभिन्न उपसमूहों को सूचित करते हैं। आइए देखें कि इसे कम दर्द में कैसे करें:

 
# Concerns
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
 
  # Other useful methods that relate to authors across models.
  # If there are none, ditch the concern.
end
 
# Models
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 को छोड़ दिया है कार्यक्षमता का मैंने पहले वर्णन किया था क्योंकि यह एक और दिन के लिए एक विषय हो सकता है।

द फाइनल बॉस

बेसकैंप के लिए, रेल निर्माता, अन्य चिंताओं को संदर्भित करने वाली चिंताएं बिल्कुल ठीक लगती हैं जैसा कि डीएचएच ने कुछ समय पहले एक ट्वीट में दिखाया था:

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

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

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

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

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

निष्कर्ष

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

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

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

अगले एक तक, चीयर्स!

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