एनकैप्सुलेशन एक ब्लैक बॉक्स है?

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

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

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

इसलिए, ब्लैक बॉक्स के उपयोग को दो श्रेणियों में विभाजित किया जा सकता है:

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

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

पुन: उपयोग कोड के लिए लाइब्रेरी, ब्लैक बॉक्स बनाते समय विचार करने के लिए सिद्धांत:

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

इस अवधारणा को OOSILA कहा जा सकता है।

पुनश्च: यदि विषय दिलचस्प है, तो मैं OOSILA के सिद्धांतों का उपयोग करने के उदाहरण तैयार करूंगा।

UPDATE: हिडन बॉक्स => ब्लैक बॉक्स