c# अमूर्त और encapsulation कैसे भिन्न है?




oop abstraction (12)

मतिहीनता

जावा में, अमूर्त मतलब वास्तविक दुनिया को जानकारी छिपाने का मतलब है। यह पार्टी के बीच अनुबंध स्थापित करता है कि "सेवा का उपयोग करने के लिए हमें क्या करना चाहिए"।

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

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

encapsulation:

Encapsulation अमूर्तता का एक स्तर नीचे है। वही उत्पाद कंपनी एक दूसरे के उत्पादन समूह से जानकारी बचाने की कोशिश करती है। उदाहरण, यदि कोई कंपनी शराब और चॉकलेट का उत्पादन करती है, तो encapsulation जानकारी को बचाने में मदद करता है कि प्रत्येक उत्पाद एक-दूसरे से कैसे बनाया जा रहा है।

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

मैं एक साक्षात्कार की तैयारी कर रहा हूं और मेरी ओओपी अवधारणाओं को ब्रश करने का फैसला किया है। सैकड़ों लेख उपलब्ध हैं, लेकिन ऐसा लगता है कि प्रत्येक अलग-अलग वर्णन करता है। Some कहते हैं

एब्स्ट्रक्शन "सामान्य पैटर्न की पहचान करने की प्रक्रिया है जिसमें व्यवस्थित विविधताएं होती हैं; एक अमूर्तता सामान्य पैटर्न का प्रतिनिधित्व करती है और यह निर्दिष्ट करने के लिए एक साधन प्रदान करती है कि" किस प्रकार का उपयोग करना है "(रिचर्ड गेब्रियल)।

और सार वर्गों के माध्यम से हासिल किया जाता है।

कुछ other कहते हैं

एब्स्ट्रक्शन का मतलब ऑब्जेक्ट के क्लाइंट को केवल आवश्यक विवरण दिखाना है

तथा

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

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

Encapsulation एक रणनीति है जो अमूर्तता के हिस्से के रूप में उपयोग की जाती है। Encapsulation वस्तुओं की स्थिति को संदर्भित करता है - वस्तुओं को अपने राज्य encapsulate और इसे बाहर से छुपा; कक्षा के बाहरी उपयोगकर्ता इसके तरीकों के माध्यम से इसके साथ बातचीत करते हैं, लेकिन सीधे कक्षा राज्य तक नहीं पहुंच सकते हैं। तो वर्ग अपने राज्य से संबंधित कार्यान्वयन विवरण को दूर करता है।

और here एक और प्रतिष्ठित सदस्य कहते हैं,

वे अलग-अलग अवधारणाएं हैं।

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

अब मैं पूरी अवधारणा के साथ गड़बड़ कर रहा हूँ। मैं अमूर्त वर्ग, विरासत, अभिगम विनिर्देशकों और सभी के बारे में जानता हूं। मैं सिर्फ यह जानना चाहता हूं कि जब मुझे साक्षात्कार में अमूर्तता और / या encapsulation के बारे में पूछा जाता है तो मुझे कैसे जवाब देना चाहिए।

कृपया इसे डुप्लिकेट के रूप में चिह्नित न करें । मुझे पता है कि कई समान प्रश्न हैं। लेकिन मैं विरोधाभासी स्पष्टीकरणों के बीच भ्रम से बचना चाहता हूं। क्या कोई एक विश्वसनीय लिंक सुझा सकता है? स्टैक ओवरफ्लो प्रश्न का एक लिंक भी तब तक स्वागत है जब तक यह फिर से भ्रम पैदा नहीं करता है। :)

संपादित करें: मुझे जवाब चाहिए, थोड़ा सी # उन्मुख


Encapsulation : गेटर्स और सेटर्स आदि का उपयोग कर डेटा छिपाना

अमूर्त : अमूर्त वर्गों और इंटरफेस इत्यादि का उपयोग करके कार्यान्वयन छुपाएं।


एब्स्ट्रक्शन का मतलब ऑब्जेक्ट के क्लाइंट को केवल आवश्यक विवरण दिखाना है

असल में यह encapsulation है। encapsulation और डेटा छिपाने से भ्रमित नहीं होने के लिए विकिपीडिया लेख का पहला भाग भी देखें। http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)

ध्यान रखें कि केवल सभी क्लास सदस्यों को छुपाकर गुणों के पीछे 1: 1 बिल्कुल encapsulation नहीं है। encapsulation invariants की रक्षा और कार्यान्वयन विवरण छिपाने के बारे में सब कुछ है।

इसके बारे में यहां एक अच्छा लेख है। http://blog.ploeh.dk/2012/11/27/Encapsulationofproperties/ उस आलेख में जुड़े आलेखों पर भी नज़र डालें।

कक्षाओं, गुणों और अभिगम संशोधक सी # में encapsulation प्रदान करने के लिए उपकरण हैं।

आप जटिलता को कम करने के लिए encapsulation करते हैं।

एब्स्ट्रक्शन "सामान्य पैटर्न की पहचान करने की प्रक्रिया है जिसमें व्यवस्थित विविधताएं होती हैं; एक अमूर्तता सामान्य पैटर्न का प्रतिनिधित्व करती है और यह निर्दिष्ट करने के लिए एक साधन प्रदान करती है कि" किस प्रकार का उपयोग करना है "(रिचर्ड गेब्रियल)।

हां, यह अमूर्तता के लिए एक अच्छी परिभाषा है।

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

हां, वे अलग-अलग अवधारणाएं हैं। ध्यान रखें कि अमूर्त वास्तव में केवल आपके डोमेन के लिए उपयुक्त ऑब्जेक्ट बनाने के विपरीत है। यह सामान्य रूप से डोमेन के लिए उपयुक्त वस्तु बनाने के लिए है!

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

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

इंटरफेस, अमूर्त कक्षाएं या विरासत और बहुरूपता सी # में अमूर्तता प्रदान करने के लिए उपकरण हैं।

पुन: प्रयोज्यता प्रदान करने के लिए आप अमूर्तता करते हैं।


जैसा कि मुझे पता है, encapsulation कक्षाओं के डेटा छुपा रहा है, और केवल इसे सेटर्स / गेटर्स के माध्यम से सुलभ बना रहा है, अगर उन्हें बाहरी दुनिया से एक्सेस किया जाना चाहिए।

एब्स्ट्रक्शन खुद के लिए क्लास डिज़ाइन है।

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

एब्स्ट्रक्शन को ओओ-डिज़ाइन चरण अधिक रखा जाता है, जबकि encapsulation भी development-phase में नामांकन करता है।


मेरा 2 सी

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


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

उदाहरण के लिए, "विंडोज़" लें। वे पारंपरिक अर्थों में वास्तव में खिड़कियां नहीं हैं, वे स्क्रीन पर सिर्फ ग्राफिकल वर्ग हैं। लेकिन विंडोज़ के बारे में सोचना उपयोगी है। यह एक अमूर्त है।

यदि "विंडोज एपीआई" एक विंडो की सीमाओं के भीतर पाठ या ग्राफिक्स को भौतिक रूप से प्रस्तुत करने के विवरण को छुपाता है, तो यह encapsulation है।


अमूर्तता और Encapsulation भ्रमित शब्दों और एक दूसरे पर निर्भर हैं। आइए इसे एक उदाहरण से लें:

public class Person
    {
        private int Id { get; set; }
        private string Name { get; set; }
        private string CustomName()
        {
            return "Name:- " + Name + " and Id is:- " + Id;
        }
    }

जब आपने पर्सन क्लास बनाया, तो आपने संपत्तियों और कार्यों को एक साथ लिखकर encapsulation किया (आईडी, नाम, कस्टम नाम)। जब आप क्लाइंट को क्लाइंट के रूप में उजागर करते हैं तो आप अमूर्त निष्पादन करते हैं

Person p = new Person();
p.CustomName();

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

public class Person
        {
            private int Id { get; set; }
            private string Name { get; set; }
            private string LastName {get; set;}
            public string CustomName()
            {
                return "Name:- " + Name + " and Id is:- " + Id + "last name:- " + LastName;
            }
        }

देखो, कक्षा में अतिरिक्त संपत्ति जोड़ने के बाद भी, आपका ग्राहक नहीं जानता कि आपने अपने कोड के साथ क्या किया है। यह वह जगह है जहां आपने अमूर्त किया था।


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


अमूर्त: बिल्ली के ऊपरी बाएं और शीर्ष दाएं छवियों द्वारा उल्लिखित है। सर्जन और बूढ़े औरत ने जानवर को अलग-अलग डिजाइन किया (या देखा)। इसी तरह, आप आवेदन की आवश्यकता के आधार पर बिल्ली वर्ग में विभिन्न सुविधाएं डाल देंगे। प्रत्येक बिल्ली में यकृत, मूत्राशय, दिल और फेफड़े होते हैं, लेकिन यदि आपको केवल अपनी बिल्ली को 'purr' की आवश्यकता होती है, तो आप अपने आवेदन की बिल्ली को शीर्ष-दाएं की बजाय शीर्ष-बाईं ओर डिज़ाइन पर अमूर्त करेंगे।

Encapsulation: तालिका पर खड़े बिल्ली द्वारा रेखांकित किया गया है। बिल्ली के बाहर हर किसी को बिल्ली को देखना चाहिए । उन्हें चिंता करने की ज़रूरत नहीं है कि क्या बिल्ली का वास्तविक कार्यान्वयन शीर्ष-बाएं एक या शीर्ष दाएं या यहां तक ​​कि दोनों का संयोजन है।

पीएस: पूरी कहानी सुनने के लिए इस सवाल पर here जाएं।


ऑब्जेक्ट ओरिएंटेड विश्लेषण और डिजाइन (ओओएडी) वास्तव में चार सिद्धांतों पर आधारित है। वो हैं:

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

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

  • बहुरूपता: विरासत का एक परिणाम है। माता-पिता से एक विधि का पालन करना उपयोगी है, लेकिन स्थिति की मांग करने पर विधि को संशोधित करने में सक्षम होना, बहुरूपता है। आप उप-वर्ग में एक विधि को मूल वर्ग के समान हस्ताक्षर के साथ कार्यान्वित कर सकते हैं ताकि जब कॉल किया जाए, तो बाल वर्ग की विधि निष्पादित की जाती है। यह बहुरूपता है।

  • Encapsulation: मतलब है कि संबंधित कार्यक्षमता एक साथ बंडल और केवल जरूरी तक पहुंच प्रदान करना। यह सिद्धांत ऑब्जेक्ट ओरिएंटेड डिजाइन में कक्षाओं को डिजाइन करने का आधार है जहां:

    • आप संबंधित डेटा और तरीकों को एक साथ रखते हैं; तथा,
    • डेटा और विधियों के सभी टुकड़े सार्वजनिक नहीं हो सकते हैं।

लोग जो तर्क देते हैं कि "ओओएडी के अमूर्त परिणाम ओओपी के अमूर्त कीवर्ड में परिणाम" ... ठीक है कि यह सही नहीं है

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


मैं एक सरल तरीके से Encapsulation और Abstraction का प्रदर्शन करने की कोशिश करेंगे .. चलो देखते हैं ..

  • एक इकाई (जिसे कक्षा कहा जाता है) में डेटा और कार्यों को लपेटना encapsulation के रूप में जाना जाता है। किसी ऑब्जेक्ट के बारे में जानकारी को शामिल और छुपाएं, जैसे आंतरिक डेटा संरचनाएं और कोड।

Encapsulation है -

  • छुपा जटिलता,
  • एक साथ बाध्यकारी डेटा और समारोह,
  • जटिल विधि के निजी बनाना,
  • इंस्टेंस वैरिएबल के निजी बनाना,
  • अंतिम उपयोगकर्ता से अनावश्यक डेटा और कार्य छुपाएं।

Encapsulation Abstraction लागू करता है।

और सार तत्व है -

  • क्या आवश्यक है दिखा रहा है,
  • डेटा को अंतिम उपयोगकर्ता से सारणी की आवश्यकता है,

आइए एक उदाहरण देखें-

नीचे दी गई छवि "ग्राहक विवरण को डेटाबेस में ADD-ed होने के लिए" का एक जीयूआई दिखाती है।

छवि को देखकर हम कह सकते हैं कि हमें ग्राहक कक्षा की आवश्यकता है।

चरण -1: मेरी ग्राहक कक्षा की क्या ज़रूरत है?

अर्थात

  • ग्राहक कोड और ग्राहक नाम स्टोर करने के लिए 2 चर।

  • डाटाबेस में ग्राहक कोड और ग्राहक नाम जोड़ने के लिए 1 फ़ंक्शन।

  namespace CustomerContent
    {
       public class Customer
       {
           public string CustomerCode = "";
           public string CustomerName = "";
           public void ADD()
           {
              //my DB code will go here
           }

अब केवल एडीडी विधि अकेले काम नहीं करेगी।

चरण -2: सत्यापन कार्य कैसे कार्य करेगा, कार्य अधिनियम जोड़ें?

हमें डाटाबेस कनेक्शन कोड और सत्यापन कोड (अतिरिक्त तरीके) की आवश्यकता होगी।

     public bool Validate()
     {
    //Granular Customer Code and Name
    return true;
     }

     public bool CreateDBObject()
     {
    //DB Connection Code
    return true;
     }


class Program
{
   static void main(String[] args)
   {
     CustomerComponent.Customer obj = new CustomerComponent.Customer;

     obj.CustomerCode = "s001";
     obj.CustomerName = "Mac";

     obj.Validate();
     obj.CreateDBObject();

     obj.ADD();
    }
}

अब अंतिम उपयोगकर्ता को अतिरिक्त विधि ( Validate() ; CreateDBObject() [ CreateDBObject() [जटिल और अतिरिक्त विधि]) दिखाने की कोई आवश्यकता नहीं है। उपयोगकर्ता को केवल ग्राहक कोड, ग्राहक नाम और एडीडी बटन के बारे में जानने और जानने की आवश्यकता है जो ADD रिकॉर्ड .. अंतिम उपयोगकर्ता इस बारे में परवाह नहीं करता है कि यह डेटा को डाटाबेस में कैसे जोड़ देगा?

चरण -3: अतिरिक्त और जटिल विधियों को निजी बनाएं जिनमें अंतिम उपयोगकर्ता की इंटरैक्शन शामिल नहीं है।

इसलिए उन जटिल और अतिरिक्त विधि को निजी रूप से सार्वजनिक (यानी उन तरीकों को obj.Validate(); ) और obj.Validate(); को हटाकर obj.Validate(); obj.CreateDBObject(); कक्षा में मुख्य कार्यक्रम से हम Encapsulation प्राप्त करते हैं।

दूसरे शब्दों में अंतिम उपयोगकर्ता को इंटरफ़ेस सरलीकृत करना Encapsulation है।

तो अब पूरा कोड नीचे जैसा दिखता है -

 namespace CustomerContent
 {
     public class Customer
     {
        public string CustomerCode = "";
        public string CustomerName = "";

        public void ADD()
        {
           //my DB code will go here
        }

        private bool Validate()
        {
           //Granular Customer Code and Name
           return true;
        }

        private bool CreateDBObject()
        {
           //DB Connection Code
           return true;
        }


  class Program
  {
     static void main(String[] args)
     {
        CustomerComponent.Customer obj = new CustomerComponent.Customer;

        obj.CustomerCode = "s001";

        obj.CustomerName = "Mac";

        obj.ADD();
   }
}

सारांश :

चरण -1 : मेरे ग्राहक वर्ग की क्या ज़रूरत है? अमूर्त है

चरण -3 : चरण -3: अतिरिक्त और जटिल विधियों को निजी बनाएं जिनमें अंतिम उपयोगकर्ता की इंटरैक्शन शामिल नहीं है।

पीएस - उपरोक्त कोड कठिन और तेज़ है।

अद्यतन: नमूना समझाए जाने के लिए इस लिंक पर एक वीडियो है: एब्स्ट्रक्शन और एनकैप्यूलेशन के बीच क्या अंतर है


Encapsulation: कार्यान्वयन विवरण छुपाएं (नोट: डेटा और / या विधियों) जैसे कि बाहरी रूप से समझदार रूप से पठनीय / लिखने योग्य / उपयोग करने योग्य केवल उनके लिए सुलभ है, बाकी सब कुछ "अस्पृश्य" है।

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

कुछ समानताएं हैं, अवधारणाओं के बीच ओवरलैप करें लेकिन इसे याद रखने का सबसे अच्छा तरीका इस तरह है: विवरण छिपाने के बारे में Encapsulation अधिक है, जबकि विवरण सामान्यीकरण के बारे में अधिक है।





abstraction