"शून्य" नरक और इससे कैसे बाहर निकलना है

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

डिफ़ॉल्ट मान

हम सभी ने एक विधि देखी जो कई तर्क देती है, लेकिन उनमें से आधे से अधिक वैकल्पिक हैं। परिणाम कुछ इस प्रकार है:

public function insertDiscount(   string $name,   int $amountInCents,   bool $isActive = true,   string $description = '',   int $productIdConstraint = null,   DateTimeImmutable $startDateConstraint = null,   DateTimeImmutable $endDateConstraint = null,   int $paymentMethodConstraint = null ): int 

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

यदि आप एक निश्चित भुगतान विधि के लिए छूट बनाना चाहते हैं, तो आपको निम्नानुसार विधि को कॉल करना होगा:

 insertDiscount('Discount name', 100, true, '', null, null, null, 5); 

यह कोड काम करेगा, लेकिन इसे पढ़ने वाले व्यक्ति के लिए यह पूरी तरह से समझ से बाहर है। इसका विश्लेषण करना बेहद मुश्किल हो जाता है, इसलिए हम आसानी से आवेदन का समर्थन नहीं कर सकते हैं।

आइए इस उदाहरण को तर्क से समझते हैं।

वैध छूट क्या है?

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

 insertDiscount('Discount name', 100); 

बस कोड को पढ़कर, मुझे नहीं पता है कि छूट तुरंत सक्रिय होगी। यह जानने के लिए, मुझे यह देखना होगा कि विधि हस्ताक्षर में डिफ़ॉल्ट मान हैं या नहीं।

अब कल्पना करें कि आपको कोड की 200 लाइनें पढ़ने की आवश्यकता है। क्या आप सुनिश्चित हैं कि आप छिपी जानकारी के लिए कॉल की गई विधि के प्रत्येक हस्ताक्षर की जांच करना चाहते हैं? मैं कुछ भी देखने के लिए बिना कोड को पढ़ूंगा।

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

मैं इस विधि को इस तरह फिर से लिखूंगा:

 public function insertDiscount(  string $name,  string $description,  int $amountInCents,  bool $isActive ): int 

मैंने प्रतिबंधों को पूरी तरह से हटा दिया क्योंकि हमने बाद में उन्हें अलग-अलग तरीकों का उपयोग करके जोड़ने का फैसला किया। चूंकि सभी पैरामीटर अब आवश्यक हैं, उन्हें किसी भी क्रम में व्यवस्थित किया जा सकता है। मैंने नाम के ठीक बाद विवरण रखा, क्योंकि पास होने पर कोड बेहतर पढ़ता है।

 insertDiscount(  'Discount name',  'Discount description',  100,  Discount::STATUS_ACTIVE ); 

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

अड़चनें जोड़ना

अब आप विभिन्न प्रतिबंध जोड़ सकते हैं। शून्य, शून्य, शून्य नरक से बचने के लिए, हम अलग तरीके बनाएंगे।

 public function addProductConstraint(  Discount $discount,  int $productId ): Discount; public function addDateConstraint(  Discount $discount,  DateTimeImmutable $startDate,  DateTimeImmutable $endDate ): Discount; public function addPaymentMethodConstraint(  Discount $discount,  int $paymentMethod ): Discount; 

इस प्रकार, यदि हम कुछ प्रतिबंधों के साथ एक नई छूट बनाना चाहते हैं, तो हम इसे इस तरह से करेंगे:

 $discountId = insertDiscount(  'Discount name',  'Discount description',  100,  Discount::STATUS_ACTIVE ); addPaymentMethodConstraint(  $discountId,  PaymentMethod::CREDIT_CARD ); 

अब इसकी तुलना मूल कॉल से करें। आप देखेंगे कि यह पढ़ने में कितना सुविधाजनक हो गया है।

वस्तु गुणों में अशक्त

ऑब्जेक्ट गुण में शून्य का समाधान भी समस्याओं का कारण बनता है। मैं यह नहीं बता सकता कि मैं कितनी बार ऐसी चीजें देखता हूं:

 $currencyCode = strtolower(  $record->currencyCode ); 

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

हम जहां भी करेंसी कोड का उपयोग करते हैं, हम निश्चित रूप से अशक्त चेक जोड़ सकते हैं। लेकिन फिर हम एक अलग तरह के नरक में समाप्त हो जाएंगे:

 if ($record->currencyCode === null) {  throw new \RuntimeException('Currency code cannot be null'); } if ($record->amount === null) {  throw new \RuntimeException('Amount cannot be null'); } if ($record->amount > 0) {  throw new \RuntimeException('Amount must be a positive value'); } 

लेकिन, जैसा कि आप पहले से ही समझ चुके हैं, यह सबसे अच्छा समाधान नहीं है। अपनी विधि को अव्यवस्थित करने के अलावा, आपको अब हर जगह इस परीक्षा को दोहराना चाहिए। और हर बार जब आप एक और अशक्त संपत्ति जोड़ते हैं, तो इस तरह की दूसरी जांच करना न भूलें! सौभाग्य से, एक सरल उपाय है: वस्तुओं का मूल्य।

मूल्य वस्तुओं

मूल्य वस्तुएं शक्तिशाली लेकिन सरल चीजें हैं। जिस समस्या को हम हल करने की कोशिश कर रहे थे, वह यह थी कि हमारी सभी संपत्तियों को लगातार मान्य करना आवश्यक है। लेकिन हम ऐसा करते हैं क्योंकि हम नहीं जानते कि क्या वस्तु के गुणों पर भरोसा करना संभव है, क्या वे वैध हैं। अगर हम कर सके तो क्या?

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

 final class Amount {  private $amountInCents;  private $currencyCode;  public function __construct(int $amountInCents, string $currencyCode): self  {    Assert::that($amountInCents)->greaterThan(0);    $this->amountInCents = $amountInCents;    $this->currencyCode = $currencyCode;  }  public function getAmountInCents(): int  {    return $this->amountInCents;  }  public function getCurrencyCode(): string  {    return $this->currencyCode;  } } 

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

चूंकि हम प्रकार की घोषणाओं का उपयोग करते हैं, इसलिए हम गारंटी देते हैं कि प्रकार भी सही है। इस प्रकार, हम strtolower के लिए इंट पास नहीं कर सकते। यदि आप PHP के पुराने संस्करण का उपयोग कर रहे हैं जो प्रकार की घोषणाओं का समर्थन नहीं करता है, तो आप इस पैकेज का उपयोग -> पूर्णांक () और -> स्ट्रिंग () के साथ प्रकारों की जांच करने के लिए कर सकते हैं।

ऑब्जेक्ट बनाने के बाद, मान नहीं बदले जा सकते हैं, क्योंकि हमारे पास केवल गेटर्स हैं, लेकिन कोई बसने वाला नहीं है। इसे प्रतिरक्षा कहा जाता है। फाइनल जोड़ना इस वर्ग को बसने या जादू के तरीकों को जोड़ने की अनुमति नहीं देता है। यदि आप विधि पैरामीटर में राशि $ राशि देखते हैं, तो आप 100% सुनिश्चित हो सकते हैं कि इसके सभी गुण मान्य किए गए हैं और उपयोग करने के लिए ऑब्जेक्ट सुरक्षित है। यदि मान मान्य नहीं थे, तो हम ऑब्जेक्ट नहीं बना पाएंगे।

अब मूल्य वस्तुओं की मदद से हम अपने उदाहरण को और बेहतर कर सकते हैं:

 $discount = new Discount(  'Discount name',  'Discount description',  new Amount(100, 'CAD'),  Discount::STATUS_ACTIVE ) insertDiscount($discount); 

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

जीरो हॉरर स्टोरी

आइए एक दिलचस्प मामले को देखें जिसमें अशक्त एक आवेदन में हानिकारक हो सकता है। विचार डेटाबेस से संग्रह को निकालने और इसे फ़िल्टर करने के लिए है।

 $collection = $this->findBy(['key' => 'value']); $result = $this->filter($collection, $someFilterMethod); if ($result === null) {   $result = $collection; } 

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

परिणामस्वरूप मूल संग्रह का उपयोग क्यों किया जाता है? हमें कभी पता नहीं चलेगा। मुझे संदेह है कि इस संदर्भ में डेवलपर की निश्चित धारणा थी कि अशक्त का क्या अर्थ है, लेकिन यह गलत निकला।

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

 try {  $result = $this->filter($collection, $someFilterMethod); } catch (CollectionCannotBeEmpty $e) {  // ... } 

यह कोड अद्वितीय है। एक डेवलपर इसकी गलत व्याख्या करने की संभावना नहीं है।

क्या यह प्रयास के लायक है?

यह सब कोड लिखने के लिए अतिरिक्त प्रयास जैसा दिखता है जो समान काम करता है। हाँ, यह है। लेकिन एक ही समय में आप कोड को पढ़ने और समझने में बहुत कम समय बिताएंगे, इसलिए प्रयासों को काफी पुरस्कृत किया जाएगा। हर अतिरिक्त घंटे जो मैं कोड लिखने में खर्च करता हूं, मुझे उन दिनों को बचाता है जब मुझे कोड बदलने या नई सुविधाएँ जोड़ने की आवश्यकता नहीं होती है। इसे गारंटीकृत उच्च-उपज निवेश के रूप में सोचें।

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