सार के माध्यम से विवरण छिपाने में क्या मूल्य है? क्या पारदर्शिता में कोई मूल्य नहीं है?

Question

पृष्ठभूमि

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

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

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

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

यहाँ क्या चल रहा है? क्या मैंने कभी भी काम किया है हर प्रणाली को बुरी तरह से डिजाइन किया गया है (इस दृष्टिकोण से कम से कम)?

मेरा दर्शन

जब मैं सॉफ्टवेयर विकसित करता हूं, तो मुझे लगता है कि मैं एक दर्शन का पालन करने की कोशिश करता हूं जो मुझे लगता है कि आर्कलिनक्स दर्शन से निकटता से संबंधित है :

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

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

दिल पर सवाल

1. क्या विवरण छिपाने में वास्तविक मूल्य है?
2. क्या हम पारदर्शिता का त्याग नहीं कर रहे हैं?
3. क्या यह पारदर्शिता मूल्यवान नहीं है?

Comments

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

— बर्नार्ड

मुझे लगता है कि वहाँ एक अच्छा सवाल है, हालांकि, यह अमूर्त के खिलाफ एक शेख़ी की तरह बहुत कुछ पढ़ता है। क्या आप उस पर जोर दे सकते हैं और अपने वास्तविक प्रश्न को और अधिक सामने ला सकते हैं।

— PersonalNexus

क्या आप वाकई "विवरण छिपा रहे हैं" की सही परिभाषा का उपयोग कर रहे हैं? इस संदर्भ में, यह युग्मन को कम करने के बारे में है , न कि आपको किसी चीज के आंतरिक कामकाज को सीखने से रोकने के बारे में।

— एंड्रेस एफ।

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

— एरिक लिपर्ट

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

— माइकल बोर्गवर्ड

Answer 1

विवरण छिपाने का कारण विवरणों को छिपाए नहीं रखना है; यह निर्भर कोड को तोड़ने के बिना कार्यान्वयन को संशोधित करना संभव बनाता है।

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

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

अब यदि आपके सभी लुकअप सूची को पुनर्प्राप्त करके और उस पर लूपिंग करके किए गए थे, तो आपको इसे ठीक करने के लिए बड़ी मात्रा में काम मिला है। यदि आप किसी लाइब्रेरी में हैं तो यह और भी कठिन है और तीसरे पक्ष के उपयोगकर्ता इसका उपयोग कर रहे हैं; आप बाहर नहीं जा सकते और उनका कोड ठीक कर सकते हैं !

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

Comments

मैं इससे सहमत हूं, लेकिन यह सवाल का मुद्दा नहीं था। मैं पूरी तरह से सहमत हो सकता हूं कि विशिष्ट कार्यक्षमता को एनकैप्सुलेट करने का एक तरीका उपयोगी है, लेकिन मुझे लगता है कि यह हमेशा मकसद नहीं होता है। क्या मै गलत हु?

— user606723

@ User606723: यह होना चाहिए। इसका मतलब यह नहीं है कि यह हमेशा है । कुछ लोगों को बात समझ में नहीं आती है और वे अधिक परतों को ढेर कर देते हैं और अधिक परतों को तोड़ देते हैं और चीजों को गड़बड़ कर देते हैं। यही कारण है कि अनुभवी प्रोग्रामर नए डेवलपर्स को सलाह देते हैं कि वे नई तकनीक या तकनीक को कभी न अपनाएं जब तक कि वे इसे समझ न लें।

— मेसन व्हीलर

@ user606723: पारदर्शिता तंग युग्मन को प्रोत्साहित करती है, इसलिए शायद हमेशा बुरा न हो, लेकिन आमतौर पर यह है।

— मलफिस्ट

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

— झॉकिंग

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

— मेसन व्हीलर

Answer 2

मैंने अभी-अभी अमूर्तता के बारे में कोड कम्प्लीट में सेक्शन को पूरा किया है, इसीलिए यह अधिकांश स्रोत हैं।

अमूर्तता की बात यह पूछने की आवश्यकता को दूर करना है कि "यह कैसे लागू किया जाता है?"। जब आप कॉल करते हैं user.get_id(), तो आप जानते हैं कि एक idवह है जो आप वापस लाने जा रहे हैं। यदि आपको पूछना है कि "यह उपयोगकर्ता आईडी कैसे प्राप्त करता है?" तो आप शायद या तो एक की जरूरत नहीं है id, या get_id()कुछ है कि अप्रत्याशित है और खराब डिजाइन किया है देता है।

आप अमूर्त का उपयोग करने के लिए आप डिजाइन करने की अनुमति:

a house with doors and windows

डिजाइन नहीं

a box with four walls,
    with 3 holes,
        two of which fit panes of glass surrounded by wood frames,
        one that fits a large plank of wood with hinges and a metal knob,
etc.

Comments

मैं इन इंटरफेस के बारे में बात नहीं कर रहा हूं। ये इंटरफेस ठीक हैं। मैं विशाल जटिल प्रणालियों के बारे में बात कर रहा हूं जो कई अलग-अलग सार के पीछे खंडित हैं।

— user606723

@ user606723 तब आपका सवाल अमूर्त के बजाय ओवरकॉम्प्लेक्स डिज़ाइन के बारे में है,

— एंड्रेस एफ।

कोड पूर्ण के लिए +1। यह दोनों को शामिल करता है कि एब्सट्रैक्शन को डिजाइन करना क्यों आवश्यक है, और एब्सट्रैक्शन का गलत स्तर डिजाइन में बाधा क्यों डालता है। अपने उदाहरण को और आगे ले जाने के लिए, यदि मैं ज़ोनिंग कार्यालय में काम कर रहा हूँ, तो मैं आपके घरों के बारे में सोचना चाहता हूं, बिना विवरणों के। लेकिन अगर आप घरों के बारे में सोचते हैं कि मैं क्या करता हूं, तो आप एक निर्माण नहीं कर सकते।

— स्पेंसर रथबुन

इस प्रश्न को बंद कर दिया जाना चाहिए या शीर्षक को बदल दिया जाना चाहिए

— जेक बर्जर

Answer 3

क्या विवरण छिपाने में वास्तविक मूल्य है?

हाँ। अमूर्तता को प्रस्तुत करके हम उच्च स्तर पर विचार और कार्यक्रम कर सकते हैं।

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

मनुष्य के पास सीमित कार्यशील स्मृति होती है। अमूर्तता हमें बड़ी प्रणालियों के बारे में तर्क करने की अनुमति देती है।

Aren't we sacrificing transparency?

नहीं। यदि सार का उपयोग नहीं किया जाता है, तो सॉफ़्टवेयर घटक का उद्देश्य दोहराया विवरण में दफन है। डेवलपर्स इस तरह कोड के माध्यम से अपने दिन व्यतीत करते हैं:

for (i = 0; i < pilgrim.wives.size(); ++i) {
  wife = pilgrim.wives[i];
  for (j = 0; j < wife.sacks.size(); ++j) {
     sack = wife.sacks[i];
     for (k = 0; j < sack.cats.size(); ++j) {
        cat = sack.cats[k];
        for (m = 0; m < cat.kits.size(); ++m) {
           ++count;
        }
     }
  }
}

और "ओह हाँ, किटों पर एक और चार-स्तरीय लूप" सोच रहा है, बजाय देखने के

pilgrim.kits.each { ++count; }

क्या यह पारदर्शिता मूल्यवान नहीं है?

जैसा कि आपने बताया, अप्रत्यक्ष लागत है। "सिर्फ मामले में" परतें बनाने का कोई मतलब नहीं है। डुप्लिकेट को कम करने और कोड को स्पष्ट करने के लिए अमूर्त का उपयोग करें।

Answer 4

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

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

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

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

Answer 5

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

एक बार जब आप एक घड़ी पर अलार्म सेट करते हैं, जिस पर आपको विश्वास होता है कि आप काम करेंगे, तो आप यह जानकर कुछ नींद ले सकते हैं कि यह समय के साथ बंद हो जाएगा। एक घंटा पहले जागना, ताकि आप देख सकें कि टिक टिक दूर एक बेकार है।

Comments

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

— user606723

क्या आपको अपने द्वारा उपयोग किए गए प्रत्येक फ्रेमवर्क के लिए कोड परिवर्तन दिखाई देते हैं?

— जेफओ

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

— user606723

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

— ब्लरफ्ल

Answer 6

अपने सवालों के जवाब देने के लिए विशेष रूप से:

क्या विवरण छिपाने में वास्तविक मूल्य है?

हाँ। जैसा कि आप अपने प्रश्न की पहली पंक्ति में स्वीकार करते हैं।

क्या हम पारदर्शिता का त्याग नहीं कर रहे हैं?

ज़रुरी नहीं। एक अच्छी तरह से लिखा अमूर्त आवश्यक होने पर विवरण को समझना आसान बना देगा।

क्या यह पारदर्शिता मूल्यवान नहीं है?

हाँ। आवश्यक / वांछित होने पर विवरण को आसान बनाने के लिए सार को डिज़ाइन और कार्यान्वित किया जाना चाहिए।

Comments

अंत में एक उत्तर मुझे पसंद है।

— user606723

Answer 7

मैं कहूंगा कि विवरण को छुपाना बहुत अच्छा है जब सामान छिपा हुआ है।

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

अब facebook से जुड़ने और उन्हें आइटम प्राप्त करने में बहुत सारे विवरण हैं .. और माइस्पेस से कनेक्ट होने पर समान रूप से बहुत सारे विवरण हैं .. और इसलिए ...

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

इसलिए जब आप कोड का उपयोग करते हैं तो यह कुछ ऐसा होता है:

    new ItemManager(user) //passes in user, allowing class to get all user properties
    ItemManager.GetListItems()

और अब आपको उपयोगकर्ता का डेटा मिल गया है जहाँ भी उन्होंने इसे संग्रहीत किया है, और चूंकि मैं चिंतित हूँ कि वस्तुओं की सूची प्राप्त हो रही है और इसके साथ कुछ किया जा रहा है, और चूंकि इसने केवल 2 लाइनें ली हैं जो काम नहीं करेगी कई और स्टोर जोड़े जाते हैं जिन्हें मैं स्टैक पर सवालों के जवाब / पोस्ट करने के लिए वापस पा सकता हूं ... lol ..

इसलिए, ऐसा होने के लिए सभी प्लंबिंग "छिपी हुई हैं" और जो वास्तव में परवाह करता है कि यह तब तक कैसे करता है जब तक कि मैं वस्तुओं की सही सूची प्राप्त नहीं करता हूं .. यदि आपके पास इकाई परीक्षण हैं, तो आप आराम भी कर सकते हैं क्योंकि परिणाम चाहिए ' पहले से ही मात्रा निर्धारित है ..

Comments

हाँ, लेकिन जिस हिस्से को बनाए रखने की आवश्यकता है, वह कभी भी दो लाइनें नहीं होती हैं। उन पर शिकंजा कसना नामुमकिन है। यह हमेशा 2, 3, 4 वां स्तर नीचे है जिसे आपको बदलने की आवश्यकता है। मैं मानता हूँ कि यह बहुत अच्छा है जब आपके पास एक एपीआई होता है जिसे आप स्थिर होने के लिए भरोसा कर सकते हैं , लेकिन क्या होगा यदि यह आपके व्यवसाय की जटिलता से स्थिर नहीं हो सकता है?

— user606723

@ user606723 यदि आप एपीआई स्थिर नहीं है, तो यह संभवतः अपरिपक्व है, या अधिक संभावना गलत अमूर्तता है

— sdg

@ user606723 - यह सच है, और उन मामलों में सम्मेलनों के नामकरण में खुद को पारदर्शिता के कुछ रूप को परिभाषित करना चाहिए जो वास्तविक प्रोग्रामिंग तर्क / विस्तार को छुपाता है .. और यदि आपको कभी वास्तविक स्रोत को संशोधित करना है, तो आगे के विवरण और विचारों को जानकारीपूर्ण नामकरण के माध्यम से व्यक्त किया जाना चाहिए। इसलिए संक्षेप में, पारदर्शिता को सभी तरह से उचित नामकरण के साथ पूरा किया जा सकता है, हालांकि, हमें वास्तव में सभी तरह से नीचे जाने की आवश्यकता नहीं है।

— हानजोलो

@ sdg, या क्योंकि सिस्टम की आवश्यकताएं हमेशा बदलती रहती हैं। क्योंकि कानून बदलते हैं, क्योंकि दूसरे का एपीआई परिवर्तन, यह हमारे नियंत्रण से बाहर है।

— user606723

@ user606723 - मैं वास्तव में एक वित्तीय सास प्रणाली पर काम करता हूं और मुझे हर रिलीज चक्र में पर्याप्त अमूर्त नहीं होने के नुकसान दिखाई देते हैं। इसमें से कुछ खराब डिजाइन का परिणाम है, लेकिन आमतौर पर यह कोडिंग का परिणाम है जहां यह मूल रूप से इरादा नहीं था। श्रृंखला के नीचे जाना उन टिप्पणियों, नामों और एनकैप्सुलेशन के बिना दर्दनाक हो सकता है । अगर सब मैं करना था Remeasurements.GetRemeasureType (अनुदान), और फिर reMeasure.PerformCalc (), कि भार के जोड़ने और विभिन्न तार्किक शाखाओं के माध्यम से पढ़ने उचित गणना पर पहुंचने या एक नया जोड़ने के लिए की तुलना में बहुत अच्छे होंगे

— हंज़ोलो

Answer 8

जिसे आप "छिपाना" के रूप में संदर्भित करते हैं, कई लोग चिंताओं के अलगाव के रूप में देखते हैं (जैसे कार्यान्वयन बनाम इंटरफ़ेस)।

मेरी राय में, अमूर्तता का एक प्रमुख लाभ डेवलपर के सीमित दिमाग से अनावश्यक विवरण के अव्यवस्था को कम करना है।

यदि कार्यान्वयन कोड को बाधित किया गया था, तो मैं देख सकता हूं कि पारदर्शिता में बाधा के रूप में, लेकिन मैं इसे देख रहा हूं, अमूर्तता सिर्फ अच्छे संगठन की है।

Answer 9

सबसे पहले, एक मशीन कोड निर्देश से परे कुछ भी अनिवार्य रूप से अमूर्त है - एक while...doलूप एक निर्देश पूरा करने के लिए निर्देशों के एक सेट को दोहराने के लिए आवश्यक तुलना और पता कॉल का प्रतिनिधित्व करने का एक सुसंगत प्रतीकात्मक तरीका है। इसी तरह इंट प्रकार बिट्स की एक्स संख्या (आपके सिस्टम पर निर्भर करता है) के लिए एक अमूर्त है। प्रोग्रामिंग सब अमूर्तता के बारे में है।

आप शायद सहमत होंगे कि उन आदिम अमूर्त शक्तिशाली उपयोगी हैं। ठीक है, इसलिए अपना निर्माण करने में सक्षम हो रहा है। OOAD और OOP सभी के बारे में हैं।

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

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

Comments

यहां तक ​​कि मशीन कोड एक अमूर्त, असली, भौतिक, तर्क के नीचे चल रही प्रक्रियाएं हैं, यहां तक ​​कि डिजिटल इलेक्ट्रॉनिक्स एक अमूर्त है कि वास्तव में क्या होता है किसी को भी, जिसने चिप को ओवरक्लॉक करने का हैश बनाया है

— jk।

बहुत सच है, हालांकि यह मशीन अनुदेश स्तर पर अधिक ठोस प्रतीत होता है।

— मैथ्यू फ्लिन

Answer 10

मुझे लगता है कि मैं इस बारे में आपकी भावना को समझता हूं, और मुझे लगता है कि मेरी भी ऐसी ही राय है।

मैंने जावा डेवलपर्स के साथ काम किया है जो 50 कोड लाइन क्लास को 3 वर्गों और 3 इंटरफेस में बदलते हैं क्योंकि इसे समझना आसान है। और मैं इसे बर्दाश्त नहीं कर सका।

बात समझने में मुश्किल थी, बहस करना लगभग असंभव था और कभी "कार्यान्वयन को स्विच करने" की आवश्यकता नहीं हुई।

दूसरी ओर, मैंने कोड भी देखा है जहां कई ऑब्जेक्ट समान व्यवहार साझा करते हैं और एक ही स्थान पर उपयोग किए जाते हैं, और यदि सामान्य इंटरफ़ेस के माध्यम से तरीकों को उजागर किया गया होता तो वे वास्तव में सामान्य छंटाई / प्रसंस्करण छोरों का उपयोग कर सकते थे।

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

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

Answer 11

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

मॉड्यूल लिखते समय, कार्यान्वयन के छिपे हुए हिस्से आपको अन्य कोड को तोड़ने के बिना उन्हें बदलने में सक्षम होने के लिए मन का टुकड़ा देता है, जिसके बारे में आप सोच भी नहीं सकते।

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

---

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

Answer 12

इतने सारे मामलों में आपको बस यह जानने की जरूरत नहीं है कि चीजों को कैसे लागू किया जाता है। मैं लगभग गारंटी दे सकता हूं कि आप people.Where(p => p.Surname == "Smith")दिन में कई बार इस तरह का कोड लिखेंगे फिर भी आप शायद ही कभी सोचेंगे कि "यह Where()तरीका वास्तव में कैसे काम करता है ?" आप बस परवाह नहीं करते हैं - आप जानते हैं कि यह विधि वहां है और यह आपको आपके इच्छित परिणाम प्राप्त करता है। आप क्यों ध्यान रखेंगे कि यह कैसे काम करता है?

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

इस नियम का एक अपवाद है (यह एक नियम के बिना ऐसा नहीं होगा!) और अगर विधि में बग है। इसलिए उपरोक्त उदाहरण में, यदि आपके पास 3 लोगों के साथ एक सूची है और आप जानते हैं कि उनमें से एक का उपनाम स्मिथ है और वे सूची में वापस नहीं आए हैं, तो आप उस पद्धति के कार्यान्वयन की परवाह करते हैं क्योंकि यह स्पष्ट रूप से टूट गया है ।

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

Comments

एह, लेकिन आप कहते हैं कि आप एक है जो कार्यान्वयन को बनाए रखता है। मेरा मतलब है, किसी को कार्यान्वयन के बारे में परवाह है, और वह व्यक्ति आप हैं। आप कार्यान्वयन के उपयोगकर्ता भी हो सकते हैं ... व्यावसायिक आवश्यकताओं में परिवर्तन होता है (उन तरीकों से जो आप अनुमान नहीं लगा सकते हैं) कई परतों में होने वाले परिवर्तनों के कारण। मुझे लगता है कि मेरी बात यह है कि बग उस नियम का एकमात्र अपवाद नहीं है।

— user606723

समस्या हैPeopleFactory.People.Strategy.MakePeople.(CoutryLaw.NameRegistry.NameMaker.Make()) as People.Female

— कोडर

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

— स्टुअर्ट लीलैंड-कोल

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

— स्टुअर्ट लेलैंड-कोल

Answer 13

जानकारी छुपाने से सार निकलता है। यह कम युग्मन में समाप्त होना चाहिए। इससे परिवर्तन में कम जोखिम होने चाहिए। यह सुखद प्रोग्रामर के लिए नेतृत्व करना चाहिए, कोड को छूने पर नर्वस नहीं हो रहा है।

सॉफ्टवेयर वास्तुकला में तीन आवश्यक कानूनों के माध्यम से उन विचारों को व्यक्त किया जाता है:

साइमन का नियम: "पदानुक्रम जटिलता को कम करते हैं।" (पदानुक्रम परिचय अमूर्तता)

पारना का नियम: "केवल जो छिपा हुआ है उसे बिना जोखिम के बदला जा सकता है।"

कॉन्स्टेंटिन का नियम: मजबूत कार्यक्रमों को कम युग्मन और उच्च सामंजस्य की आवश्यकता होती है

Comments

"पदानुक्रम जटिलता को कम करते हैं।" - जरूरी नहीं कि सच हो।

— कोडर

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

— ins0m

Answer 14

मैं एंटरप्राइज़ एप्लिकेशन व्यवसाय में भी हूं, और इस सवाल ने मेरा ध्यान खींचा क्योंकि मेरा भी यही सवाल है। मेरे पास अब तक के अपने कैरियर के दौरान अमूर्त मुद्दे के बारे में कुछ अंतर्दृष्टि थी, लेकिन मेरी अंतर्दृष्टि का मतलब सार्वभौमिक उत्तर नहीं है। मैं नए विचारों और विचारों को सीखना / सुनना जारी रख रहा हूं, इसलिए मेरा मानना ​​है कि अब बदल सकता है।

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

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

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

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

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

Answer 15

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

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

उस ने कहा, यदि आपके अंदर यह देखने की क्षमता है कि इसका उपयोग करने में सक्षम होने के लिए क्या करना है। इसे अच्छे से डिजाइन करना बहुत मुश्किल हो सकता है। एक अच्छा अमूर्त का एक उदाहरण इसके अलावा है - जब आखिरी बार आपको सोचना था कि अंदर क्या होता है? (लेकिन कई बार आप ऐसा करते हैं, जैसे अतिप्रवाह के लिए)।

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

हालांकि, यह सभी अमूर्तताओं का भाग्य लगता है - यहां तक ​​कि सबसे अच्छा - कि अंततः वहाँ अप्रत्याशित (और यकीनन, अप्रत्याशित) परिवर्तन होंगे जो अमूर्त को तोड़ने की आवश्यकता होती है। इसे संबोधित करने के लिए, कुछ अमूर्तियों से बच निकलते हैं, जहाँ आप वास्तव में ज़रूरत पड़ने पर एक गहरे स्तर तक पहुँच प्राप्त कर सकते हैं।

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

Answer 16

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

शायद आप अमूर्त पसंद नहीं करते क्योंकि वे हमेशा जटिलता जोड़ते हैं? हो सकता है कि आपने जो सिस्टम पर काम किया है वह एब्स्ट्रेक्टाइटिस (गर्भपात के उपयोग से अधिक) हो? वे रामबाण नहीं हैं।

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

आप इन दोनों दिशाओं में समय के साथ "फ्लेक्सिड" हुए हैं, यह दिखाते हुए कि आप अमूर्त रिटर्न के निवेश को लगभग माप सकते हैं: अपेक्षाकृत दर्द रहित कार्यान्वयन परिवर्तन और अतिरिक्त नए ग्राहक।

उदाहरण के लिए: जावा में सॉकेट वर्ग के अमूर्त उपयोग से, मुझे यकीन है कि मेरा 1.2 से जावा का कोड कोड अभी भी जावा 7 के तहत ठीक काम करता है (हालांकि उनके कुछ प्रदर्शन परिवर्तन हो सकते हैं)। जावा 1.2 के बाद से, निश्चित रूप से बहुत से नए ग्राहक आए हैं जिन्होंने इस अमूर्त का उपयोग किया है।

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

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

ArchLinux के लिए आपका संदर्भ मेरे लिए समझ में आता है अगर आप ऑपरेटिंग सिस्टम के "अंदर" को अमूर्त के जटिल कार्यान्वयन के रूप में मानते हैं जो उस पर चलने वाले अनुप्रयोगों के लिए ओएस हैं। इसे अमूर्तन की हिम्मत में सरल रखें।

Answer 17

मैं आपके प्रश्न का उत्तर एक प्रश्न के साथ दूंगा; जब आप आज सुबह काम करने के लिए चले गए (मैं मान लूंगा कि आपने वास्तव में ऐसा किया था), क्या आपने ठीक से ध्यान दिया कि इंजन ने ईंधन-हवा के मिश्रण में जाने के लिए वाल्व कैसे खोला, और फिर उन्हें प्रज्वलित किया? नहीं, आपको परवाह नहीं है कि जब आप सड़क पर गाड़ी चला रहे हों तो आपकी कार का इंजन कैसे काम करता है। आप परवाह करते हैं कि यह काम करता है ।

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

ये मूल सिद्धांत एनकैप्सुलेशन और अमूर्त के पीछे मूल सिद्धांत हैं। किसी वस्तु का क्या होता है, इसका ज्ञान उसे यह करने के लिए उपयोग करने के लिए अपेक्षित नहीं होना चाहिए कि वह क्या करता है। यहां तक ​​कि कंप्यूटर प्रोग्रामिंग में, आपके प्रोग्राम को चलाने वाले सीपीयू के भीतर बिजली के रास्तों का विवरण I / O निर्देश, ड्राइवरों, OS सॉफ्टवेयर और रनटाइम की कम से कम आधा दर्जन परतों के पीछे सारगर्भित है। कई बहुत सफल सॉफ्टवेयर इंजीनियर सटीक हार्डवेयर आर्किटेक्चर, या ओएस बिल्ड के बारे में चिंता किए बिना एक बार पूरी तरह से अच्छा कोड लिखते हैं, जो इसे चलाएगा। मुझे शामिल करते हुए।

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

अमूर्तता की अनुमति देता है "यह वैसा ही नहीं है, लेकिन क्योंकि वे दोनों XI हैं उनका उपयोग कर सकते हैं जैसा कि मैं किसी भी X" मानसिकता। यदि आपकी वस्तु एक अमूर्तता प्राप्त या कार्यान्वित करती है, तो आपके उपभोक्ताओं को आपके कार्यान्वयन की अपेक्षा करनी चाहिए कि वे अमूर्त के अन्य ज्ञात कार्यान्वयन के समान या समान परिणाम उत्पन्न करें। एक टोयोटा कैमरी और एक फोर्ड फ्यूजन दोनों "कार" हैं। जैसे, उनके पास अपेक्षित कार्यक्षमता का एक सामान्य सेट है, जैसे कि स्टीयरिंग व्हील। इसे वामावर्त मोड़ो, कार बाईं ओर जाती है। इसे दक्षिणावर्त घुमाएं, कार सही जाती है। आप संयुक्त राज्य अमेरिका में किसी भी कार में बैठ सकते हैं और उम्मीद कर सकते हैं कि कार में स्टीयरिंग व्हील और कम से कम दो पैडल हों, सही में "कार जाती है" पेडल और केंद्र में "कार स्टॉप" पैडल हो ।

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