प्रकार-सुरक्षित पहचानकर्ता और प्रेत प्रकार

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

समस्या कथन

मान लीजिए कि हमारा कार्यक्रम कई प्रकार की संस्थाओं के साथ काम करता है। उदाहरण के लिए, विजेट ( Widget वर्ग) और गैजेट ( Gadget वर्ग) लें:

 class Widget { public: long id() const; // ... }; class Gadget { public: long id() const; // ... }; 

त्रुटि की उच्च संभावना के अलावा, पहचानकर्ताओं के रूप में "कच्चे" प्रकारों का उपयोग कोड की पठनीयता को काफी कम कर देता है। कोड को समझना बहुत आसान नहीं है, जैसे कई प्रकार जैसे std::vector<long> std::map<long, long> । प्रकार समानार्थी शब्द का प्रयोग:

 typedef long WidgetId; typedef long GadgetId; 

प्रोग्रामर को std::map<WidgetId, GadgetId> जैसे प्रकारों में हेरफेर करके अधिक अभिव्यंजक कोड लिखने की अनुमति देगा। लेकिन यह दृष्टिकोण केवल पठनीयता की समस्या को हल करेगा। कंपाइलर अभी भी नहीं जानता है कि हम WidgetId और GadgetId प्रकारों के मूल्यों को असंगत GadgetId हैं।

हम कंपाइलर को हमारे इरादे बताते हैं

यदि कोई व्यक्ति अमूर्त पहचानकर्ताओं की भीड़ के साथ कागज़ पर काम करने की आवश्यकता रखता है तो उसे क्या करना चाहिए ताकि सभी संख्याओं में भ्रमित न हों? मुझे लगता है कि पूरी तरह से उचित दृष्टिकोण पहचानकर्ताओं के लिए एक प्रकार का लेबल जोड़ना है - एक उपसर्ग या प्रत्यय जिसका अर्थ है एक पहचान योग्य इकाई। उदाहरण के लिए, K-12 का मतलब 12 नौकरियों के लिए एक कंप्यूटर हो सकता है, और P-12 - बारहवें पंजीकृत उपयोगकर्ता।

सौभाग्य से, C ++ में एक तंत्र है जो आपको अपने प्रकार - टेम्प्लेट में लेबल संलग्न करने की अनुमति देता है। हमारी समस्या को हल करने के लिए, यह हमारे लिए पर्याप्त है कि हम किस प्रकार के श्रेणीबद्ध पैरामीटर को लागू करें और पहचानकर्ता को संग्रहीत करें:

 template <typename ModelType, typename ReprType = long> class IdOf { public: typedef ModelType model_type; typedef ReprType repr_type; IdOf() : value_() {} explicit IdOf(repr_type value) : value_(value) {} repr_type value() const { return value_; } bool operator==(const IdOf &rhs) const { return value() == rhs.value(); } bool operator!=(const IdOf &rhs) const { return value() != rhs.value(); } bool operator<(const IdOf &rhs) const { return value() < rhs.value(); } bool operator>(const IdOf &rhs) const { return value() > rhs.value(); } private: repr_type value_; }; 

हमारे गैजेट और विजेट पर नई कक्षा लागू करें:

 class Gadget; class Widget; typedef IdOf<Gadget> GadgetId; typedef IdOf<Widget> WidgetId; class Widget { public: WidgetId id() const; // ... }; class Gadget { public: GadgetId id() const; // ... }; 

जिस तरह से हमने IdOf क्लास को परिभाषित किया है, IdOf लिए धन्यवाद, तार्किक त्रुटियों वाले निम्नलिखित कोड को संकलित नहीं किया जाएगा:

 // This won't compile. vector<GadgetId> gadgetIds; gadgetIds.push_back(WidgetId(5)); // This won't compile either. if (someGadget.id() == someWidget.id()) { doSomething(); } 

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

यदि हमें अभी भी विभिन्न प्रकार के पहचानकर्ताओं की तुलना करने या कच्चे मान के साथ पहचानकर्ता की तुलना करने की आवश्यकता है, तो हम हमेशा value() स्पष्ट रूप से कह सकते हैं।

प्रेत प्रकार

यह पता चला है कि जिस ट्रिक को हमने पहचानने वालों के साथ क्रैंक किया है वह कार्यात्मक प्रोग्रामिंग में काफी समय से जाना जाता है। पैरामीटर प्रकार जो परिभाषा में पैरामीटर प्रकार का उपयोग नहीं करते हैं उन्हें फैंटम प्रकार कहा जाता है।
उदाहरण के लिए, हास्केल में, एक समान तकनीक को निम्नानुसार लागू किया जा सकता है:

 newtype IdOf a = IdOf { idValue :: Int } deriving (Ord, Eq, Show, Read) 

वाह, कोड की सिर्फ एक दो लाइनें! अब हमारे मॉडल की परिभाषाएँ जोड़ें:

 data Widget = Widget { widgetId :: IdOf Widget } deriving (Show, Eq) data Gadget = Gadget { gadgetId :: IdOf Gadget } deriving (Show, Eq) 

और विभिन्न प्रकार के उदाहरण बनाकर और उनके पहचानकर्ताओं की तुलना करके वांछित व्यवहार की जाँच करें:

 Prelude> let g = Gadget (IdOf 5) Prelude> let w = Widget (IdOf 5) Prelude> widgetId w == gadgetId g <interactive>:1:15: Couldn't match type `Gadget' with `Widget' Expected type: IdOf Widget Actual type: IdOf Gadget In the return type of a call of `gadgetId' In the second argument of `(==)', namely `gadgetId g' In the expression: widgetId w == gadgetId g 

खैर, संकलक (या यों कहें, मैंने प्रयोगों के लिए ghci दुभाषिया का उपयोग किया) ने विभिन्न प्रकार के पहचानकर्ताओं की तुलना को स्वीकार करने से इनकार कर दिया। यह वही है जो आपको चाहिए।

इस तकनीक का उपयोग मुद्रा लेबल, माप की इकाइयों, और अन्य जानकारी के संख्यात्मक मानों को बाँधने के लिए किया जा सकता है जो कार्यक्रम और संकलक दोनों के लिए उपयोगी हो सकते हैं।

परिणाम

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

नुकसान एक छोटे से अधिक अक्षरों को टाइप करने (और पढ़ने) की आवश्यकता है, और, शायद, सहकर्मियों को विचार की व्याख्या करते हैं, लेकिन अक्सर कंपाइलर द्वारा तर्क की अधिक कठोर जांच के फायदे नुकसान को पछाड़ देते हैं।

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

कोई भी शक्तिशाली Boost.Units लाइब्रेरी का उल्लेख नहीं कर सकता है, जो स्वचालित आउटपुट प्रकार आउटपुट के साथ विभिन्न प्रकारों के मूल्यों पर टाइप-सुरक्षित संचालन करने की अनुमति देता है।