कितना अमूर्तता बहुत अधिक है?

Question

एक ऑब्जेक्ट उन्मुख प्रोग्राम में: कितना अमूर्तता बहुत अधिक है? कितना सही है?

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

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

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

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

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

तो यह बहुत अधिक कब है? खाली परतों और अतिरिक्त "आवश्यकता हो सकती है" abstractions किस बिंदु पर overkill हो जाते हैं? बहुत कम कितना है? मीठी जगह कहां है?

वहाँ आप अपने कैरियर के दौरान मदद की है कि आप अमूर्त की राशि की जरूरत न्याय में मिल गया है अंगूठे के किसी भी भरोसेमंद नियम हैं?

Answer 1

तो यह बहुत अधिक कब है? किस बिंदु पर खाली परतें और अतिरिक्त "शायद आवश्यकता" अवशोषण अधिक हो गया है? कितना छोटा है? मीठे स्थान कहां है?

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

• You ain't gonna need it
• The use/reuse paradox
• Project triangle: good, fast, cheap
• All problems in computer science can be solved by another level of indirection (David Wheeler)

विकास खोजने के बारे में सब है:

यहाँ कुछ लिंक है कि आप जवाब की खोज में प्रेरित हो सकता है विभिन्न tensio के बीच सही संतुलन एनएस जो किसी भी सॉफ्टवेयर इंजीनियरिंग प्रयास में मौजूद हैं।

Answer 2

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

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

Answer 3

बस शब्दों में कहें, अगर कोड को समझना मुश्किल हो तो बहुत अधिक अमूर्तता है।

अब यह कहना नहीं है कि आपको सब कुछ कड़ी मेहनत करनी चाहिए, क्योंकि यह लिखना और पढ़ना सबसे आसान कोड है।

सबसे आसान परीक्षण इसे या तो कुछ दिनों तक डालना है, इसे वापस ले लें और खुद से पूछें, क्या इससे कोई अर्थ हो जाता है। एक बेहतर तरीका यह है कि इसे किसी और को दें, और देखें कि क्या वे इसके सिर या पूंछ बना सकते हैं।

Answer 4

(6a)RFC 1925 देखें और पता है कि यह वास्तव में सच है। अबास्ट्रक्शन परतों को जोड़कर आप ठीक नहीं कर सकते हैं, जो बहुत अधिक अमूर्त परतों के कारण होते हैं। (विशेष रूप से, अमूर्तता का प्रत्येक टुकड़ा पूरी चीज़ को समझने में कठोर बनाता है।)

Answer 5

सिद्धांत रूप में, यह केवल तीन (काफी सरल) वेरिएबल का उपयोग करके सरल गणित की बात होना चाहिए:

• एस = उपयोग
से बचत
• सी = अतिरिक्त कपोल-कल्पना की लागत
• पी = उपयोग की संभावना

यदि एस * पी> सी, तो कोड अच्छा है। यदि एस * पी < सी, तो यह बुरा है।

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

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

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

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

Answer 6

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

OTOH, यह निश्चित रूप से अमूर्त के किसी भी प्रकार के बिना एक जटिल, unmaintainable गड़बड़ कार्यक्रम संभव है, और कभी कभी, "मानकीकृत" अमूर्त परतों मदद कर सकते हैं एक प्रणाली सबसे बेहतर लोग अपने दम पर ऐसा करने में सक्षम हो जाएगा की संरचना करें।

Answer 7

कैसे थोड़ा बहुत कम है?

आप एक नियमित आधार पर "कम स्तर" तत्वों के साथ काम कर रखना और आप लगातार की तरह आप डॉन 'लग रहा है जब टी यह कर जाना चाहते हैं। सार 'दूर।

तो जब यह बहुत ज्यादा है?

जब आप नियमित आधार पर कुछ कोड भागों के बिट्स और टुकड़े नहीं बना सकते हैं और उन्हें पिछली परत पर डीबग करना होगा। आपको लगता है कि यह विशेष परत कुछ भी योगदान नहीं देती है, केवल एक बाधा है। जाने दो।

मिठाई स्थान कहां है?

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

ab + ac => a(b + c) 

अब आप तीन के बजाय दो कार्यों के साथ एक ही बात करते हैं:

Answer 8

कपोल-कल्पना की बात विशिष्ट लोगों से बाहर सामान्य गुणों, गणितीय प्रक्रिया में तरह कारक है। इस फैक्टरिंग ने हमारी अभिव्यक्ति को सरल बना दिया।

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

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

चीजें एक आम संपत्ति साझा करती हैं।अधिक फायदेमंद एक अमूर्त हो सकता है:

ab + ac + ad + ae + af 

रहे हैं:

a(b + c + d + e + f) 

यह 9 आपरेशन को कम करेगा 5. को

मूल रूप से प्रत्येक अच्छा अमूर्त मोटे तौर पर एक प्रणाली की जटिलता आधा कर देगा।

आपको हमेशा एक कम संपत्ति को साझा करने के लिए कम से कम दो चीजों की आवश्यकता होती है ताकि एक अमूर्तता उपयोगी हो सके। बेशक आप एक ही बात अलग आंसू इसलिए यह एक अमूर्त की तरह दिखता है, लेकिन यह यह उपयोगी है मतलब यह नहीं है:

10 => 5 * 2 

आप शब्द को परिभाषित नहीं कर सकते हैं "आम" यदि आप केवल एक इकाई है।

तो अपने प्रश्न का उत्तर देने के लिए। यदि आपके सिस्टम को यथासंभव सरल बनाते हैं तो आपके पास पर्याप्त अवशोषण हैं।

(मेरी उदाहरणों में, इसके अलावा, प्रणाली के कुछ हिस्सों से जोड़ता है, जबकि गुणा एक सार-ठोस रिश्ते को परिभाषित करता है।)