बड़े ActiveRecord मॉडल के लिए 7 रीफैक्टरिंग

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

परिचय

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

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

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

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

मॉडल से मिश्रण का चयन न करें

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

अब आइए फिर से शुरू करते हैं!

refactorings

1. मूल्य वस्तुओं को हाइलाइट करें

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

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

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

class Rating include Comparable def self.from_cost(cost) if cost <= 2 new("A") elsif cost <= 4 new("B") elsif cost <= 8 new("C") elsif cost <= 16 new("D") else new("F") end end def initialize(letter) @letter = letter end def better_than?(other) self > other end def <=>(other) other.to_s <=> to_s end def hash @letter.hash end def eql?(other) to_s == other.to_s end def to_s @letter.to_s end end 

कॉन्स्टेंटस्नापशॉट वर्ग का प्रत्येक उदाहरण अपने सार्वजनिक इंटरफ़ेस में रेटिंग ऑब्जेक्ट के लिए निम्नानुसार पहुंच प्रदान करता है:

 class ConstantSnapshot < ActiveRecord::Base # … def rating @rating ||= Rating.from_cost(cost) end end 

कॉन्स्टेंटस्नापशॉट वर्ग के आकार को कम करने के अलावा, इस दृष्टिकोण के कई और फायदे हैं:

• #Worse_than तरीके ? और # फाइबर__थन? निर्मित रूबी ऑपरेटरों> और <की तुलना में रेटिंग की तुलना करने के लिए अधिक अभिव्यंजक तरीका प्रदान करते हैं
  
• #Hash और #eql तरीकों को परिभाषित करना ? एक हैश कुंजी के रूप में कक्षा रेटिंग की एक वस्तु का उपयोग करना संभव बनाता है। CodeClimate Enumberable # group_by का उपयोग करके आसानी से समूह कक्षाओं और मॉड्यूल के लिए इसका उपयोग करता है।
  
• #To_s विधि अतिरिक्त प्रयासों के बिना एक स्ट्रिंग में कक्षा रेटिंग की एक वस्तु को प्रक्षेपित करने की अनुमति देती है
  
• यह वर्ग फ़ैक्टरी विधि के लिए एक सुविधाजनक स्थान है, जो किसी दिए गए "सुधार मूल्य" (किसी दिए गए वर्ग के सभी "बदबू" को खत्म करने के लिए आवश्यक समय) के लिए सही रेटिंग देता है।
  

2. सेवा वस्तुओं का चयन (सेवा वस्तुएँ)

सिस्टम में कुछ क्रियाएं सर्विस ऑब्जेक्ट में उनके इनकैप्सुलेशन को सही ठहराती हैं। मैं इस दृष्टिकोण का उपयोग तब करता हूं जब कोई कार्रवाई एक या अधिक मानदंडों को पूरा करती है:

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

उदाहरण के लिए, हम उपयोगकर्ता # प्रमाणिक विधि को UserAuthenticator वर्ग में स्थानांतरित कर सकते हैं:

 class UserAuthenticator def initialize(user) @user = user end def authenticate(unencrypted_password) return false unless @user if BCrypt::Password.new(unencrypted_password) == @user.password_digest @user else false end end end 

इस स्थिति में, SessionController इस तरह दिखेगा:

 class SessionsController < ApplicationController def create user = User.where(email: params[:email]).first if UserAuthenticator.new(user).authenticate(params[:password]) self.current_user = user redirect_to dashboard_path else flash[:alert] = "Login failed." render "new" end end end 

3. फॉर्म ऑब्जेक्ट्स का चयन (फॉर्म ऑब्जेक्ट्स)

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

 class Signup include Virtus extend ActiveModel::Naming include ActiveModel::Conversion include ActiveModel::Validations attr_reader :user attr_reader :company attribute :name, String attribute :company_name, String attribute :email, String validates :email, presence: true # … more validations … # Forms are never themselves persisted def persisted? false end def save if valid? persist! true else false end end private def persist! @company = Company.create!(name: company_name) @user = @company.users.create!(name: name, email: email) end end 

ActiveRecord के समान विशेषता व्यवहार प्राप्त करने के लिए, मैं रत्न पुण्य का उपयोग करता हूं। प्रपत्र ऑब्जेक्ट सामान्य मॉडल की तरह दिखते हैं, इसलिए नियंत्रक अपरिवर्तित रहता है:

 class SignupsController < ApplicationController def create @signup = Signup.new(params[:signup]) if @signup.save redirect_to dashboard_path else render "new" end end end 

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

4. क्वेरी ऑब्जेक्ट्स को हाइलाइट करना

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

 class AbandonedTrialQuery def initialize(relation = Account.scoped) @relation = relation end def find_each(&block) @relation. where(plan: nil, invites_count: 0). find_each(&block) end end 

इस तरह के वर्ग का उपयोग पत्र भेजने के लिए पृष्ठभूमि में किया जा सकता है:

 AbandonedTrialQuery.new.find_each do |account| account.send_offer_for_support end 

ActiveRecord :: Relation class के तरीकों का उपयोग करते हुए, रचना का उपयोग करके प्रश्नों को संयोजित करना सुविधाजनक है:

 old_accounts = Account.where("created_at < ?", 1.month.ago) old_abandoned_trials = AbandonedTrialQuery.new(old_accounts) 

ऐसी कक्षाओं का परीक्षण करते समय, क्वेरी क्रम और डेटाबेस से चयन को सही क्रम में पंक्तियों की उपस्थिति के लिए, साथ ही जॉइन-एस और अतिरिक्त प्रश्नों की उपस्थिति के लिए (एन + 1 क्वेरी जैसे बग से बचने के लिए) जांचना आवश्यक है।

5. वस्तुओं को देखें

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

उदाहरण के लिए, कोड जलवायु में एक डोनट चार्ट कोड की स्थिति के स्नैपशॉट के आधार पर कक्षा की रेटिंग को तोड़ देता है। इन क्रियाओं को प्रपत्र के किसी ऑब्जेक्ट में एन्क्रिप्ट किया गया है:

 class DonutChart def initialize(snapshot) @snapshot = snapshot end def cache_key @snapshot.id.to_s end def data # pull data from @snapshot and turn it into a JSON structure end end 

मुझे अक्सर विचारों और ईआरबी (या हम्ल / स्लिम) पैटर्न के बीच एक-से-एक रिश्ते मिलते हैं। इससे मुझे टू स्टेप व्यू टेम्प्लेट का उपयोग करने का विचार आया, लेकिन मेरे पास अभी भी रेल के लिए एक तैयार समाधान नहीं है।

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

6. नियम वस्तुओं का चयन (नीति वस्तुएँ)

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

 class ActiveUserPolicy def initialize(user) @user = user end def active? @user.email_confirmed? && @user.last_login_at > 14.days.ago end end 

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

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

7. डेकोरेटिंग डेकोरेटर्स

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

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

यहां बताया गया है कि आप डेकोरेटर में फेसबुक कमेंट लॉजिक कैसे डाल सकते हैं:

 class FacebookCommentNotifier def initialize(comment) @comment = comment end def save @comment.save && post_to_wall end private def post_to_wall Facebook.post(title: @comment.title, user: @comment.author) end end 

नियंत्रक इस तरह दिख सकता है:

 class CommentsController < ApplicationController def create @comment = FacebookCommentNotifier.new(Comment.new(params[:comment])) if @comment.save redirect_to blog_path, notice: "Your comment was posted." else render "new" end end end 

सज्जाकार वस्तुओं - सेवाओं से भिन्न होते हैं, क्योंकि वे मौजूदा वस्तुओं की कार्यक्षमता का विस्तार करते हैं। लपेटने के बाद, डेकोरेटर ऑब्जेक्ट का उपयोग उसी तरह किया जाता है जैसे एक नियमित टिप्पणी वस्तु। रूबी मानक पुस्तकालय मेटाप्रोग्रामिंग का उपयोग करके सज्जाकारों के निर्माण को सरल बनाने के लिए उपकरणों का एक सेट प्रदान करता है।

निष्कर्ष

यहां तक ​​कि एक रेल अनुप्रयोग में, मॉडल जटिलता के लिए कई नियंत्रण हैं। उनमें से किसी को भी रूपरेखा के सिद्धांतों के उल्लंघन की आवश्यकता नहीं होगी।

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

आपने शायद देखा कि अधिकांश वर्णित टेम्प्लेट बहुत सरल हैं, ये ऑब्जेक्ट्स केवल प्लेन ओल्ड रूबी ऑब्जेक्ट्स (PORO) हैं, जो रेल में ओओपी दृष्टिकोण का उपयोग करने की सुविधा को पूरी तरह से दिखाता है।