मजबूती के सिद्धांत के साथ अपने रूबी कोड को सरल बनाएं

मैंने मूल रूप से इनमें से बहुत से विचार कॉन्फिडेंट रूबी से सीखे हैं, जो मेरी पसंदीदा रूबी पुस्तकों में से एक है। अगर आपको यह पोस्ट अच्छी लगी हो तो आप इसे खरीद कर पूरी बात पढ़ लें। वहाँ ऐसा . है वहां बहुत अच्छी चीजें हैं।

आपका current_user विधि एक User लौटाती है , सिवाय इसके कि जब कोई उपयोगकर्ता न हो और यह शून्य हो जाए। एक search विधि एक Array लौटाती है परिणामों का, जब तक कि केवल एक परिणाम न हो, और यह इसके बजाय केवल वही परिणाम देता है। उचित लगता है, है ना? शायद सुविधाजनक भी!

लेकिन जल्द ही, ये निर्णय आपके कोड को if कथनों के पहाड़ के नीचे दबा देंगे। हो सकता है कि यह if kind_of? . का एक समूह हो चारों ओर छिड़का। या हो सकता है कि आपको ऐसा लगे कि आपको हर जगह पर शून्य की जांच करनी है। या इससे भी बदतर, NoMethodError जब भी आप कोई नई सुविधा शिप करते हैं तो यह दिखना शुरू हो जाता है। लगता है कि यह एक और हॉटफिक्स का समय है!

हालांकि, इसे रोकने का एक तरीका है, और इसके लिए केवल थोड़ी सी सोच-विचार की आवश्यकता है।

मजबूती का सिद्धांत

कंप्यूटिंग में एक सिद्धांत है जो कहता है,

आप जो करते हैं उसमें रूढ़िवादी रहें, जो आप दूसरों से स्वीकार करते हैं उसमें उदार रहें।

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

अंतिम भाग पर ध्यान केंद्रित करना:जब कोई व्यक्ति आपके द्वारा लिखी गई विधि को कॉल करता है, तो उन्हें पता होना चाहिए कि वह विधि वास्तव में क्या लौटाएगी।

अपने आउटपुट के बारे में विचारशील रहें

रेल 2.1 के ActiveRecord::Errors#on के कार्यान्वयन पर एक नज़र डालें :

# File activerecord/lib/active_record/validations.rb, line 212
def on(attribute)
  attribute = attribute.to_s
  return nil unless @errors.has_key?(attribute)
  errors = @errors[attribute].map(&:to_s)
  errors.size == 1 ? errors.first : errors
end

कॉल किए जाने पर, यह या तो Array लौटा सकता है का String एस, एक String , या nil . यह कॉलर पर निर्भर करता है कि वह किस प्रकार की वस्तु से निपट रहा है। यह एक बुरा विचार है:

• कॉल करने वाले को टाइप-चेकिंग के साथ अपने कोड को खराब करना पड़ता है।

• कॉल करने वाले को बहुत कुछ जानना होगा जिस तरीके से यह कॉल कर रहा है उसके बारे में। कम से कम, इसे हर प्रकार की वस्तु को जानने की जरूरत है जो विधि वापस आ सकती है और प्रत्येक प्रकार को कब वापस किया जा सकता है।

• आपके पास परीक्षण करने के लिए अधिक किनारे के मामले हैं। यदि आप आश्वस्त होना चाहते हैं कि आपका कोड वही कर रहा है जो उसे करना चाहिए, तो आपको तीनों परिदृश्यों को आज़माना होगा।

आपके तरीके उनके वापस आने के बारे में संगत होने चाहिए। यदि आप आमतौर पर Array लौटाते हैं , वह करें जो आपको हमेशा . करने के लिए करना है एक Array लौटाएं . यदि आप आमतौर पर User . लौटाते हैं , लेकिन कभी-कभी शून्य लौटते हैं, आप एक नल उपयोगकर्ता ऑब्जेक्ट बना सकते हैं और वह . वापस कर सकते हैं शून्य के बजाय।

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

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

और यदि आप सोच रहे थे, रेल ने बाद के संस्करणों में उस विधि को ठीक कर दिया:

# File activemodel/lib/active_model/errors.rb, line 133
def [](attribute)
  get(attribute.to_sym) || set(attribute.to_sym, [])
end

अब यह हमेशा एक Array देता है . उनके लिए आसान और हमारे लिए आसान।

विसंगति को समाप्त करें

अगली बार जब आप स्वयं को "एक Array . लौटाते हुए पाएं या nil ”, बस एक Array लौटाएं . अपने कोडबेस पर एक नज़र डालें और देखें कि आप kind_of? . का उपयोग कहां कर रहे हैं? और respond_to? . देखें कि क्या आप एक ही प्रकार को वापस करने के लिए उस कोड द्वारा बुलाए गए तरीकों को दोबारा कर सकते हैं।

और उन अनुमानों के रूप में देखें जिन्हें आप अपने प्रोजेक्ट के माध्यम से अपने रिटर्न वैल्यू के बारे में बना सकते हैं और अपने सभी नजदीकी कोड को सरल बना सकते हैं।