अमूर्तता के स्तर का निर्धारण कैसे करें

35

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

मेरा सवाल यह है कि अमूर्तता के स्तर को निर्धारित करने के लिए क्या मापदंड है?

मैं पुस्तक से अनुच्छेद उद्धृत करता हूं:

यह सुनिश्चित करने के लिए कि हमारे कार्य "एक काम" कर रहे हैं, हमें यह सुनिश्चित करने की आवश्यकता है कि हमारे कार्य के भीतर कथन एक ही स्तर पर हैं। यह देखना आसान है कि लिस्टिंग 3-1 इस नियम का उल्लंघन कैसे करती है। वहाँ अवधारणाएँ हैं जो अमूर्तता के बहुत उच्च स्तर पर हैं, जैसे गेटहेटलएम (); अन्य जो अमूर्तता के एक मध्यवर्ती स्तर पर हैं, जैसे: स्ट्रिंग पृष्ठपाथनाम = पथप्रदर्शक.प्रेंडर (पृष्ठपथ); और अभी भी अन्य जो उल्लेखनीय रूप से निम्न स्तर के हैं, जैसे: .append ("\ n")।

abstraction

— OKAN
स्रोत

2

संबंधित: अमूर्तता क्या है? ।

— एडम लेअर

27

लेखक बताते हैं कि "रीडिंग कोड ऊपर से नीचे तक" उस हिस्से के उप-भाग में है जो अमूर्त (पदानुक्रमित इंडेंटेशन मेरा) के बारे में बात करता है:

[...] हम जैसे कि यह का एक सेट थे कार्यक्रम को पढ़ने में सक्षम होना चाहता हूँ के लिए पैराग्राफ, जिनमें से प्रत्येक अमूर्त के वर्तमान स्तर का वर्णन और संदर्भित बाद में किया जाता है करने के लिए अगले स्तर नीचे पर पैराग्राफ।

सेटअप और टियरडाउन को शामिल करने के लिए, हम सेटअप को शामिल करते हैं, फिर हम परीक्षण पृष्ठ की सामग्री को शामिल करते हैं, और फिर हम फाड़ को शामिल करते हैं।

सेटअप को शामिल करने के लिए, हम सूट सेटअप को शामिल करते हैं यदि यह एक सूट है, तो हम नियमित सेटअप को शामिल करते हैं।

सुइट सेटअप को शामिल करने के लिए, हम "सुइटसेटअप" पृष्ठ के लिए मूल पदानुक्रम की खोज करते हैं और उस पृष्ठ के पथ के साथ एक सम्मिलित विवरण जोड़ते हैं।

माता-पिता की खोज करने के लिए ...

इसके साथ जाने वाला कोड कुछ इस तरह होगा:

public void CreateTestPage()
{
    IncludeSetups();
    IncludeTestPageContent();
    IncludeTeardowns();
}

public void IncludeSetups()
{
    if(this.IsSuite())
    {
        IncludeSuiteSetup();
    }

    IncludeRegularSetup();
}

public void IncludeSuiteSetup()
{
    var parentPage = FindParentSuitePage();

    // add include statement with the path of the parentPage
}

और इसी तरह। हर बार जब आप फ़ंक्शन पदानुक्रम के नीचे गहराई से जाते हैं, तो आपको अमूर्तता के स्तर को बदलना चाहिए। उपरोक्त उदाहरण में IncludeSetups, IncludeTestPageContentऔर IncludeTeardownsसभी अमूर्तता के समान स्तर पर हैं।

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

— एडम लीयर
स्रोत

10

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

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

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

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

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

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

— DXM
स्रोत

2

मेरा सवाल यह है कि अमूर्तता के स्तर को निर्धारित करने के लिए क्या मापदंड है?

अमूर्त स्तर स्पष्ट माना जाता है। यदि यह समस्या डोमेन का हिस्सा है - यह प्रोग्रामिंग भाषा का हिस्सा नहीं है, तो यह सार है। "अत्यधिक सार" == "वास्तविक नहीं" == "समस्या डोमेन" की तुलना में अधिक स्पष्ट होना कठिन है। और "सार नहीं == ठोस == भाषा का हिस्सा"। यह अमूर्त स्तर तय करने के लिए तुच्छ माना जाता है। वहाँ बिल्कुल भी सूक्ष्मता नहीं होनी चाहिए।

.append("\n")सार नहीं है। यह सिर्फ एक तार पर एक चरित्र डालता है। वह ठोस होगा। सार नहीं।

String pagePathName = PathParser.render(pagePath);स्ट्रिंग्स से संबंधित है। ठोस चीजें। आंशिक रूप से कंक्रीट प्रोग्रामिंग भाषा सुविधाओं पर। आंशिक रूप से अमूर्त "पथ" और "पार्सर" अवधारणाओं के साथ काम करना।

getHtml(); सार। "मार्कअप" और ऐसी चीजें, जो तुच्छ, ठोस, भाषा की विशेषताएं नहीं हैं, से निपटती हैं।

सार == भाषा की विशेषता नहीं है।

कंक्रीट == एक भाषा सुविधा।

— S.Lott
स्रोत

1

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

— रॉबर्ट हार्वे

1

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

foreach(var customer in allCustomers)
{
    if (CustomerIsChanged(customer)
        customer.Save();
}

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

— user7542047
स्रोत