नमस्कार, हेब्र! यहां ओपन-क्लोज्ड प्रिंसिपल के रॉबर्ट मार्टिन के एक लेख का अनुवाद है, जिसे उन्होंने जनवरी 1996 में प्रकाशित किया था। लेख, इसे हल्के ढंग से रखने के लिए, नवीनतम नहीं है। लेकिन RuNet में, SOLID के बारे में अंकल बॉब के लेख केवल काट-छाँट के रूप में हैं, इसलिए मैंने सोचा था कि एक पूर्ण अनुवाद अतिश्योक्तिपूर्ण नहीं होगा।

मैंने पत्र ओ से शुरू करने का फैसला किया, चूंकि खुलेपन-बंद होने का सिद्धांत, वास्तव में, केंद्रीय है। अन्य बातों के अलावा, कई महत्वपूर्ण सूक्ष्मताएं हैं जो ध्यान देने योग्य हैं:

• कोई भी कार्यक्रम 100% "बंद" नहीं हो सकता है।
• ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग (OOP) वास्तविक दुनिया की भौतिक वस्तुओं के साथ नहीं, बल्कि अवधारणाओं के साथ संचालित होती है - उदाहरण के लिए, "आदेश" की अवधारणा।

यह C ++ रिपोर्ट के लिए मेरे इंजीनियर नोट्स कॉलम का पहला लेख है। इस कॉलम में प्रकाशित लेख C ++ और OOP के उपयोग पर ध्यान केंद्रित करेंगे और सॉफ्टवेयर विकास में आने वाली कठिनाइयों को छूएंगे। मैं इंजीनियरों को अभ्यास करने के लिए सामग्रियों को व्यावहारिक और उपयोगी बनाने की कोशिश करूंगा। इन लेखों में ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के प्रलेखन के लिए मैं बुच के अंकन का उपयोग करूँगा।

ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के साथ कई हेयूरिस्टिक्स जुड़े हुए हैं। उदाहरण के लिए, "सभी सदस्य चर निजी होने चाहिए", या "वैश्विक चर से बचा जाना चाहिए", या "रनटाइम पर प्रकार का निर्धारण खतरनाक है"। ऐसे उत्तराधिकारियों का क्या कारण है? वे सच क्यों हैं? क्या वे हमेशा सच होते हैं? यह स्तंभ इन उत्तराधिकारियों के आधार पर डिजाइन सिद्धांत की खोज करता है - खुलेपन-बंद होने का सिद्धांत।
इवर जैकबसन ने कहा: “जीवन चक्र के दौरान सभी प्रणालियाँ बदल जाती हैं। यह उस सिस्टम को ध्यान में रखते हुए पैदा किया जाना चाहिए, जिसमें एक से अधिक संस्करण होने की उम्मीद है। ” हम एक प्रणाली को कैसे डिजाइन कर सकते हैं ताकि यह परिवर्तन के चेहरे पर स्थिर हो और जिसमें एक से अधिक संस्करण होने की उम्मीद हो? बर्ट्रेंड मेयर ने हमें 1988 में इस बारे में बताया, जब खुलेपन-निकटता के प्रसिद्ध सिद्धांत को तैयार किया गया था:

कार्यक्रम संस्थाओं (कक्षाएं, मॉड्यूल, फ़ंक्शन, आदि) को विस्तार के लिए खुला होना चाहिए और परिवर्तनों के लिए बंद होना चाहिए।

यदि प्रोग्राम में एक परिवर्तन निर्भर मॉड्यूल में परिवर्तन का एक झरना मजबूर करता है, तो प्रोग्राम में "खराब" डिज़ाइन के अवांछनीय संकेत दिखाई देते हैं।

कार्यक्रम नाजुक, अनम्य, अप्रत्याशित और अप्रयुक्त हो जाता है। खुलेपन-घनिष्ठता का सिद्धांत इन समस्याओं को बहुत ही सरल तरीके से हल करता है। वह कहते हैं कि ऐसे मॉड्यूलों को डिजाइन करना आवश्यक है जो कभी नहीं बदलते हैं । जब आवश्यकताएं बदल जाती हैं, तो आपको पुराने, पहले से ही कार्यरत कोड को बदलने के बजाय नए कोड जोड़कर ऐसे मॉड्यूल के व्यवहार का विस्तार करना होगा।

विवरण

खुलेपन-निकटता के सिद्धांत को पूरा करने वाले मॉड्यूल की दो मुख्य विशेषताएं हैं:

1. विस्तार के लिए खोलें। इसका मतलब है कि मॉड्यूल के व्यवहार का विस्तार किया जा सकता है। यही है, हम एप्लिकेशन के लिए बदलती आवश्यकताओं के अनुसार या नए अनुप्रयोगों की जरूरतों को पूरा करने के लिए मॉड्यूल में नया व्यवहार जोड़ सकते हैं।
2. बदलाव के लिए बंद। इस तरह के एक मॉड्यूल का स्रोत कोड अछूत है। किसी को भी इसमें बदलाव करने का अधिकार नहीं है।

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

समाधान की कुंजी अमूर्तता है।

C ++ में, ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के सिद्धांतों का उपयोग करके, निश्चित अमूर्त बनाना संभव है जो संभव व्यवहारों के असीमित सेट का प्रतिनिधित्व कर सकता है।

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

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

बंद ग्राहक

और निम्नलिखित आरेख संबंधित डिजाइन विकल्प दिखाता है, जो खुलेपन-निकटता के सिद्धांत को पूरा करता है। इस मामले में, AbstractServer वर्ग एक सार वर्ग है, जिसके सभी सदस्य कार्य आभासी हैं। Client वर्ग अमूर्तता का उपयोग करता है। हालाँकि, Client वर्ग की ऑब्जेक्ट Server उत्तराधिकारी वर्ग की वस्तुओं का उपयोग करेंगे। यदि हम Client क्लास की वस्तुओं को एक अलग सर्वर वर्ग का उपयोग करना चाहते हैं, तो हम AbstractServer क्लास के एक नए वंशज का परिचय देंगे। Client वर्ग अपरिवर्तित रहेगा।

क्लाइंट खोलें

Shape सार

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

सी में, प्रक्रियात्मक प्रोग्रामिंग तकनीकों का उपयोग करते हुए जो खुले-पास के सिद्धांत को पूरा नहीं करते हैं, हम इस समस्या को हल कर सकते हैं जैसा कि सूची 1 में दिखाया गया है। यहां हम एक ही तत्व के साथ कई डेटा संरचनाएं देखते हैं। यह तत्व एक प्रकार का कोड है जो एक सर्कल या वर्ग के रूप में डेटा संरचना की पहचान करता है। DrawAllShapes फ़ंक्शन इन डेटा संरचनाओं को पॉइंटर्स की एक सरणी से गुजरता है, प्रकार कोड को पहचानता है और फिर संबंधित फ़ंक्शन ( DrawCircle या DrawSquare ) को कॉल करता है।

 // 1 //  /    enum ShapeType {circle, square} struct Shape { ShapeType itsType; }; struct Circle { ShapeType itsType; double itsRadius; Point itsCenter; }; struct Square { ShapeType itsType; double itsSide; Point itsTopLeft; }; // //     // void DrawSquare(struct Square*) void DrawCircle(struct Circle*); typedef struct Shape *ShapePointer; void DrawAllShapes(ShapePointer list[], int n) { int i; for (i=0; i<n; i++) { struct Shape* s = list[i]; switch (s->itsType) { case square: DrawSquare((struct Square*)s); break; case circle: DrawCircle((struct Circle*)s); break; } } } 

DrawAllShapes फ़ंक्शन खुलेपन-बंद होने के सिद्धांत को पूरा नहीं DrawAllShapes , क्योंकि यह नए प्रकार के आकारों से "बंद" नहीं हो सकता है। अगर मैं इस सूची का विस्तार करना चाहता था जिसमें एक सूची से आकृतियों को आकर्षित करने की क्षमता शामिल है जिसमें त्रिकोण शामिल हैं, तो मुझे फ़ंक्शन को बदलना होगा। वास्तव में, मुझे प्रत्येक नए प्रकार के आकार के लिए फ़ंक्शन को बदलना होगा जो मुझे आकर्षित करने की आवश्यकता है।

बेशक, यह कार्यक्रम केवल एक उदाहरण है। वास्तविक जीवन में, DrawAllShapes फ़ंक्शन से switch ऑपरेटर को पूरे आवेदन में विभिन्न कार्यों में बार-बार दोहराया जाएगा, और प्रत्येक कुछ अलग करेगा। इस तरह के एक अनुप्रयोग में नए आकार जोड़ने का मतलब है कि ऐसे सभी स्थान जहां इस तरह के switch (या if/else चेन) का उपयोग किया जाता है, और उनमें से प्रत्येक के लिए एक नया आकार जोड़ रहा है। इसके अलावा, यह बहुत संभावना नहीं है कि सभी switch और if/else श्रृंखला DrawAllShapes में भी संरचित DrawAllShapes । यह बहुत अधिक संभावना है कि if को तार्किक ऑपरेटरों के साथ जोड़ if जाएगा या case switch ब्लॉक को इस तरह से जोड़ switch जाएगा जैसे कोड में किसी विशेष स्थान को "सरल" करना है। इसलिए, उन सभी स्थानों को खोजने और समझने की समस्या जहां आपको एक नया आंकड़ा जोड़ने की आवश्यकता है, वे गैर-तुच्छ हो सकते हैं।

लिस्टिंग 2 में, मैं कोड दिखाऊंगा जो एक वर्ग / सर्कल समाधान प्रदर्शित करता है जो खुलेपन-बंद होने के सिद्धांत को पूरा करता है। एक सार Shape वर्ग पेश किया गया है। इस अमूर्त वर्ग में एक शुद्ध आभासी Draw फंक्शन होता है। Circle और Square वर्ग Shape क्लास के वंशज हैं।

 // 2 //  /  - class Shape { public: virtual void Draw() const = 0; }; class Square : public Shape { public: virtual void Draw() const; }; class Circle : public Shape { public: virtual void Draw() const; }; void DrawAllShapes(Set<Shape*>& list) { for (Iterator<Shape*>i(list); i; i++) (*i)->Draw(); } 

ध्यान दें कि यदि हम एक नए तरह के आकार को आकर्षित करने के लिए DrawAllShapes 2 में DrawAllShapes फ़ंक्शन के व्यवहार को विस्तारित करना चाहते हैं, तो हमें केवल यह करना होगा कि हम Shape वर्ग का एक नया वंशज जोड़ दें। DrawAllShapes फ़ंक्शन को बदलने की कोई आवश्यकता नहीं है। इसलिए, DrawAllShapes खुलेपन-निकटता के सिद्धांत को पूरा करता है। कार्य को बदले बिना ही इसके व्यवहार का विस्तार किया जा सकता है।

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

इसलिए, प्रोग्राम जो खुलेपन-निकटता के सिद्धांत को पूरा करते हैं, नए कोड को जोड़कर बदले जाते हैं, और मौजूदा को बदलकर नहीं। वे उन कार्यक्रमों की विशेषता में बदलाव नहीं करते हैं जो इस सिद्धांत के अनुरूप नहीं हैं।

बंद की गई प्रवेश रणनीति

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

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

अतिरिक्त निकटता प्राप्त करने के लिए अमूर्तता का उपयोग

हम ड्राइंग ऑर्डर में बदलाव से DrawAllShapes फ़ंक्शन को कैसे बंद कर सकते हैं? याद रखें कि बंद होना अमूर्तता पर आधारित है। इसलिए, DrawAllShapes को ऑर्डर करने से DrawAllShapes लिए, हमें "ऑर्डरिंग एब्स्ट्रक्शन" के कुछ प्रकार की आवश्यकता है। आदेश देने का एक विशेष मामला, ऊपर प्रस्तुत किया गया है, एक प्रकार के आंकड़े को दूसरे प्रकार के आंकड़ों के सामने खींच रहा है।

आदेश देने की नीति का तात्पर्य है कि दो वस्तुओं के साथ, आप यह निर्धारित कर सकते हैं कि कौन सा पहले खींचा जाना चाहिए। इसलिए, हम Shape नामक वर्ग के लिए एक विधि को परिभाषित कर सकते हैं, जिसे Precedes कहा जाता है, जो एक अन्य Shape वस्तु को एक तर्क के रूप में लेता है और बूलियन मान को true लौटाता है, यदि यह संदेश प्राप्त करने वाले Shape वर्ग ऑब्जेक्ट को Shape वर्ग ऑब्जेक्ट से पहले सॉर्ट करने की आवश्यकता होती है एक तर्क के रूप में पारित किया।

C ++ में, इस फ़ंक्शन को "<" ऑपरेटर को ओवरलोड करने के रूप में दर्शाया जा सकता है। 3 की सूची Shape वर्ग को छँटाई के तरीकों से दिखाता है।

अब जब हमारे पास Shape वर्ग की वस्तुओं के क्रम को निर्धारित करने का एक तरीका है, हम उन्हें सॉर्ट कर सकते हैं और फिर उन्हें आकर्षित कर सकते हैं। लिस्टिंग 4 इसी C ++ कोड को दिखाता है। यह मेरी पुस्तक में विकसित Components श्रेणी से Set , OrderedSet और Iterator वर्गों का उपयोग करता है (बूच विधि, रॉबर्ट सी। मार्टिन, अप्रेंटिस हॉल, 1995 का उपयोग करके डिजाइनिंग ऑब्जेक्ट ओरिएंटेड सी ++ एप्लीकेशन)।

इसलिए, हमने Shape वर्ग की वस्तुओं के क्रम को लागू किया है और उन्हें उचित क्रम में चित्रित किया है। लेकिन हमारे पास अभी भी ऑर्डरिंग के अमूर्तन का कार्यान्वयन नहीं है। जाहिर है, ऑर्डर को निर्धारित करने के लिए प्रत्येक Shape ऑब्जेक्ट को Precedes विधि को ओवरराइड करना चाहिए। यह कैसे काम कर सकता है? Circle::Precedes में किस कोड को लिखने की आवश्यकता है Circle::Precedes ताकि वृत्त वर्गों के लिए तैयार हों? लिस्टिंग 5 पर ध्यान दें।

 // 3 //  Shape    . class Shape { public: virtual void Draw() const = 0; virtual bool Precedes(const Shape&) const = 0; bool operator<(const Shape& s) {return Precedes(s);} }; 

 // 4 // DrawAllShapes   void DrawAllShapes(Set<Shape*>& list) { //    OrderedSet  . OrderedSet<Shape*> orderedList = list; orderedList.Sort(); for (Iterator<Shape*> i(orderedList); i; i++) (*i)->Draw(); } 

 // 5 //    bool Circle::Precedes(const Shape& s) const { if (dynamic_cast<Square*>(s)) return true; else return false; } 

यह स्पष्ट है कि यह फ़ंक्शन खुलेपन-निकटता के सिद्धांत को पूरा नहीं करता है। Shape क्लास के नए वंशजों से इसे बंद करने का कोई तरीका नहीं है। हर बार Shape वर्ग का एक नया वंशज दिखाई देता है, इस फ़ंक्शन को बदलना होगा।

क्लोजर प्राप्त करने के लिए डेटा ड्रिवन अप्रोच का उपयोग करना

Shape वर्ग के उत्तराधिकारियों की निकटता एक सारणीबद्ध दृष्टिकोण का उपयोग करके प्राप्त की जा सकती है जो प्रत्येक विरासत वर्ग में परिवर्तनों को उत्तेजित नहीं करती है। इस दृष्टिकोण का एक उदाहरण सूची 6 में दिखाया गया है।

इस दृष्टिकोण का उपयोग करते हुए, हमने DrawAllShapes फ़ंक्शन को ऑर्डर करने से संबंधित परिवर्तनों से, और Shape क्लास के प्रत्येक वंशज को सफलतापूर्वक बंद कर दिया - एक नए वंश को शुरू करने से या Shape क्लास की वस्तुओं की ऑर्डरिंग पॉलिसी में बदलाव से इस प्रकार के आधार पर (उदाहरण के लिए, जैसे कि Squares वर्ग की वस्तुएं) पहले खींचा जाए)।

 // 6 //     #include <typeinfo.h> #include <string.h> enum {false, true}; typedef int bool; class Shape { public: virtual void Draw() const = 0; virtual bool Precedes(const Shape&) const; bool operator<(const Shape& s) const {return Precedes(s);} private: static char* typeOrderTable[]; }; char* Shape::typeOrderTable[] = { "Circle", "Square", 0 }; //      . //   ,    //  . ,    , //      bool Shape::Precedes(const Shape& s) const { const char* thisType = typeid(*this).name(); const char* argType = typeid(s).name(); bool done = false; int thisOrd = -1; int argOrd = -1; for (int i=0; !done; i++) { const char* tableEntry = typeOrderTable[i]; if (tableEntry != 0) { if (strcmp(tableEntry, thisType) == 0) thisOrd = i; if (strcmp(tableEntry, argType) == 0) argOrd = i; if ((argOrd > 0) && (thisOrd > 0)) done = true; } else // table entry == 0 done = true; } return thisOrd < argOrd; } 

एकमात्र तत्व जो ड्राइंग आकृतियों के क्रम को बदलने से बंद नहीं है, वह एक तालिका है। तालिका को अन्य सभी मॉड्यूल से अलग करके एक अलग मॉड्यूल में रखा जा सकता है, और इसलिए इसके परिवर्तन अन्य मॉड्यूल को प्रभावित नहीं करेंगे।

आगे बंद

यह कहानी का अंत नहीं है। हमने Shape वर्ग के आधार पर आर्डर नीति को बदलने से Shape वर्ग और DrawAllShapes फ़ंक्शन के पदानुक्रम को बंद कर दिया। हालांकि, Shape वर्ग के वंशज उन नीतियों को आदेश देने से बंद नहीं होते हैं जो Shape प्रकारों से संबद्ध नहीं हैं। ऐसा लगता है कि हमें उच्च-स्तरीय संरचना के अनुसार आकृतियों के आरेखण की व्यवस्था करने की आवश्यकता है। ऐसी समस्याओं का एक पूरा अध्ययन इस लेख के दायरे से परे है; हालाँकि, एक रुचि रखने वाला पाठक सोच सकता है कि OrderedObject क्लास में निहित अमूर्त OrderedObject क्लास का उपयोग करके इस समस्या को कैसे हल किया OrderedShape , जो कि Shape और OrderedObject से विरासत में मिला है।

हेयूरिस्टिक्स और कन्वेंशन

जैसा कि लेख की शुरुआत में उल्लेख किया गया है, खुलेपन-घनिष्ठता का सिद्धांत कई अनुमानों और सम्मेलनों के पीछे की प्रमुख प्रेरणा है जो ओओपी प्रतिमान के विकास के वर्षों में उभरे हैं। निम्नलिखित सबसे महत्वपूर्ण हैं।

सभी सदस्य चर को निजी बनाएं

यह पीएलओ के सबसे स्थायी सम्मेलनों में से एक है। सदस्य चर को केवल उस कक्षा के तरीकों के लिए जाना जाना चाहिए जिसमें वे परिभाषित हैं। परिवर्तनीय सदस्यों को व्युत्पन्न वर्गों सहित किसी भी अन्य वर्गों के लिए नहीं जाना चाहिए। इसलिए, उन्हें private एक्सेस संशोधक के साथ घोषित किया जाना चाहिए, public या protected ।
खुलेपन-घनिष्ठता के सिद्धांत के प्रकाश में, इस तरह के सम्मेलन का कारण समझ में आता है। जब कक्षा सदस्य चर बदलते हैं, तो प्रत्येक फ़ंक्शन जो उन पर निर्भर करता है को बदलना होगा। यही है, फ़ंक्शन इन चरों में परिवर्तन से बंद नहीं है।

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

लेकिन अगर आपके पास एक चर है जिसके बारे में आप सुनिश्चित हैं कि यह कभी नहीं बदलेगा? क्या इसे private बनाने का कोई मतलब है? उदाहरण के लिए, सूचीबद्ध 7 Device वर्ग को दिखाता है जिसमें चर सदस्य bool status । यह अंतिम ऑपरेशन की स्थिति को संग्रहीत करता है। यदि ऑपरेशन सफल रहा, तो status चर का मूल्य true होगा, अन्यथा false ।

 // 7 //   class Device { public: bool status; }; 

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

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

दूसरी ओर, मान लीजिए कि हमारे पास Time क्लास है, जो लिस्टिंग 8 में दिखाया गया है। इस वर्ग के सदस्यों के प्रचार का खतरा क्या है? यह बहुत संभावना नहीं है कि वे बदल जाएंगे। इसके अलावा, इससे कोई फर्क नहीं पड़ता कि क्लाइंट मॉड्यूल इन चरों के मूल्यों को बदलते हैं या नहीं, क्योंकि इन चरों में परिवर्तन माना जाता है। यह भी बहुत संभावना नहीं है कि विरासत में मिली कक्षाएं किसी विशेष सदस्य चर के मूल्य पर निर्भर कर सकती हैं। तो क्या कोई समस्या है?

 // 8 class Time { public: int hours, minutes, seconds; Time& operator-=(int seconds); Time& operator+=(int seconds); bool operator< (const Time&); bool operator> (const Time&); bool operator==(const Time&); bool operator!=(const Time&); }; 

सूची 8 में मैं केवल एक ही शिकायत कर सकता हूं कि समय परिवर्तन परमाणु नहीं है। यही है, क्लाइंट hours चर के मूल्य को बदले बिना minutes चर के मूल्य को बदल सकता है। यह असंगत डेटा को सम्‍मिलित करने के लिए Time क्लास की एक वस्तु का कारण बन सकता है। मैं समय निर्धारित करने के लिए एक ही फ़ंक्शन शुरू करना पसंद करूंगा, जिसमें तीन तर्क होंगे, जो समय को एक परमाणु संचालन स्थापित करेगा। लेकिन यह एक कमजोर तर्क है।

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

इसलिए, ऐसे दुर्लभ मामलों में, जब खुलेपन-बंद होने के सिद्धांत का उल्लंघन नहीं किया जाता है, तो public का निषेध - और protected चर शैली पर अधिक निर्भर करता है और सामग्री पर नहीं।

कोई वैश्विक चर ... बिल्कुल नहीं!

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

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

RTTI खतरनाक है

एक अन्य सामान्य निषेध dynamic_cast का उपयोग है। बहुत बार, dynamic_cast या कुछ अन्य प्रकार के रनटाइम प्रकार निर्धारण (आरटीटीआई) पर एक अत्यंत खतरनाक तकनीक होने का आरोप लगाया जाता है और इसलिए इसे टाला जाना चाहिए। उसी समय, वे अक्सर लिस्टिंग 9 से एक उदाहरण देते हैं, जो स्पष्ट रूप से खुलेपन-निकटता के सिद्धांत का उल्लंघन करता है। हालाँकि, सूची 10 एक समान कार्यक्रम का एक उदाहरण दिखाता है जो खुले-बंद सिद्धांत का उल्लंघन किए बिना dynamic_cast उपयोग करता है।

उनके बीच का अंतर यह है कि पहले मामले में, लिस्ट 9 में दिखाया गया है, हर बार कोड को बदलने की आवश्यकता होती है, Shape वर्ग का एक नया वंश प्रकट होता है (यह उल्लेख नहीं है कि यह एक बिल्कुल हास्यास्पद समाधान है)। हालाँकि, लिस्टिंग 10 में, इस मामले में किसी भी बदलाव की आवश्यकता नहीं है। इसलिए, सूची 10 में कोड खुले-बंद सिद्धांत का उल्लंघन नहीं करता है।
इस मामले में, अंगूठे का नियम यह है कि आरटीटीआई का उपयोग किया जा सकता है अगर खुलेपन-बंद करने के सिद्धांत का उल्लंघन नहीं किया जाता है।

 // 9 //RTTI,   -. class Shape {}; class Square : public Shape { private: Point itsTopLeft; double itsSide; friend DrawSquare(Square*); }; class Circle : public Shape { private: Point itsCenter; double itsRadius; friend DrawCircle(Circle*); }; void DrawAllShapes(Set<Shape*>& ss) { for (Iterator<Shape*>i(ss); i; i++) { Circle* c = dynamic_cast<Circle*>(*i); Square* s = dynamic_cast<Square*>(*i); if (c) DrawCircle(c); else if (s) DrawSquare(s); } } 

 // 10 //RTTI,    -. class Shape { public: virtual void Draw() cont = 0; }; class Square : public Shape { // . }; void DrawSquaresOnly(Set<Shape*>& ss) { for (Iterator<Shape*>i(ss); i; i++) { Square* s = dynamic_cast<Square*>(*i); if (s) s->Draw(); } } 

निष्कर्ष

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

, - -. , , , , , .