"समय से पहले अमूर्त" क्या है?


10

मैंने सुना है कि वाक्यांश को घेर लिया गया है और मेरे लिए तर्क पूरी तरह से पागल लग रहे हैं (क्षमा करें, अगर मैं यहां स्ट्रोमैन कर रहा हूं, तो यह मेरा उद्देश्य नहीं है), आम तौर पर इसकी तर्ज पर कुछ किया जाता है:

आप सामान्य स्थिति क्या है, यह जानने से पहले आप अमूर्तता पैदा नहीं करना चाहते हैं, अन्यथा (1) आप अपने अमूर्त में ऐसी चीजें डाल सकते हैं जो संबंधित नहीं हैं, या (2) महत्व की चीजों को छोड़ देना।

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

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

हमें हमेशा अमूर्तता से नीचे की ओर काम करना चाहिए क्योंकि यह चीजों को करने का सबसे व्यावहारिक तरीका है, न कि दूसरे तरीके से।

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

यहां एक उदाहरण दिया गया है, जो कहता है कि एक ग्राहक आपको आइटम बैगिंग रोबोट बनाने की इच्छा रखता है:

public abstract class BaggingRobot() {
    private Collection<Item> items;

    public abstract void bag(Item item);
}

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

समय से पहले गर्भपात जैसी कोई चीज नहीं होती है, केवल समय से पहले गर्भपात होता है। इस कथन में गलत क्या है? मेरे तर्क में दोष कहां है? धन्यवाद।


1
समय से पहले अमूर्तता के विपरीत YAGNI है - आपको इसकी आवश्यकता नहीं है, जो मेरी राय में लगभग हमेशा गलत है। लगभग। मैंने ऐसा होते देखा है, लेकिन यह दुर्लभ है। मैं ज्यादातर आप यहाँ कह रहे हैं के साथ सहमत हूँ।
user1118321

जवाबों:


19

कम से कम मेरी राय में, समय से पहले अमूर्त काफी आम है, और विशेष रूप से OOP के इतिहास में इतनी जल्दी था।

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

नतीजतन, हम उन कोड के साथ समाप्त हो गए जो वास्तव में केवल कर्मचारियों के रिकॉर्ड के साथ कहने, कहने के लिए आवश्यक थे, लेकिन सावधानी से लिखे जाने के लिए तैयार थे यदि आपने कभी एक अर्चना या शायद एक क्रस्टेशियन किराए पर लिया हो।


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

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

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

6

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

आप अमूर्तता को केवल इसलिए नहीं जोड़ेंगे क्योंकि आपको इसकी आवश्यकता हो सकती है ( यह सोचने के लिए कोई वास्तविक आधार नहीं है कि आपको भविष्य में नई कक्षाएं जोड़ने की आवश्यकता होगी)। एक उचित रूपक यहाँ नलसाजी हो सकता है। उम्मीद है कि आप सहमत होंगे कि एक 6-दिशात्मक पाइप जो पानी को ऊपर / नीचे, पूर्व / पश्चिम, उत्तर / दक्षिण में प्रवाहित करने की अनुमति देता है, आपके लिए सबसे लचीला प्रकार का पाइप हो सकता है। आप सैद्धांतिक रूप से 6-दिशात्मक पाइप का उपयोग कर सकते हैं कहीं भी जहां एक पाइप की आवश्यकता होती है, और अनावश्यक दिशाओं को बंद कर दें, है ना?

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

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

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


आप थोड़े-से लगते हैं class... भले ही कई वर्ग हैं, अमूर्त का उपयोग / उन्हें लाभ पहुंचाने तक सीमित नहीं है।
Deduplicator

1
@ डेडप्लिकेटर मेला पर्याप्त, लेकिन वह मेरी बात नहीं बदलता है। यदि अमूर्त का उपयोग किया जाता है, तो यह तुरंत लाभकारी होना चाहिए या निकट भविष्य में यह एक नियोजित परिवर्तन होना चाहिए। यह महत्वपूर्ण नहीं है कि हम कक्षाओं या कार्यात्मक प्रोग्रामिंग की बात कर रहे हैं।
नील

3

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

उसको देखते हुए, किसी भी संज्ञा (या संज्ञा वाक्यांश) को एक संभावित वर्ग माना जाएगा। कोई भी क्रिया (या क्रिया वाक्यांश) कक्षाओं पर संभावित तरीके होंगे। तो "बैगिंग रोबोट" एक वर्ग हो सकता है BaggingRobot। "एक बैग खोलें" विधि बन सकती है OpenBag

कुछ पुनरावृत्तियों के बाद, यह एक वर्ग आरेख में बदल जाएगा।

इस बिंदु पर, कोई अमूर्त वर्ग नहीं हैं। ग्राहक बैगिंग रोबोट की एक अमूर्त अवधारणा नहीं चाहता है। वे एक ऐसा रोबोट चाहते हैं जो सामान को बैग में रखे। सभी वर्ग ठोस हैं और विधियों का एक समूह है।

सार कक्षाएं केवल तब ही शुरू की जाती हैं जब यह स्पष्ट हो जाता है कि:

  • कई समान वर्ग हैं जो एक पदानुक्रम बना सकते हैं।
  • वे वास्तव में कुछ साझा करते हैं, ताकि एक आधार वर्ग एक उपयोगी उद्देश्य पूरा करे।

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


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

एक BaggingRobot ऑब्जेक्ट जो आइटम को बैग ऑब्जेक्ट्स में रखता है, पहले से ही एक वास्तविक बैगिंग रोबोट का एक अमूर्त है जो सामानों को बैग में रखता है।
user253751

1

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

अपने उदाहरण के साथ, क्या आप कल्पना करते हैं कि यह रोबोट ही है , जिन वस्तुओं को बैग किया जा रहा है या बैगिंग का तरीका है जो लाइन को बदल देगा?

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

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

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

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

public class Item {
/* Relevant item attributes as specified by customer */
}
public class BaggingRobot {
  private Collection<Item> items;

  public void bag(Item item);
}

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

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

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

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


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

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

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

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

"या आप अपने आप को इस तरीके से बढ़ाते हुए पा सकते हैं कि गलत चीजों को अमूर्त करके लाइन के नीचे डिजाइन को जटिल बना दिया जाए।" ... क्या आपने ईमानदारी से पढ़ा कि मैंने क्या कहा या सिर्फ शीर्षक? गंभीरता से? बिंदु (1) और (2)
जेम्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.