गतिशील सरणियों और कस्टम संग्रह कक्षाओं के साथ काम करने के लिए नियम

गतिशील सरणियों और कस्टम संग्रह कक्षाओं के साथ काम करने के लिए नियम
यहां ऐसे नियम दिए गए हैं जिनका मैं डायनेमिक सरणियों के साथ काम करते समय पालन करता हूं। वास्तव में, यह सरणियों को डिजाइन करने के लिए एक मार्गदर्शिका है, लेकिन मैं इसे वस्तुओं को डिजाइन करने के लिए एक मार्गदर्शिका में नहीं रखना चाहता था, क्योंकि प्रत्येक वस्तु-उन्मुख भाषा में गतिशील सरणियां नहीं हैं। उदाहरण PHP में लिखे गए हैं क्योंकि यह जावा के समान है (जिसे आप पहले से परिचित हो सकते हैं), लेकिन अंतर्निहित संग्रह कक्षाओं और इंटरफेस के बजाय गतिशील सरणियों के साथ।

एक सूची के रूप में सरणियों का उपयोग करना

सभी आइटम एक ही प्रकार के होने चाहिए।

यदि आप एक सूची (एक निश्चित क्रम में मूल्यों का संग्रह) के रूप में एक सरणी का उपयोग करते हैं, तो सभी मान एक ही प्रकार के होने चाहिए:

$goodList = [ 'a', 'b' ]; $badList = [ 'a', 1 ]; 

सामान्य सूची प्रकार एनोटेशन शैली है: @var array<TypeOfElment> । सुनिश्चित करें कि आप एक इंडेक्स प्रकार नहीं जोड़ते हैं, यह हमेशा int होना चाहिए।

प्रत्येक तत्व के सूचकांक को अनदेखा करना आवश्यक है

PHP स्वचालित रूप से प्रत्येक सूची आइटम (0, 1, 2, आदि) के लिए एक नया सूचकांक बनाएगी। हालाँकि, आपको न तो इन अनुक्रमणिकाओं पर भरोसा करना चाहिए, न ही सीधे इनका उपयोग करना चाहिए। ग्राहक केवल iterable countable और countable पर भरोसा कर सकते countable ।

इसलिए आप स्वतंत्र रूप से foreach और count() उपयोग कर सकते हैं, लेकिन सूची आइटम के चारों ओर चक्र करने के for उपयोग न करें:

 // Good loop: foreach ($list as $element) { } // Bad loop (exposes the index of each element): foreach ($list as $index => $element) { } // Also bad loop (the index of each element should not be used): for ($i = 0; $i < count($list); $i++) { } 

यदि सूची में कोई अनुक्रमणिका नहीं हैं, या तत्वों की संख्या से अधिक अनुक्रमित हैं, तो PHP में, लूप के for बिल्कुल भी काम नहीं किया जा सकता है।

आइटम हटाने के बजाय एक फ़िल्टर का उपयोग करें

आप अनुक्रमणिका ( unset() ) द्वारा आइटम हटाना चाहते हैं, लेकिन इसे हटाने के बजाय array_filter() का उपयोग करके कोई अवांछित तत्व नहीं के साथ एक नई सूची बनाना बेहतर है।

फिर, किसी को तत्व सूचकांकों पर भरोसा नहीं करना चाहिए। तो array_filter() उपयोग करते समय , इंडेक्स द्वारा तत्वों को फ़िल्टर करने के लिए फ्लैग पैरामीटर का उपयोग न करें, या तत्व और इंडेक्स द्वारा भी।

 // Good filter: array_filter( $list, function (string $element): bool { return strlen($element) > 2; } ); // Bad filter (uses the index to filter elements as well) array_filter( $list, function (int $index): bool { return $index > 3; }, ARRAY_FILTER_USE_KEY ); // Bad filter (uses both the index and the element to filter elements) array_filter( $list, function (string $element, int $index): bool { return $index > 3 || $element === 'Include'; }, ARRAY_FILTER_USE_BOTH ); 

एसोसिएटिव एरे के रूप में एरे का उपयोग करना

यदि चाबियाँ प्रासंगिक हैं और अनुक्रमणिका (0, 1, 2, आदि) नहीं हैं, तो स्वतंत्र रूप से साहचर्य सरणियों का उपयोग करें (एक संग्रह जिसमें से आप उनकी अद्वितीय कुंजियों द्वारा मान निकाल सकते हैं)।

सभी कुंजियाँ एक ही प्रकार की होनी चाहिए।

साहचर्य सरणियों का उपयोग करने का पहला नियम: सभी चाबियाँ एक ही प्रकार की होनी चाहिए (सबसे अधिक बार यह string )।

 $goodMap = [ 'foo' => 'bar', 'bar' => 'baz' ]; // Bad (uses different types of keys) $badMap = [ 'foo' => 'bar', 1 => 'baz' ]; 

सभी मान एक ही प्रकार के होने चाहिए।

मूल्यों पर भी यही लागू होता है: वे एक ही प्रकार के होने चाहिए।

 $goodMap = [ 'foo' => 'bar', 'bar' => 'baz' ]; // Bad (uses different types of values) $badMap = [ 'foo' => 'bar', 'bar' => 1 ]; 

एक प्रकार की व्याख्या करने के लिए एक सामान्य शैली है: @var array<TypeOfKy, TypeOfValue> ।

सहयोगी सरणियाँ निजी रहनी चाहिए

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

 // Exposing a list is fine /** * @return array<User> */ public function allUsers(): array { // ... } // Exposing a map may be troublesome /** * @return array<string, User> */ public function usersById(): array { // ... } // Instead, offer a method to retrieve a value by its key /** * @throws UserNotFound */ public function userById(string $id): User { // ... } 

कई प्रकार के मूल्यों के साथ वस्तुओं को साहचर्य सरणियों के रूप में उपयोग करें

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

 final class SillyRegisterUserCommand { public string $username; public string $plainTextPassword; public bool $wantsToReceiveSpam; public int $answerToIAmNotARobotQuestion; } 

नियम के अपवाद

लाइब्रेरी और फ्रेमवर्क को कभी-कभी सरणियों के उपयोग की आवश्यकता अधिक गतिशील रूप से होती है। फिर पिछले नियमों का पालन करना असंभव (और अवांछनीय) है। उदाहरणों में डेटाबेस तालिका में संग्रहीत डेटा का आकार , और सिम्फनी में फॉर्म कॉन्फ़िगरेशन शामिल हैं ।

कस्टम संग्रह कक्षाएं

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

क्या इंगित करता है कि आपको कस्टम संग्रह ऑब्जेक्ट में सरणी को लपेटने की आवश्यकता है?

• किसी सरणी से संबंधित तर्क का दोहराव।
  
• सरणी की सामग्री के बारे में ग्राहकों को बहुत सारे विवरणों के साथ काम करना पड़ता है।
  

डुप्लिकेट तर्क को रोकने के लिए एक कस्टम संग्रह वर्ग का उपयोग करें।

यदि समान सरणी के साथ काम करने वाले कई क्लाइंट एक ही कार्य करते हैं (उदाहरण के लिए, फ़िल्टर, तुलना, कम, गिनती), तो डुप्लिकेट को कस्टम संग्रह वर्ग का उपयोग करके हटाया जा सकता है। डुप्लिकेट लॉजिक को एक संग्रह वर्ग विधि में स्थानांतरित करना किसी भी क्लाइंट को समान कार्य करने की अनुमति देता है बस संग्रह विधि को कॉल करके:

 $names = [/* ... */]; // Found in several places: $shortNames = array_filter( $names, function (string $element): bool { return strlen($element) < 5; } ); // Turned into a custom collection class: use Assert\Assert; final class Names { /** * @var array<string> */ private array $names; public function __construct(array $names) { Assert::that()->allIsString($names); $this->names = $names; } public function shortNames(): self { return new self( array_filter( $this->names, function (string $element): bool { return strlen($element) < 5; } ) ); } } $names = new Names([/* ... */]); $shortNames = $names->shortNames(); 

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

कस्टम संग्रह वर्ग के साथ ग्राहकों को अनबाइंड करें

यदि कोई क्लाइंट किसी सरणी के माध्यम से साइकिल चलाता है, तो चयनित तत्वों से डेटा का हिस्सा लेता है और उनके साथ कुछ करता है, यह क्लाइंट सभी संबंधित प्रकारों के साथ निकटता से जुड़ जाता है: सरणी, तत्व, पुनर्प्राप्त मान, चयनकर्ता विधि, आदि। इस तरह के एक गहरे बंधन के कारण, क्लाइंट को तोड़े बिना इन प्रकारों से संबंधित किसी भी चीज़ को बदलना आपके लिए अधिक कठिन होगा। इस मामले में, आप कस्टम संग्रह कक्षा में सरणी को भी लपेट सकते हैं और सही उत्तर दे सकते हैं, जो ग्राहक के अंदर की गणना को ढीला कर रहा है और संग्रह के बंधन को ढीला कर रहा है।

 $lines = []; $sum = 0; foreach ($lines as $line) { if ($line->isComment()) { continue; } $sum += $line->quantity(); } // Turned into a custom collection class: final class Lines { public function totalQuantity(): int { $sum = 0; foreach ($lines as $line) { if ($line->isComment()) { continue; } $sum += $line->quantity(); } return $sum; } } 

कस्टम संग्रह कक्षाओं के लिए कुछ नियम

उन्हें अपरिवर्तनीय बनाओ

ऐसे परिवर्तनों का प्रदर्शन करते समय, संग्रह उदाहरण के मौजूदा संदर्भ प्रभावित नहीं होने चाहिए। इसलिए, इस रूपांतरण को करने वाली किसी भी विधि को कक्षा का एक नया उदाहरण वापस करना चाहिए, जैसा कि हमने पिछले उदाहरण में देखा था:

 final class Names { /** * @var array<string> */ private array $names; public function __construct(array $names) { Assert::that()->allIsString($names); $this->names = $names; } public function shortNames(): self { return new self( /* ... */ ); } } 

बेशक, यदि आप एक आंतरिक सरणी को परिवर्तित करते हैं, तो आप दूसरे प्रकार के संग्रह या साधारण सरणी में परिवर्तित कर सकते हैं। हमेशा की तरह, सुनिश्चित करें कि सही प्रकार वापस आ गया है।

केवल वही व्यवहार प्रदान करें जो ग्राहकों को वास्तव में चाहिए

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

IteratorAggregate और ArrayIterator का उपयोग करें

यदि आप PHP के साथ काम करते हैं, तो Iterator इंटरफ़ेस के सभी तरीकों (आंतरिक ArrayIterator बचाने आदि) को लागू करने के बजाय, केवल IteratorAggregate इंटरफ़ेस लागू करें और इसे आंतरिक सरणी के आधार पर ArrayIterator का एक उदाहरण वापस करने दें:

 final class Names implements IteratorAggregate { /** * @var array<string> */ private array $names; public function __construct(array $names) { Assert::that()->allIsString($names); $this->names = $names; } public function getIterator(): Iterator { return new ArrayIterator($this->names); } } $names = new Names([/* ... */]); foreach ($names as $name) { // ... } 

समझौता

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