सूची हस्तांतरण की समस्याएं या सार "प्रवाह" क्यों

छिद्रों के सभी गैर-तुच्छ सार

जोएल स्पोल्स्की - द लॉ ऑफ़ लॉकी एब्स्ट्रक्शन

और कभी-कभी काफी सरल सार

इस लेख के लेखक।


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

एक बार एक "छोटी" छोटी सॉफ्ट कंपनी में, उन्होंने तय किया कि वस्तु के स्थान से "अमूर्त" क्यों नहीं किया जाए और वस्तु या स्थानिक या दूरस्थ वस्तु, "कार्यान्वयन का विस्तार" है या नहीं, इस तथ्य को बहुत महत्वपूर्ण बना देता है। तो DCOM प्रौद्योगिकियां और उसके उत्तराधिकारी .NET रीमोटिंग दिखाई दिए, जो डेवलपर से छिपाते थे कि वस्तु दूरस्थ है या नहीं। एक ही समय में, ये सभी "पारदर्शी परदे के पीछे" दिखाई दिए, जिसने इसके बारे में जानने के बिना एक दूरस्थ वस्तु के साथ काम करना संभव बना दिया। हालांकि, समय के साथ, यह स्पष्ट हो गया कि यह जानकारी डेवलपर के लिए महत्वपूर्ण है, क्योंकि दूरस्थ वस्तु अपवादों की एक पूरी तरह से अलग सूची उत्पन्न कर सकती है, और इसके साथ काम करने की लागत स्थानीय वस्तु के साथ बातचीत की तुलना में अतुलनीय रूप से अधिक है।



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

ऐसे ही कई उदाहरण हैं जब हमें न केवल दृश्य व्यवहार (अमूर्तता) को जानने की आवश्यकता है, बल्कि आंतरिक संरचना (कार्यान्वयन) को भी समझना होगा। अधिकांश प्रोग्रामिंग भाषाओं में, विभिन्न प्रकार के संग्रह के साथ काम करना बहुत ही समान तरीके से किया जाता है। बेस बेस या इंटरफेस (.NET के रूप में) के पीछे संग्रह "छिपा" सकते हैं, या कुछ अन्य सामान्यीकरण विधि का उपयोग कर सकते हैं (उदाहरण के लिए, C ++ में)। लेकिन, इस तथ्य के बावजूद कि हम एक ही तरह से विभिन्न संग्रहों के साथ काम कर सकते हैं, हम विशिष्ट प्रकार के संग्रह से अपनी कक्षाओं को पूरी तरह से "अनटाइ" नहीं कर सकते हैं। स्पष्ट समानता के बावजूद, हमें यह समझने की आवश्यकता है कि इस समय सबसे अच्छा क्या उपयोग किया जाता है: एक वेक्टर या दोगुनी लिंक की गई सूची, हैश-सेट या सॉर्ट किए गए सेट। मूल संचालन की जटिलता संग्रह के आंतरिक कार्यान्वयन पर निर्भर करती है: एक तत्व की खोज करना, इसे बीच में या संग्रह के अंत में सम्मिलित करना और ऐसे मतभेदों के बारे में जानना बस आवश्यक है।

आइए एक विशिष्ट उदाहरण देखें। हम सभी जानते हैं कि सूची < T> (या सी ++ में वेक्टर :: वेक्टर ) जैसे प्रकार एक साधारण सरणी के आधार पर कार्यान्वित किए जाते हैं। यदि संग्रह पहले से ही भरा है, तो एक नया तत्व जोड़ते समय, एक नया आंतरिक सरणी बनाया जाएगा, जबकि यह एक तत्व द्वारा "विकसित" होगा, लेकिन कुछ हद तक मजबूत (**)। बहुत से लोग इस व्यवहार के बारे में जानते हैं, लेकिन ज्यादातर मामलों में हम इस पर कोई ध्यान नहीं दे सकते हैं: यह सूची < T> वर्ग की "व्यक्तिगत समस्या" है और हमें परवाह नहीं है।

लेकिन मान लेते हैं कि हमें WCF के माध्यम से एनमों की एक सूची पारित करने की आवश्यकता है या सिर्फ DataContractSerializer या NetDataContractSerializer (***) कक्षाओं का उपयोग करके ऐसी सूची को अनुक्रमित करें । सूची निम्नानुसार घोषित की गई है:

public enum Color
{
Green = 1,
Red,
Blue
}

* This source code was highlighted with Source Code Highlighter .

इस तथ्य पर ध्यान न दें कि यह गणना किसी भी विशेषता के साथ चिह्नित नहीं है, यह NeDataContractSerializer के लिए कोई बाधा नहीं है। इस गणना की मुख्य विशेषता यह है कि इसमें एक शून्य मान नहीं है; गणना मूल्य 1 से शुरू होते हैं।

WCF में क्रमिक एन्यूमरेशंस की ख़ासियत यह है कि आप इस मान से संबंधित नहीं हैं।

public static string Serialize<T>(T obj)
{
// NetDataContractSerializer,
// DataContractSerializer
var serializer = new NetDataContractSerializer();
var sb = new StringBuilder ();
using ( var writer = XmlWriter.Create(sb))
{
serializer.WriteObject(writer, obj);
writer.Flush();
return sb.ToString();
}
}
Color color = (Color) 55;
Serialize(color);

* This source code was highlighted with Source Code Highlighter .

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

अब एक आइटम का एक संग्रह पास करने की कोशिश करते हैं:

var colors = new List <Color> {Color.Green};
Serialize(colors);

* This source code was highlighted with Source Code Highlighter .

हालाँकि, यह स्पष्ट रूप से सहज कोड भी एक ही सामग्री के साथ एक रन-टाइम त्रुटि की ओर जाता है, और केवल अंतर यह है कि धारावाहिक 0 के गणना मूल्य के साथ सामना नहीं कर सकता है। किस लिए ... 0 कहाँ से आ सकता है? हम एक तत्व के साथ एक सरल संग्रह को व्यक्त करने की कोशिश कर रहे हैं, जबकि इस तत्व का मूल्य बिल्कुल सही है। हालाँकि, DataContractSerializer / NetDataContractSerializer , अच्छे पुराने बाइनरी क्रमांकन की तरह, सभी क्षेत्रों तक पहुँच प्राप्त करने के लिए प्रतिबिंब का उपयोग करता है। नतीजतन, ऑब्जेक्ट का पूरा आंतरिक प्रतिनिधित्व, जो खुले और बंद दोनों क्षेत्रों में निहित है, को आउटपुट स्ट्रीम में क्रमबद्ध किया जाएगा।

चूंकि सूची < T> वर्ग को सरणी के आधार पर बनाया गया है, जब सूची में कितने तत्व हैं, इसकी परवाह किए बिना पूरे सरणी को क्रमबद्ध किया जाएगा। इसलिए, उदाहरण के लिए, दो तत्वों के संग्रह को क्रमबद्ध करते समय:

var list = new List < int > {1, 2};
string s = Serialize(list);

* This source code was highlighted with Source Code Highlighter .

आउटपुट स्ट्रीम में, हमें दो तत्व नहीं मिलते हैं, जैसा कि हम उम्मीद कर सकते हैं, लेकिन 4 (यानी क्षमता संपत्ति के अनुरूप तत्वों की संख्या, गणना नहीं):

< ArrayOfint >
< _items z:Id ="2" z:Size ="4" >
< int > 1 </ int >
< int > 2 </ int >
< int > 0 </ int >
< int > 0 </ int >
</ _items >
< _size > 2 </ _size >
< _version > 2 </ _version >
</ ArrayOfint >

* This source code was highlighted with Source Code Highlighter .

इस स्थिति में, त्रुटि संदेश का कारण जो एनुमरेशन्स की सूची को क्रमबद्ध करते समय होता है। हमारे गणना रंग में 0 के बराबर मान नहीं है, अर्थात्, सूची के आंतरिक सरणी के तत्व इस मान से भरे हुए हैं:



यह अमूर्तता के "पाठ्यक्रम" का एक और उदाहरण है, जब सूची < टी> के रूप में इस तरह के एक साधारण वर्ग का आंतरिक कार्यान्वयन भी हमें इसे सामान्य रूप से अनुक्रमित करने से रोक सकता है।

समस्या हल करना

इस समस्या के कई समाधान हैं, जबकि प्रत्येक समाधान की अपनी कमियां हैं।

1. एक डिफ़ॉल्ट मूल्य जोड़ना

इस समस्या का सबसे सरल समाधान गणना में 0 का मान जोड़ना या मौजूदा तत्वों में से किसी एक का मान बदलना है:

public enum Color
{
None = 0,
Green = 1, // Green = 0
Red,
Blue
}

* This source code was highlighted with Source Code Highlighter .

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

2. "खाली" तत्वों के बिना एक संग्रह को स्थानांतरित करना

किसी गणना के साथ कुछ करने के बजाय, आप यह सुनिश्चित कर सकते हैं कि संग्रह में ऐसे खाली तत्व नहीं हैं। आप यह कर सकते हैं, उदाहरण के लिए, इस प्रकार है:

var li1 = new List <Color> { Color.Green };
var li2 = new List <Color>(li1);

* This source code was highlighted with Source Code Highlighter .

इस स्थिति में, चर li1 में तीन अतिरिक्त खाली तत्व शामिल होंगे (इस मामले में, गणना 1 होगी, और क्षमता 4 होगी ), और चर li2 नहीं होगा (दूसरी सूची के आंतरिक सरणी में केवल 1 तत्व होगा)।

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

3. सेवा इंटरफ़ेस में अन्य प्रकार के संग्रह का उपयोग करना

अन्य डेटा संरचनाओं का उपयोग करना, जैसे कि एक सरणी, या XML क्रमांकन का उपयोग करना, जो कि DataContractSerializer के बजाय केवल सार्वजनिक सदस्यों का उपयोग करता है, इस समस्या को हल करेगा। लेकिन यह आपके लिए कितना सुविधाजनक है या नहीं।

सार प्रवाह, अवधि। यही कारण है कि विभिन्न पुस्तकालयों के आंतरिक कार्यान्वयन के माध्यम से अफवाह करना बहुत उपयोगी है। यहां तक ​​कि अगर यह पुस्तकालय पूरी तरह से अपने सभी विवरणों को छिपाता है, तो जल्द या बाद में आप एक ऐसी स्थिति का सामना करेंगे जहां इसकी आंतरिक संरचना के ज्ञान के बिना आप अपनी समस्या को हल नहीं कर सकते। डेबिट, आंतरिक डिवाइस से निपटें और डरें नहीं कि यह भविष्य में बदल जाएगा; इस तथ्य पर नहीं कि आपको इसकी आवश्यकता होगी, लेकिन कम से कम यह दिलचस्प है!

ZY वैसे, डब्ल्यूसीएफ के माध्यम से महत्वपूर्ण प्रकार पास करने के लिए दो बार सोचें सूची < टी> । यदि आपके पास 524 तत्वों का संग्रह है, तो एक महत्वपूर्ण प्रकार की 500 अतिरिक्त वस्तुओं को स्थानांतरित किया जाएगा!

-

(*) जोएल इन उद्देश्यों के लिए एक उत्कृष्ट रूपक पेश करने वाले पहले और अंतिम लेखक से दूर नहीं है। इसलिए, उदाहरण के लिए, ली कैंपबेल ने एक बार पूरी तरह से एक ही बात कही थी, लेकिन थोड़े अलग शब्दों में: "आपको उस स्तर से कम से कम एक स्तर के अमूर्त को समझना चाहिए, जिस स्तर पर आप कोड करते हैं।" संक्षिप्त नोट में विवरण: अमूर्तता के वांछित स्तर को समझने पर ।

(**) आमतौर पर, ऐसी डेटा संरचनाएं अपने आंतरिक सरणी को दोगुना करती हैं। इसलिए, उदाहरण के लिए, सूची <T> में तत्वों को जोड़ने पर, "क्षमता" इस तरह से बदल जाएगी: 0, 4, 8, 16, 32, 64, 128, 256, 512, 1024 ...

(***) डब्ल्यूसीएफ धारावाहिकों के दो मुख्य प्रकारों के बीच अंतर काफी महत्वपूर्ण है। NetDataContractSerializer , DataContractSerializer के विपरीत, SOA के सिद्धांतों का उल्लंघन करता है और CLR प्रकार के बारे में जानकारी को आउटपुट स्ट्रीम में जोड़ता है, जो "क्रॉस-प्लेटफ़ॉर्म" सेवा-उन्मुख प्रतिमान का उल्लंघन करता है। आप इसके बारे में नोट्स में पढ़ सकते हैं: WCF या NetDataContractSerializer का घोषणात्मक उपयोग क्या है ।