संक्षेप में सार के बारे में

ऐसा होता है कि परियोजना एक ठहराव पर आती है, और इसका आगे का विकास असंभव हो जाता है। अक्सर नहीं, ऐसी विफलता का कारण विकास की शुरुआत में रखी गई असफल वास्तुकला है। या क्या आपको इस बारे में बहस करनी है कि "दो कुर्सियों" में से कौन सी बेहतर है, या शायद भाग भी लें और ईमानदारी से न समझें कि आपका प्रतिद्वंद्वी ऐसा कैसे सोच सकता है!

फिर हम बहुत से सार को समझने की कोशिश नहीं करेंगे कि वे कहाँ से आते हैं और उनके साथ क्या करना है।

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

परिभाषा से हम यह निष्कर्ष निकाल सकते हैं कि केवल सार्थक ही अमूर्त हो सकता है। इस मामले में, धारणा केवल वास्तविक दुनिया का प्रक्षेपण है। यह पता चला है कि वास्तविक पर सभी प्रतिबिंब वास्तविक के हमारे मॉडल पर प्रतिबिंब हैं।

सार रूप पदानुक्रम बनाते हैं, और दोनों निजी संस्थाओं के साथ पहचाने जा सकते हैं और समान संस्थाओं को उच्च-स्तरीय अमूर्त में संयोजित कर सकते हैं।

चेतना सार

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

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

विकास में अमूर्तता

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

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

अब जरूरत नहीं है

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

हर चीज में संतुलन होना चाहिए। अपने लिए, मैंने निम्नलिखित मेमो को बाहर रखा।

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

कुल मिलाकर

सार हमारी चेतना में निर्मित एक उपकरण है, किसी भी अन्य की तरह उनके पास अपने पेशेवरों और विपक्ष हैं, लेकिन विकल्पों को जानने से केवल एक बेहतर तरीका खोजने में मदद मिलती है।