OOP, "पवित्र ट्रिनिटी" और SOLID: उनके बारे में कुछ न्यूनतम ज्ञान

आवश्यक प्रविष्टि

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

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

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

यहाँ उन्हें मुझ पर आपत्ति हो सकती है कि स्कूल में इन चीजों को सीखना बहुत जल्दी है, और सामान्य तौर पर ओओपी में प्रकाश एक साथ नहीं आया है। सबसे पहले, यह इस बात पर निर्भर करता है कि आप कैसे सीखते हैं। दूसरे, इस लेख में 70% सामग्री न केवल ओओपी पर लागू होती है। मैं अलग से क्या नोट करूंगा।

संक्षेप में OOP

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

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

यहाँ भी हम ध्यान दें कि कमांड के अनुक्रम को सबप्रोग्राम में जोड़ा जाना चाहिए और प्रत्येक सबप्रोग्राम को एक कमांड का उपयोग करके निष्पादित किया जा सकता है।

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

शुरुआत से ही, आदिम डेटा प्रकारों के एक अधिक या कम सामान्य सेट का गठन किया गया था। पूर्णांक, वास्तविक संख्या, बूलियन चर, सरणियाँ, तार। एल्गोरिथ्म + डेटा संरचनाएं = प्रोग्राम, जैसा कि निकलस विर्थ को माना गया है।

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

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

type Name: record consisting of FirstName: String, MiddleName: String, LastName: String. type Point: record consisting of X: Double, Y: Double. 

अर्थात्, दो या तीन संबंधित चर के साथ खींचने के बजाय, आप उन्हें नामित फ़ील्ड के साथ एक संरचना में समूहित करते हैं। फिर आप प्रकार नाम का एक चर घोषित करते हैं और उदाहरण के लिए, FirstName फ़ील्ड देखें।

हमारे विषय के लिए इस "परिवर्धित" चर में इतना मूल्यवान क्या है? कि यहाँ से OOP के लिए केवल एक छोटा कदम है। मैंने यह इंगित करने के लिए केवल एक बोल्ड पैराग्राफ को उजागर नहीं किया है कि कोड के टुकड़े भी चर में रखे जा सकते हैं। देखें कि चर वस्तुओं में कैसे बदलते हैं:

 type Name: class consisting of FirstName: String, MiddleName: String, LastName: String, GetFullName: subprogram with no parameters returns String. type Point: class consisting of X: Double, Y: Double, ScalarMultiply: subprogram with (Double) parameters returns Point. 

एनबी एनईपीएल सक्रिय रूप से विकसित हो रहा है और पहले से ही रिकॉर्ड कीवर्ड को कक्षा के साथ बदल दिया है।

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

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

वास्तव में, सब कुछ इतना आसान नहीं निकला। और कुछ "मजबूत" विचारों के बिना, ओओपी एक प्रोग्रामर के जीवन को नरक में बदल देगा। लेकिन आगे बढ़ने से पहले, कुछ और शब्द दें:

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

पवित्र त्रिमूर्ति

ऐसा ऐतिहासिक रूप से हुआ कि वे इन बातों के बारे में साक्षात्कार में पूछते हैं। वे किसी भी OOP भाषा की पाठ्यपुस्तक के बारे में लिखे गए हैं। क्यों? क्योंकि यदि आप बिना किसी संबंध के लिए किसी ओओपी कार्यक्रम को डिजाइन करते हैं, तो आप "ताबूत, ताबूत, कब्रिस्तान, बेहिसाब।" वंशानुक्रम इतनी सख्ती से आवश्यक नहीं है, लेकिन यह अवधारणा आपको ओओपी को बेहतर ढंग से समझने की अनुमति देती है और ओओपी का उपयोग करके डिजाइन करने में एक मुख्य उपकरण है।

कैप्सूलीकरण

ठीक है, चलो विकिपीडिया से परिभाषा के साथ शुरू करते हैं: "डेटा और फ़ंक्शंस को एक एकल घटक में पैक करना।" परिभाषा स्पष्ट लगती है, लेकिन साथ ही साथ सामान्यीकृत भी। इसलिए, आइए इस बारे में बात करें कि यह क्यों आवश्यक है, यह हमें क्या देगा, और वास्तव में डेटा और फ़ंक्शन को एक घटक में कैसे पैक किया जाए।

मैंने पहले ही एक लेख लिखा था जो एनकैप्सुलेशन से निपटा। और वहां मुझे इस तथ्य के साथ सही रूप से फटकार लगाई गई कि मैंने जानकारी को छिपाने के लिए एनकैप्सुलेशन को कम कर दिया है, और ये कुछ अलग चीजें हैं। विशेष रूप से, EngineerSpock ने इस तरह के एक सुरुचिपूर्ण सूत्रीकरण का निर्माण किया, जो कि अपरिवर्तनीय संरक्षण था । मैं अपनी गलती मानता हूं, और फिर मैं समझाऊंगा कि मैंने इसे क्यों बनाया।

इस बीच, मेरा, एन्कैप्सुलेशन के सिद्धांत की एक प्रारंभिक परिभाषा, या, यदि आप चाहते हैं, तो एनकैप्सुलेशन की प्रक्रिया, जो न केवल एनकैप्सुलेशन के सिद्धांत का वर्णन करती है, बल्कि इसके साथ क्या हासिल करना है:

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

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

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

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

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

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

बस इस बारे में सोचें कि आपकी ऑब्जेक्ट के उपयोगकर्ता को कौन से बटन दबाने हैं, और उन्हें आंतरिक गिब्लेट से अलग करना है। और किसी भी मामले में अतिरिक्त बटन न जोड़ें! वह पहले था।

दूसरे, इंटरफ़ेस और कार्यान्वयन के बीच की सीमा का सम्मान करें और दूसरों को इसका सम्मान करें। सिद्धांत रूप में, यह विचार सहज है और कई रूपों में लोक ज्ञान के बीच मंडराता है। कम से कम "अगर आपने किसी अनहोनी का फायदा उठाया, और फिर आपके लिए कुछ टूट गया, तो आपको दोष देना होगा।" मुझे लगता है, "जब तक आप अपनी ज़रूरत के अनुसार काम नहीं करते तब तक माइक्रोवेव को स्पिन न करें," सब कुछ स्पष्ट है। अब दूसरों को कुख्यात सीमा का सम्मान करने के तरीके के बारे में।

यह वह जगह है जहाँ जानकारी का बहुत बचाव के लिए आता है। हां, आप कोड सम्मेलनों को हमेशा सहमत कर सकते हैं, पूछ सकते हैं, एक कोड समीक्षा को इंगित कर सकते हैं कि यह संभव नहीं है। लेकिन इस सीमा से आगे चढ़ने की बहुत संभावना बनी रहेगी। यह बचाव के लिए आने वाली जानकारी का बहुत ही छिपाव है।

यदि हमारा कोड इसके अस्तित्व के बारे में नहीं सीख सकता है और इसके पीछे क्या है, तो हम कुख्यात सीमा पार नहीं कर सकते। और यहां तक ​​कि अगर वह पता लगाता है, तो संकलक यह दिखाएगा कि ऐसा कोई क्षेत्र या विधि नहीं है, और यहां तक ​​कि अगर वहाँ है, तो इसे छूने के लिए आवश्यक नहीं है, मैं संकलन करने से इनकार करता हूं, और आम तौर पर आप कौन हैं, हमने आपको नहीं बुलाया, इंटरफ़ेस भाग का उपयोग करें।

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

यदि आपका पसंदीदा YP आपको जानकारी छिपाने की अनुमति नहीं देता है तो क्या होगा? इस विषय पर आप टिप्पणियों के बारे में बात करके मज़े ले सकते हैं। मुझे अगला रास्ता दिख रहा है। वृद्धि पर:

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

एक बार और:

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

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

 type Microwave: class consisting of private fancyInnerChips: List of Chip, private foodWarmingThing: FoodWarmerController, private buttonsPanel: ButtonsPanel, public GetAccessToControlPanel: subprogram with no parameters returns ButtonsPanel, public OpenDoor: subprogram with no parameters returns nothing, public Put: subprogram with (Food) parameters return nothing, public CloseDoor: subprogram with no parameters returns nothing. type ButtonsPanel: class consisting of private buttons: List of ButtonState, public PressOn: subprogram with no parameters returns nothing, public PressOff: subprogram with no parameters returns nothing, public PressIncreaseTime: subprogram with no parameters returns nothing, public PressDecreaseTime: subprogram with no parameters returns nothing, public PressStart: subprogram with no parameters returns nothing, public PressStop: subprogram with no parameters returns nothing. 

मुझे उम्मीद है कि यह कोड से स्पष्ट है कि उदाहरण का सार क्या है। मैं केवल एक ही बिंदु स्पष्ट करूंगा: GetAccessToControlPanel यह जाँच करता है कि क्या हम माइक्रोवेव को छू भी सकते हैं। अगर वह टूट गया है तो क्या होगा? तब आप कुछ भी क्लिक नहीं कर सकते आप केवल एक त्रुटि संदेश प्राप्त कर सकते हैं।

खैर, तथ्य यह है कि बटनपैनसेल एक अलग वर्ग बन गया है जो हमें सुचारू रूप से एक महत्वपूर्ण सवाल पर लाता है: विकिपीडिया पर एनकैप्सुलेशन की परिभाषा से "एकल घटक" क्या है? वर्गों के बीच की सीमाएँ कहाँ और कैसे होनी चाहिए? हम थोड़ी देर बाद निश्चित रूप से इस मुद्दे पर लौटेंगे।

OOP के बाहर का उपयोग करें

इतने सारे प्रोग्रामर ने जावा / C ++ / C # ट्यूटोरियल से एनकैप्सुलेशन के बारे में सीखा है। इसलिए, ओओपी के साथ किसी तरह जुड़े हुए जन चेतना में एनकैप्सुलेशन। लेकिन एनकैप्सुलेशन की दो परिभाषाओं पर वापस जाएं।

एकल घटक में डेटा और फ़ंक्शंस पैक करना।

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

क्या आपने गौर किया है? कक्षाओं और वस्तुओं के बारे में कुछ भी नहीं है!

तो एक उदाहरण है। आप एक डीबीए हैं । आपका काम किसी तरह के रिलेशनल डेटाबेस पर नज़र रखना है। उदाहरण के लिए, MySQL पर इसे रहने दें। आपका कीमती डेटाबेस कई कार्यक्रमों का उपयोग करता है। आपका उनमें से कुछ पर नियंत्रण नहीं है। क्या करें?

संग्रहीत प्रक्रियाओं का एक सेट बनाएं। हम उन्हें एक सर्किट में लिखते हैं, जिसे हम इंटरफ़ेस कहेंगे। हम किसी भी अधिकार के बिना अपने कार्यक्रमों के लिए एक उपयोगकर्ता बनाते हैं। यह CREATE USER कमांड है। फिर, GRANT कमांड का उपयोग करके, यूजर को इन स्कीमों को इंटरफ़ेस स्कीमा से निष्पादित करने का अधिकार देता है।

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

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

यही कारण है कि वर्ग और ऑब्जेक्ट एनकैप्सुलेशन की परिभाषा में प्रकट नहीं होते हैं। यह विचार ओओपी की तुलना में बहुत व्यापक है। और यह केवल OOP भाषाओं पर पाठ्यपुस्तकों में इसे बोलने के लिए बहुत अधिक लाभ लाता है।

बहुरूपता

बहुरूपता के कई रूप और परिभाषाएं हैं। यह पर्याप्त है कि जब मैं विकिपीडिया खोलता हूं, तो कोंड्रैटियस मुझे पीड़ित करता है। यहां मैं बहुरूपता के बारे में बात करूंगा, जैसा कि स्ट्रेंज़प ने इसे तैयार किया था: एक इंटरफ़ेस - कई कार्यान्वयन ।

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

NEPL तेजी से विकसित हो रहा है और, C # के प्रभाव में, प्राप्त करता है (ध्यान से, शब्दांकन पर ठोकर न खाएं) डेटा प्रकार का इंटरफ़ेस।

 type FoodWarmer: interface consisting of GetAccessToControlPanel: no parameters returns FoodWarmerControlPanel, OpenDoor: no parameters returns nothing, Put: have (Food) parameters returns nothing, CloseDoor: no parameters returns nothing. type FoodWarmerControlPanel: interface consisting of PressOn: no parameters returns nothing, PressOff: no parameters returns nothing, PressIncreaseTime: no parameters returns nothing, PressDecreaseTime: no parameters returns nothing, PressStart: no parameters returns nothing, PressStop: no parameters returns nothing. type EnemyFinder: interface consisting of FindEnemies: no parameters returns List of Enemy. type Radar: class implementing FoodWarmer, EnemyFinder and consisting of private secretMilitaryChips: List of Chip, private giantMicrowavesGenerator: FoodWarmerController, private strangeControlPanel: AlarmClock, public GetAccessToControlPanel: subprogram with no parameters returns FoodWarmerControlPanel, public OpenDoor: subprogram with no parameters returns nothing, public Put: subprogram with (Food) parameters return nothing, public CloseDoor: subprogram with no parameters returns nothing, public FindEnemies: subprogram with no parameters returns List of Enemy. type AlarmClock: class implementing FoodWarmerControlPanel and consisting of private mechanics: List of MechanicPart, public PressOn: subprogram with no parameters returns nothing, public PressOff: subprogram with no parameters returns nothing, public PressIncreaseTime: subprogram with no parameters returns nothing, public PressDecreaseTime: subprogram with no parameters returns nothing, public PressStart: subprogram with no parameters returns nothing, public PressStop: subprogram with no parameters returns nothing. type Microwave: class implementing FoodWarmer and consisting of private fancyInnerChips: List of Chip, private foodWarmingThing: FoodWarmerController, private buttonsPanel: ButtonsPanel, public GetAccessToControlPanel: subprogram with no parameters returns FoodWarmerControlPanel, public OpenDoor: subprogram with no parameters returns nothing, public Put: subprogram with (Food) parameters return nothing, public CloseDoor: subprogram with no parameters returns nothing. type ButtonsPanel: class implementing FoodWarmerControlPanel and consisting of private buttons: List of ButtonState, public PressOn: subprogram with no parameters returns nothing, public PressOff: subprogram with no parameters returns nothing, public PressIncreaseTime: subprogram with no parameters returns nothing, public PressDecreaseTime: subprogram with no parameters returns nothing, public PressStart: subprogram with no parameters returns nothing, public PressStop: subprogram with no parameters returns nothing. 

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

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

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

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

माइक्रोवेव और रडार क्लास में बंद खेतों को भी देखें। वहां हमारे पास अलार्म घड़ी और बटन के साथ एक पैनल है। लेकिन बाहर हम FoodWarmerControlPanel प्रकार का एक चर देते हैं।

पिकाबू पर कहीं एक कहानी थी कि कैसे एक निश्चित उम्मीदवार ने बहुरूपता के सिद्धांत को इस प्रकार समझाया:

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

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

OOP के बाहर का उपयोग करें

एर्लांग के रूप में इन शब्दों की सभी इंद्रियों में एक ऐसी अजीब और मजाकिया भाषा है। और इसमें व्यवहार जैसी विशेषता है। अपने हाथ देखो:

कोड को मॉड्यूल में विभाजित किया गया है। आप एक चर के रूप में मॉड्यूल नाम का उपयोग कर सकते हैं। यही है, आप इस तरह से एक मॉड्यूल से एक फ़ंक्शन कॉल लिख सकते हैं:

 %option 1 foobar:function(), %option 2 Module = foobar, Module:function(). 

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

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

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

Erlang — , .

« — » , , .

. .NET. . CLR . CLR Microsoft , , , ( ECMA-335).

.NET , Windows, Windows Phone, XBox ( XNA, , ), . Microsoft. , , . , Mono Project. .NET. .

, . Microsoft , .NET . . , , .NET Core. , .NET Core .NET Framework, , , . , .

, « — » - . , .

, . , , , . , .

, , . , , NEPL. . Name? , . EtiquetteInfo - .

 import class EtiquetteInfo from Diplomacy. type PoliteName: class consisting of private FirstName: String, private MiddleName: String, private LastName: String, for descendants GetPoliteFirstName: subprogram with (EtiquetteInfo) parameters returns String, for descendants GetPoliteMiddleName: subprogram with (EtiquetteInfo) parameters returns String, for descendants GetPoliteLastName: subprogram with (EtiquetteInfo) parameters returns String, public GetFullName: subprogram with (EtiquetteInfo) parameters returns String. subprogram GetPoliteFirstName.PoliteName with (EtiquetteInfo _EtiquetteInfo) parameters returning String implemented as return _EtiquetteInfo.PoliteFirstName(FirstName). subprogram GetPoliteMiddleName.PoliteName with (EtiquetteInfo _EtiquetteInfo) parameters returning String implemented as return _EtiquetteInfo.PoliteMiddleName(MiddleName). subprogram GetPoliteLastName with (EtiquetteInfo _EtiquetteInfo) parameters returning String implemented as return _EtiquetteInfo.PoliteLastName(LastName). subprogram GetFullName with (EtiquetteInfo _EtiquetteInfo) parameters returning String implemented as return GetPoliteFirstName(_EtiquetteInfo) + GetPoliteMiddleName(_EtiquetteInfo) + GetPoliteLastName(_EtiquetteInfo). 

, GetFullName - , ( , , ?). , , - . , , . , , , , . , . PoliteName . ExoticPoliteName — . , , .

- . ExoticPoliteName, PoliteName, . PoliteExoticName. , PoliteName.

 import class EtiquetteInfo from Diplomacy. type PoliteExoticName: class extending PoliteName and consisting of private MoreMiddleNames: List of String, for descendants overridden GetPoliteMiddleName: subprogram with (EtiquetteInfo) parameters returns String, public overriden GetFullName: subprogram with (EtiquetteInfo) parameters returns String. subprogram GetPoliteMiddleName.PoliteExoticName with (EtiquetteInfo _EtiquetteInfo) parameters returning String implemented as String AggregatedMiddleName = String.Join(" ", MoreMiddleNames), return base.GetPoliteMiddleName(_EtiquetteInfo + AggregatedMiddleName). subprogram GetFullName with (EtiquetteInfo _EtiquetteInfo) parameters returning String implemented as String Prefix = "", String FirstName = GetFirstName(_EtiquetteInfo), if _EtiquetteInfo.ComplimentIsAppropriate(FirstName) then Prefix = "Oh, joy of my heart, dear ", return Prefix + base.GetFullName(_EtiquetteInfo). 

: PoliteName . PoliteExoticName -.

, , . , GetPoliteFirstName GetPoliteLastName. . GetFullName, , .

, , PoliteName, PoliteExoticName, GetFullName. , PoliteName, , . , , base.GetFullName(etiquetteInfo). , , .

, " ". , . : , . . .

, . . , Boolean, , . , Object. . , , , , Object, .

, NEPL . PoliteName Object, PoliteExoticName PoliteName Object . , NEPL :

 subprogram Foo.Bar with no parameters returning nothing implemented as PoliteExoticName _PoliteExoticName = GetSomePoliteExoticName(), PoliteName _PoliteName = _PoliteExoticName, Object _Object = _PoliteExoticName. 

, , _Object.GetFullName, , . PoliteName PoliteExoticName - Object, - _Object, .

? , . . , ( Object) , - -.

, , , , . ? , . - , . . - , .

? , . . . , «» , . ?

. , NEPL for descendants.

 type PoliteName: class consisting of private FirstName: String, private MiddleName: String, private LastName: String, for descendants GetPoliteFirstName: subprogram with (EtiquetteInfo) parameters returns String, for descendants GetPoliteMiddleName: subprogram with (EtiquetteInfo) parameters returns String, for descendants GetPoliteLastName: subprogram with (EtiquetteInfo) parameters returns String, public GetFullName: subprogram with (EtiquetteInfo) parameters returns String. 

PoliteExoticName FirstName, «, , , , ». GetPoliteFirstName FirstName.

, , Square Shape, Shape Square . , . Shape , , . Square, Shape. क्यों? , Shape, .

. , ? -, . -, , , , . , , .

, . , . « »? , . . , .

. , . , , . . , . , , .

, , . . ( , ), , . , , . , , . .

, ) , ) , , , 999 1000 . , , .

()

, . - , . , , . - , .

SOLID

— , , . - . SOLID — , , … ? ? , , .

S — The Single Responsibility Principle

. .

.

. . .

, « » - . . « ?». , , ? .

, SRP :

.

, ? — , . ? . « ». , . ? .

, ? . , .txt-. , , , .txt-. - , . , , … .txt-. क्यों? . , , .txt-.

NB ( , ) «», « , ».

. , , , .txt-. . , . , . लेकिन! -, , , . -, , , .

, , . , ) , ) .html-. , , .txt/.html.

, , , . , , .txt-. क्या गलत हो सकता है?

• . , . , , . , , , , , , . .
• , . 900 USD 900.00$? 20190826T130000 2019 ? , ?
• .txt-? .csv? , .txt. ? ? - ? - ? , ?

? — . , -.

, , , . , .

DRY — Don't Repeat Yourself

:

, . .

, , , - , . , , .

SRP . , , . , « ». , , , — .

. HTML . , «» . , HTML 90- . , . - , . , HTML- . CSS .

? -, CSS , «» . , . -, CSS- html- , - text-color . — . .

O — The Open/Closed Principle

, , , - . , «» «». / , , . « » . :

.

. , . , . , — .

, . . ? . , .

• , . , . , / .
• , . , . / /, . NB /. , : .
• , . , .
• , - , , . (), () «» .
• . , , ? , . , . , .

, . .

 type SpellChecker: class consisting of public DoSpellCheck: subprogram with (String) parameters returns String. type CorporativeStyleChecker: class consisting of public DoCorporativeStyleCheck: subprogram with (String) parameters returns String. type TextProcessor: class consisting of private Text: String, private SpellChecker: SpellChecker, private CorporativeStyleChecker: CorporativeStyleChecker, public Process: subprogram with no parameters returns String. subprogram TextProcessor.Process with no parameters returning String implemented as String ProcessedText = Text, ProcessedText = SpellChecker.DoSpellCheck(ProcessedText), ProcessedText = CorporativeStyleChecker.DoCorporativeStyleCheck(ProcessedText), return ProcessedText. 

,

 type TextChecker: interface consisting of Check: have (String) parameters returns String. type SpellChecker: class implementing TextChecker and consisting of public Check: subprogram with (String) parameters returns String. type CorporativeStyleChecker: class implementing TextChecker and consisting of public Check: subprogram with (String) parameters returns String. type TextProcessor: class consisting of private Text: String, private SpellChecker: SpellChecker, private CorporativeStyleChecker: CorporativeStyleChecker, public Process: subprogram with no parameters returns String. subprogram TextProcessor.Process with no parameters returning String implemented as String ProcessedText = Text, List of SpellChecker Checkers = (SpellChecker, CorporativeStyleChecker), for each SpellChecker SpellChecker in Checkers do ProcessedText = SpellChecker.Check(ProcessedText) and nothing else, return ProcessedText. 

O/CP . TextCheckersSupplier, .

 type TextChecker: interface consisting of Check: have (String) parameters returns String. type SpellChecker: class implementing TextChecker and consisting of public Check: subprogram with (String) parameters returns String. type CorporativeStyleChecker: class implementing TextChecker and consisting of public Check: subprogram with (String) parameters returns String. type TextCheckersSupplier: class consisting of public GetCheckers: subprogram with no parameters returns List of TextChecker. type TextProcessor: class consisting of private Text: String, private CheckersSupplier: TextCheckersSupplier, public Process: subprogram with no parameters returns String. subprogram TextProcessor.Process with no parameters returning String implemented as String ProcessedText = Text, List of SpellChecker Checkers = CheckersSupplier.GetCheckers(), for each SpellChecker SpellChecker in Checkers do ProcessedText = SpellChecker.Check(ProcessedText) and nothing else, return ProcessedText. 

? , , , . , TextProcessor. , TextCheckerSupplier , , . TextChecker' . , , , . , .

, , , , . .

L — The Liskov Substitute Principle

, :

, , , .

, , . ?

- NEPL:

 type PoliteExoticName: class extending PoliteName and consisting of... subprogram Foo.Bar with no parameters returning nothing implemented as PoliteExoticName _PoliteExoticName = GetSomePoliteExoticName(), PoliteName _PoliteName = _PoliteExoticName, Object _Object = _PoliteExoticName. 

, _PoliteName - . , , . , . PoliteName, . , , , PoliteName . , , , . .

, -, allex ( , ). , , :

-, .

, «Agile Principles, Patterns and Practices in C#». NEPL, .

  Object _Object = GetObjectSomewhere(), PoliteExoticName IHopeItsActuallyName = _Object as PoliteExoticName, 

, , . . , . - , . , . . ( , alias , ):

 from UnboundedCollections import UnboundedSet as ThirdPartyUnboundedSet. from BoundedCollections import BoundedSet as ThirdPartBoundedSet. type Set: interface consisting of Add: have (Object) parameters returns nothing, Delete: have (Object) parameters returns nothing, IsMember: have (Object) parameters returns Boolean. type UnboundedSet: class implementing Set and consisting of private ThirdPartySet: ThirdPartyUnboundedSet, public Add: subprogram with (Object) parameters returning nothing, public Delete: subprogram with (Object) parameters returning nothing, public IsMember: subprogram with (Object) parameters returning Boolean. type BoundedSet: class implementing Set and consisting of private ThirdPartySet: ThirdPartyBoundedSet, public Add: subprogram with (Object) parameters returning nothing, public Delete: subprogram with (Object) parameters returning nothing, public IsMember: subprogram with (Object) parameters returning Boolean. subprogram BoundedSet.Add with (Object O) parameters returning nothing implemented as ThirdPartSet.Add(O). 

. . . PersistentSet, - . , PersistentObject. - . Delete IsMember . Add...

 from PersistentCollections import PersistentSet as ThirdPartyPersistentSet, PersistentObject. type PersistentSet: class implementing Set and consisting of private ThirdPartySet: ThirdPartyPersistentSet, public Add: subprogram with (Object) parameters returning nothing, public Delete: subprogram with (Object) parameters returning nothing, public IsMember: subprogram with (Object) parameters returning Boolean. subprogram PersistentSet.Add with (Object O) parameters returning nothing implemented as PersistentObject Po = O as PersistentObject, ThirdPartySet.Add(Po). 

. PersistentSet Object, . , , Set , . ( ):

 type MemberContainer: interface consisting of Delete: have (Object) parameters returns nothing, IsMember: have (Object) parameters returns Boolean. type Set: interface extending MemberContainer and consisting of Add: have (Object) parameters returns nothing. type PersistentSet: interface extending MemberContainer and consisting of Add: have (PersistingObject) parameters returns nothing. 

C#.

 type List: class generalized with (T) parameters consisting of 

 from UnboundedCollections import UnboundedSet as ThirdPartyUnboundedSet. from BoundedCollections import BoundedSet as ThirdPartBoundedSet. from PersistentCollections import PersistentSet as ThirdPartyPersistentSet, PersistentObject. type Set: interface generalized with (T) parameters consisting of Add: have (T) parameters returns nothing, Delete: have (T) parameters returns nothing, IsMember: have (T) parameters returns Boolean. type UnboundedSet: class implementing Set of Object and consisting of private ThirdPartySet: ThirdPartyUnboundedSet, public Add: subprogram with (Object) parameters returning nothing, public Delete: subprogram with (Object) parameters returning nothing, public IsMember: subprogram with (Object) parameters returning Boolean. type BoundedSet: class implementing Set of Object and consisting of private ThirdPartySet: ThirdPartyBoundedSet, public Add: subprogram with (Object) parameters returning nothing, public Delete: subprogram with (Object) parameters returning nothing, public IsMember: subprogram with (Object) parameters returning Boolean. type PersistentSet: class implementing Set of PersistentObject and consisting of private ThirdPartySet: ThirdPartyPersistentSet, public Add: subprogram with (PersistentObject) parameters returning nothing, public Delete: subprogram with (PersistentObject) parameters returning nothing, public IsMember: subprogram with (PersistentObject) parameters returning Boolean. 

()

. , , «» . , « — » . , . .

I — The Interface Segregation Principle

, . . .

, ? , - . , , SQL? , . , API . API , «interface», , . . क्या गलत हो सकता है?

, , - , DBA . , 100500 , . . , .

, , , «» . , « interface, ». DBA . GDPR, HIPAA , .

- . , . और इसी तरह।

? , . :

, ( ).

? interface «interface_billing», «interface_customer_data» . .

, , . pet-project. IActor. , . , IActor : ICollidable, IDisplayble, IUpdatable. ?

( , Camera), . , - . , . , , IDisplayble SpecEffect.

CollisionsController , - ICollidable. , , , SOLID . TileWall -, . CollisionsController . , , IActor , .

: , , .

D — The Dependency Inversion

-. , . , , . , , . , , , , - . , , - . , , - .

"यही है! .» — - ImportantClass. , , . , ImportantClass VeryImportantClass, , , EvenMoreImportantClass, , . , , , . , . , .

ImportantClass VeryImportantClass EvenMoreImportantClass. ImportantClass . , , . , IVeryImportantClass IEvenMoreImportantClass, ImportantClass.

ImportantClass VeryImportantClass . ImportantClass « », IVeryImportantClass .

. , , .

. .

. .

, «» «» - . , , . . , , . , . , -.

. , .

- , . ( MegaSender), . , , SOAP API.

-. SenderAccess. , MegaSender SenderAccess . SenderAccess MegaSender, , MegaSender, MegaSender , Apple i.

MegaSender. LightSender. , SenderAccess c LightSender. , , . , .

SenderAccess, , MegaSender . , SenderAccess MegaSender. MegaSender « ». , MegaSender, , , . . , LightSender , , LightSender, MegaSender.

, SenderAccess , SenderAccess LightSender . .

, IActor ICollidable, IUpdatable, IDisplayble. , IActor . Actor Player, Enemy, Door, Wall . , .

Blueprint. . , , , , , et cetera. , , , .

, , C#, . , - List<String>. , List<T> List<String>. Actor Actor<TBlueprint>.

, , - . Actor<EnemyBlueprint> Actor<DoorBlueprint> , . , .

- . , , . , . , . , IActor, , ActorsFactory .

. : .

, , . - , . () :

. . . TCP/HTTP/SMPP/SOAP, . ? , TCP/HTTP/SMPP/SOAP- TCP/HTTP/SMPP/SOAP- , . , - . ? . , « » « 1000 ».

. ? - SOLID'? , . , - , .

- , .

- , .

. , -, , . . - , , , , -. , .

. - , :

KISS — . . . , , . , , .

, , Actor . , — , - . , .

YAGNI — . - , , « », , - . , . « » - . , , . , , .

, OC/P . 50 . , , -. 50 , . , - .

? , , « », . « » , .

, SOLID . , .

, . , -, , . , .

• «Code Complete» . , « » - .
• «Clean Code» . «Clean Architecture».
• «Agile Principles, Patterns and Practices in C#» . SOLID . , language-agnostic.

पुनश्च

, . , , . : ! , , language-agnostic .

, language-agnostic. NEPL, : , , , . , , .

, . , , . :

, , , . , , . , . : , .