तर्क कहां छिपा है?

सवाल

कार्यक्रमों पर चर्चा करते समय, शब्द "तर्क" या "व्यावसायिक तर्क" का अक्सर उपयोग किया जाता है।
उदाहरण के लिए:

• (यूनिट परीक्षणों के बारे में) परीक्षणों के साथ कोड के 100% कवरेज को प्राप्त करना आवश्यक नहीं है, यह केवल तर्क का परीक्षण करने के लिए पर्याप्त है।
• (वेब अनुप्रयोगों के बारे में) नियंत्रक को कोई व्यावसायिक तर्क नहीं होना चाहिए, लेकिन केवल अन्य वर्गों के तरीकों को कॉल करना चाहिए
• VIEW लेयर में कोई व्यावसायिक तर्क नहीं होना चाहिए (यानी, JSP फाइलें)

तो, मुझे कौन बताएगा कि "तर्क" क्या है? क्या इसका मतलब कोड में कोई IF है? लेकिन क्या आईएफएस के बिना वास्तव में कोड है? या (व्यवसाय -) "तर्क" का अर्थ ग्राहक से आने वाली कोई जानकारी है? लेकिन क्या हम क्लाइंट के पैसे से कुछ कर सकते हैं जो उसने ऑर्डर नहीं किया? हम नहीं कर सकते इसलिए, हमारे सभी कोड क्लाइंट से पूरी तरह से "व्यावसायिक तर्क" हैं। इसलिए मैं कभी समझ नहीं सका कि नरक तर्क क्या है।

जवाब है

शायद इस प्रश्न का उत्तर "तर्क" शब्द के बजाय, "ज्ञान" शब्द का उपयोग किया जाता है। तर्क कोड का कोई ज्ञान है, या कोड को कैसे व्यवहार करना चाहिए। आप इसे इस तरह भी तैयार कर सकते हैं: "तर्क" वह सब है जो आप कम से कम एक बार टिप्पणी करना चाहेंगे।

उदाहरण

उदाहरण के लिए, खाता वर्ग जिसे मैंने हाल ही में अपनी परियोजना में खोदा है।

यह ऐसा ही था। हमारे कार्यालय में एक अच्छा दिन इंटरनेट दो घंटे के लिए काट दिया गया था। मैं वास्तव में काम नहीं कर सकता था - अच्छी तरह से, वहाँ, svn, जीरा, ज्ञान का आधार और इतने पर उपलब्ध नहीं थे। और मैंने कुछ वर्ग के लिए एक इकाई परीक्षण लिखने के लिए एक अभ्यास के रूप में फैसला किया। और खाते में आया:

public class Account { // Negative amount means that account is prepaid private BigDecimal amount; public BigDecimal getAmount() { return amount; } //        } 

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

नकारात्मक राशि का मतलब है कि खाता प्रीपेड है

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

 public class AccountTest { @Test public void negativeAmountMeansThatAccountIsPrepaid() { Account prepaidAccount = new Account(-123); assertTrue(prepaidAccount.isPrepaid()); } } 

चूंकि हम एक नकारात्मक "राशि" के मामले की जांच कर रहे हैं, इसलिए सकारात्मक के मामले की जांच करना अच्छा होगा:

  @Test public void positiveAmountMeansThatAccountIsInDebt() { Account indebtAccount = new Account(456); assertFalse(indebtAccount.isPrepaid()); assertTrue(indebtAccount.isInDebt()); } 

तो अनजाने में, हमारे पास दो नए तरीके हैं, जो कि प्रीपेड है और आईबीडीटी है, जिसका कार्यान्वयन, निश्चित रूप से, स्पष्ट है:

 public class Account { private BigDecimal amount; public boolean isInDebt() { return amount > 0; } public boolean isPrepaid() { return amount < 0; } } 

आप देखते हैं, पहले से ही IF कोड में दिखाई दिया है!
निम्नलिखित विचार, जो एक ही समय में दिमाग में आना चाहिए: शायद ये आईएफ पहले से कहीं पहले से थे?

मुझे थोड़ा दिखना था, लेकिन यह इसके लायक था। यह पता चला कि ये IFs वास्तव में कोड में थे, और कहीं नहीं, लेकिन JSP फ़ाइल में, अर्थात्, "दृश्य" परत में, जिसमें, परिभाषा के अनुसार, कोई तर्क नहीं होना चाहिए:

 <%-- Positive amount means that account is in debt %--> <c:if test="${account.amount > 0}"> <font color="red"> !</font> </c:if> <c:if test="${account.amount < 0}"> <font color="green"></font> </c:if> 

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

 <c:if test="${account.inDebt}"> <font color="red"> !</font> </c:if> <c:if test="${account.prepaid}"> <font color="green"></font> </c:if> 

क्या यह बेहतर हो गया है? मुझे लगता है कि यह बन गया है। यह एनकैप्सुलेशन की तरह थोड़ा अधिक है - कार्यान्वयन को छिपी हुई आंखों से छिपाना। केवल राशि वर्ग जानता है कि ग्राहक किस मामले में बकाया है या नहीं। पूरी दुनिया में कोई और नहीं जानता कि यह कैसे होता है - ग्राहक को isInDebt और isPrepaid का उपयोग करके तैयार समाधान प्राप्त होता है। सैद्धांतिक रूप से, मूल्य "ऋण" और "पूर्व भुगतान" आम तौर पर डेटाबेस के विभिन्न स्तंभों में, या यहां तक ​​कि आम तौर पर अलग-अलग तालिकाओं में और आमतौर पर अलग-अलग डेटाबेस में संग्रहीत किए जा सकते हैं। अब, दो विधियों की उपस्थिति के लिए धन्यवाद, यह तर्क Account वर्ग में छिपा हुआ (एनकैप्सुलेटेड) है।

यदि आप अभी भी इसे नहीं मानते हैं, तो कोड की मात्रा की तुलना करें।

यह था <%-- Positive amount means that account is in debt %--> <c:if test="${account.amount > 0}"> <font color="red"> !</font> </c:if>

बन गया है <c:if test="${account.inDebt}"> <font color="red"> !</font> </c:if>

आप आगे भी जा सकते हैं और getAmount() बजाय getAmount() दो अलग-अलग तरीके getPrepaidAmount() और getDoubt() । इसके अलावा, उनके अंदर आप जांच सकते हैं कि ग्राहक के पास वास्तव में ऋण है या अग्रिम भुगतान। अर्थात्, अब यह असंभव होगा, उदाहरण के लिए, ऐसा कोड लिखना:

 <%--      ,    . %--> <c:if test="${account.amount != 0}> <font color="red"> !</font> </c:if> 

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

नैतिकता

आप देखते हैं कि इकाई परीक्षण किस प्रकार पठनीय, वस्तु-उन्मुख कोड की ओर ले जाते हैं। और आप कहते हैं: "मेरे कोड में कोई तर्क नहीं है, परीक्षण के लिए कुछ भी नहीं है ..." जैसा कि यह है!

तर्क है, यह नहीं हो सकता है।