मैंने हाल ही में मान्यताओं के लिए एक छोटा रत्न लिखा है और इसके कार्यान्वयन के बारे में आपसे साझा करना चाहूंगा।

पुस्तकालय बनाते समय जिन विचारों का अनुसरण किया गया था:

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

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

स्रोत कोड यहां पाया जा सकता है ।

आर्किटेक्चर

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

मैं आखिरी पैराग्राफ पढ़ता हूं और समझता हूं कि मैंने किसी तरह का गड़बड़ लिखा है। मुझे क्षमा करें। पहले, मैं कुछ परिभाषाएँ दूंगा और फिर एक उदाहरण दूंगा।

परिभाषित

संपूर्ण पुस्तकालय तीन सरल अवधारणाओं पर बनाया गया है: सत्यापनकर्ता , खाका और परिवर्तन ।

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

कारखाने, औपचारिक रूप से, निम्नलिखित करते हैं:

• परिवर्तनों के एक सेट के लिए T1, T2, ..., Tn , एक रचना Ta(Tb(Tc(...))) (आदेश मनमाना है)।
• परिणामी रचना को चक्रीय रूप से सर्किट पर लागू किया जाता है जब तक कि परिणाम तर्क से अलग न हो जाए।

यह मुझे ट्यूरिंग मशीन की याद दिलाता है। आउटपुट पर, हमें एक सत्यापनकर्ता (या एक अनाम फ़ंक्शन) मिलना चाहिए। कुछ और का अर्थ है कि योजना और / या परिवर्तन गलत हैं।

उदाहरण

रेडिट पर, एक व्यक्ति ने सूखे में एक उदाहरण दिया:

 user_schema = Dry::Schema.Params do required(:id).value(:integer) required(:name).value(:string) required(:age).value(:integer, included_in?: 0..150) required(:favourite_food).value(array[:string]) required(:dog).maybe do hash do required(:name).value(:string) required(:age).value(:integer) optional(:breed).maybe(:string) end end end user_schema.call(id: 123, name: "John", age: 18, ...).success? 

जैसा कि आप देख सकते हैं, जादू का उपयोग required(..).value के रूप में किया जाता है required(..).value और तरीके जैसे #array ।

मेरे उदाहरण से तुलना करें:

 is_valid_user = StValidation.build( id: Integer, name: String, age: ->(x) { x.is_a?(Integer) && (0..150).cover?(x) }, favourite_food: [String], dog: Set[NilClass, { name: String, age: Integer, breed: Set[NilClass, String] }] ) is_valid_user.call(id: 123, name: 'John', age: 18, ...) 

1. एक हैश का वर्णन करने के लिए एक हैश का उपयोग किया जाता है। मूल्यों का उपयोग मूल्यों (वर्गों, सरणियों, सेटों, अनाम कार्यों) का वर्णन करने के लिए किया जाता है। कोई भी जादू करने का तरीका ( #build नहीं माना जाता है, क्योंकि यह सिर्फ एक संक्षिप्त नाम है)।
2. अंतिम सत्यापन मूल्य एक जटिल वस्तु नहीं है, लेकिन केवल सच / गलत है, जिसके बारे में हम अंततः चिंता करते हैं। यह एक फायदा नहीं है, बल्कि एक सरलीकरण है।
3. शुष्क में, बाहरी हैश को आंतरिक से थोड़ा अलग परिभाषित किया गया है। बाहरी स्तर पर, Schema.Params पद्धति का Schema.Params , और #hash अंदर।
4. (बोनस) मेरे मामले में, मान्य वस्तु का हैश होना आवश्यक नहीं है, और किसी विशेष वाक्यविन्यास की आवश्यकता नहीं है: is_int = StValidation.build(Integer) ।
   सर्किट का प्रत्येक तत्व स्वयं एक सर्किट है। एक हैश एक जटिल योजना का उदाहरण है (यानी ऐसी योजना जिसमें अन्य योजनाएं शामिल हैं)।

संरचना

पूरे रत्न में बहुत कम भाग होते हैं:

• मुख्य नाम स्थान (मॉड्यूल) StValidation
• सत्यापनकर्ताओं की पीढ़ी के लिए जिम्मेदार कारखाना StValidation::ValidatorFactory ।
• अमूर्त सत्यापनकर्ता StValidation::AbstractValidator , जो वास्तव में, एक इंटरफ़ेस है।
• मूल सत्यापनकर्ताओं का सेट जिसे मैंने मूल "वाक्यविन्यास" में StValidation::Validators मॉड्यूल में शामिल किया है
• सुविधा और अन्य सभी तत्वों के संयोजन के लिए मुख्य मॉड्यूल के दो तरीके:
  
  • StValidation.build - परिवर्तनों का एक मानक सेट का उपयोग करना
  • StValidation.with_extra_transformations - परिवर्तनों के एक मानक सेट का उपयोग करते हुए, लेकिन इसका विस्तार करते हुए।

मानक डीएसएल

मैंने निम्नलिखित तत्वों को अपने डीएसएल में शामिल किया है:

• क्लास - एक ऑब्जेक्ट के प्रकार (उदाहरण के लिए, इंटेगर) की जांच करता है।
  मेरे सिंटैक्स में सबसे सरल सत्यापनकर्ता, अनाम फ़ंक्शन और एसेन्सवेलेडिएटर के वंशजों के अलावा, जो जनरेटर की आदिम हैं।
• बहुत कुछ योजनाओं का एक संघ है। उदाहरण: Set[Integer, ->(x) { x.nil? }] Set[Integer, ->(x) { x.nil? }] ।
  जाँचता है कि वस्तु कम से कम एक योजना से मेल खाती है। यहां तक ​​कि वर्ग को ही UnionValidator कहा जाता है।
  सबसे सरल उदाहरण एक समग्र सत्यापनकर्ता है।
• एक सरणी एक उदाहरण है: [Integer] ।
  जाँचता है कि वस्तु एक सरणी है और इसके सभी तत्व एक निश्चित योजना को पूरा करते हैं।
• एक हैश समान है, लेकिन हैश के लिए। अतिरिक्त कुंजी की अनुमति नहीं है।

परिवर्तन का सेट इस तरह दिखता है:

 def basic_transformations [ ->(bp, _factory) { bp.is_a?(Class) ? class_validator(bp) : bp }, ->(bp, factory) { bp.is_a?(Set) ? union_validator(bp, factory) : bp }, ->(bp, factory) { bp.is_a?(Hash) ? hash_validator(bp, factory) : bp }, ->(bp, factory) { bp.is_a?(Array) && bp.size == 1 ? array_validator(bp[0], factory) : bp } ] end def class_validator(klass) Validators::ClassValidator.new(klass) end def union_validator(blueprint, factory) Validators::UnionValidator.new(blueprint, factory) end # ... 

कहीं भी आसान नहीं है, क्या यह है?

त्रुटियां और # शिकायत

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

अनिवार्य रूप से, इसे सत्यापन के रूप में एक ही काम करना चाहिए, लेकिन जो विशेष रूप से गलत है उसे वापस करें
सामान्य तौर पर, सत्यापन ( #call ) को #call एक विशेष मामले के रूप में परिभाषित किया जा सकता है, बस अगर जाँच परिणाम खाली है तो जाँच करके।

हालांकि, इस तरह की मान्यता धीमी होगी (लेकिन यह महत्वपूर्ण नहीं है)।

क्योंकि बेनामी विधेय कार्य अपने आप को AbstractValidator वंश में लपेटते हैं; उनके पास #explain विधि भी होती है और बस संकेत मिलता है कि फ़ंक्शन कहाँ परिभाषित है।

कस्टम सत्यापनकर्ताओं को लिखते समय, #explain मनमाने ढंग से जटिल और स्मार्ट हो सकता है।

अनुकूलन

मेरा "वाक्यविन्यास" पुस्तकालय के केंद्र में नहीं बनाया गया है और इसलिए, इसकी आवश्यकता नहीं है। (देखें StValidation.build )।

आइए एक सरल डीएसएल की कोशिश करें जिसमें केवल संख्याएं, तार और सरणियाँ शामिल होंगी:

 validator_factory = StValidation::ValidatorFactory.new( [ -> (blueprint, _) { blueprint == :int ? ->(x) { x.is_a?(Integer) } : blueprint }, -> (blueprint, _) { blueprint == :str ? ->(x) { x.is_a?(String) } : blueprint }, lambda do |blueprint, factory| return blueprint unless blueprint.is_a?(Array) inner_validators = blueprint.map { |b| factory.build(b) } ->(x) { x.is_a?(Array) && inner_validators.zip(x).all? { |v, e| v.call(e) } } end ] ) is_int = validator_factory.build(:int) is_int.call('123') # ==> false is_int_pair = validator_factory.build([:int, :int]) is_int_pair.call([1, 2]) # ==> true is_int_pair.call([1, '2']) # ==> false 

थोड़ा भ्रमित कोड के लिए क्षमा करें। संक्षेप में, इस मामले में सरणी सूचकांक द्वारा अनुपालन की जांच करती है।

परिणाम

लेकिन उसे नहीं। मुझे इस तकनीकी समाधान पर गर्व है और इसे प्रदर्शित करना चाहता हूं :)