क्या उपयोगकर्ता इनपुट सत्यापन पर "बताएं, मत पूछें" लागू होते हैं?

Question

मैंने इन सभी वर्षों में ओओपी सिद्धांत "बताओ, मत पूछो" अनदेखा कर दिया होगा क्योंकि मैंने पहली बार कुछ दिनों पहले इसके बारे में सीखा था।

लेकिन संदर्भ सत्यापन कोड के बारे में एक चर्चा थी जिसे एएसपी.नेट वेब फॉर्म पेज से बाहर ले जाया गया था और डेटा/व्यापार ऑब्जेक्ट में स्थानांतरित किया गया था, और वहां कोई "मान्य()" विधि नहीं थी, केवल एक सहेजने की विधि स्वयं ने सत्यापन किया और (माना जाता है) एक अपवाद उठाया। मैंने पूछा कि यह इस तरह से क्यों डिजाइन किया गया था और मुझे ओओपी के "बताओ, मत पूछो" सिद्धांत के लिए निर्देशित किया गया था, जिसे मैंने कभी नहीं सुना था, इसलिए हमने Google पर एक साथ देखा और मुझे तुरंत शिक्षित किया गया। ;)

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

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

Answer 1

मैं AviewAview से सहमत हैं, लेकिन दुष्ट केवल अपवाद फेंक d यदि उपयोगकर्ता बताता है (नहीं करता है, तो वह पूछता है):

public Foo 
{ 
    bool Validate(Baz bar) 
    { 
     if(!is_number(bar)) return false; 
     return true; 
    } 

    AssignBar(Baz bar) 
    { 
     if (!Validate(bar)) throw numberexception(); 
    } 
} 

बताएं:

try 
{ 
    foo.AssignBar(bar); 
} 
catch(numberexception e) 
{ 
    alert('Not a number!'); 
} 

पूछें:

if (foo.Validate(bar) 
{ 
    foo.AssignBar(bar); 
} 
else 
{ 
    alert('Not a number!'); 
} 

तो AssignBar एक वैध बार उम्मीद है और एक अपवाद फेंकता यदि यह नहीं है, लेकिन हम मान्य करने के लिए एक विधि भी प्रदान करते हैं जो अपवाद नहीं फेंकता है।

Answer 2

मैंने सोचा कि यह "सर्वोत्तम प्रथाओं" और "डिजाइन पद्धतियों" के भार की तरह लग रहा है, लेकिन अब यह मुझे समझ में आता है। इसे इस तरह देखें:

कल्पना करें कि व्यवसाय ऑब्जेक्ट में सत्यापन डालने की कल्पना करें, लेकिन प्रस्तुति परत में "सत्यापन विफल होने पर मैं क्या करूँ?" यह एकाधिक सत्यापन प्रस्तुति परतों को समान सत्यापन तर्क का पुन: उपयोग करने की अनुमति देगा, लेकिन हैंडल अलग ढंग से। त्रुटियों

public Foo 
{ 
    Validate(Baz bar) 
    { 
     if(!is_number(bar)) throw numberexception(); 
    } 

    AssignBar(Baz bar) 
    { 
     Validate(bar); 
    } 
} 


//... 

try 
{ 
    foo.AssignBar(bar); 
} 
catch(numberexception e) 
{ 
    alert('Not a number!'); 
} 

nb आप अपवाद फेंकने के बारे में सभी आप चाहते हैं का तर्क कर सकते हैं, यह एक उदाहरण के रूप में किया गया था। लौटें राज्यों, bools, जो कुछ भी आप चाहते हैं।

Answer 3

मुझे आश्चर्य है कि यह "पूछो मत पूछो" की तुलना में "चिंताओं को अलग करने" का एक मुद्दा है। डेटा को सत्यापित करने के लिए किसकी ज़िम्मेदारी है? तर्कसंगत रूप से, यह जारी रखने के लिए जिम्मेदार चीज है।

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