क्या ऐसी कई चीजें हैं?

Question

जब आप विकास कर रहे हों, तो आप कब निर्धारित कर सकते हैं कि आपके आवेदन में बहुत सारी अनावश्यक कक्षाएं हैं या नहीं? क्या आपके पास कितनी कक्षाएं होनी चाहिए इस पर एक निश्चित सीमा है?

Answer 1

वास्तव में ऐसी कोई चीज़ नहीं है जैसे "बहुत अधिक कक्षाएं"। समस्या हो सकती है "बहुत सी कक्षाएं एक ही काम कर रही हैं।"

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

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

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

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

Answer 2

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

Answer 3

आम तौर पर कक्षाओं का बहुत मतलब है कि आप आमतौर पर अपनी समस्याओं का समाधान कर सकते हैं। यह आम तौर पर अच्छा होता है क्योंकि इसका मतलब है कि आपको आशा है कि जब आपको अंततः आवश्यकता हो तो व्यवहार करने में आसान समय लगेगा।

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

जब तक कक्षाएं अच्छी तरह से आदेशित होती हैं और एक अच्छी तरह परिभाषित उद्देश्य है तो इसे कई कक्षाएं होने में कोई समस्या नहीं होनी चाहिए।

कक्षाएं कसकर युग्मित होने पर या किसी वर्ग की ज़िम्मेदारी अच्छी तरह परिभाषित नहीं होने पर समस्या कैसे हो सकती है। युग्मन के बारे में अधिक जानकारी मिल सकती है।

नीचे दी गई टिप्पणी में एक और समस्या का उल्लेख किया जा सकता है। यदि आपके बहुत से वर्गों में समान कोड है तो आपके पास डुप्लिकेशन समस्या है। यह आमतौर पर सिस्टम में कम रखरखाव की ओर जाता है क्योंकि डुप्लीकेट कोड में बदलाव की आवश्यकता होती है, जिसे आपको कई बार बदलना पड़ता है। यह आमतौर पर विरासत द्वारा हल किया जाता है।

Answer 4

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

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

यदि आप विजुअल स्टूडियो 2012 का उपयोग कर रहे हैं तो http://msdn.microsoft.com/en-us/library/bb385910.aspx और http://msdn.microsoft.com/en-us/library/dd264939.aspx में कोड मेट्रिक्स और कोड विश्लेषण कैसे काम करता है इस बारे में जानकारी है।

यह मेरे स्वयं के ऐप के आधार पर विजुअल स्टूडियो 2012 में कोड मेट्रिक्स की एक रिपोर्ट का एक उदाहरण है, मूल्य http://msdn.microsoft.com/en-us/library/bb385914.aspx पर समझाया गया है।

Project: <<Projectname>> 
Configuration: Debug 
Scope: Project 
Assembly: <<Path>> 
Maintainability Index: 84 
Cyclomatic Complexity: 479 
Depth of Inheritance: 8 
Class Coupling: 189 
Lines of Code: 903 

Answer 5

मुझे लगता है कि यह निर्भर करता है कि किस क्षेत्र में बड़ी संख्या में कक्षाएं हैं। यदि सामान्य व्यापार तर्क वाले कई स्थैतिक वर्ग हैं, तो यह बुरा माना जाएगा क्योंकि स्थैतिक वर्गों का उपयोग केवल सामान्य सहायक तरीकों के लिए किया जाना चाहिए। स्टेटिक कक्षाओं में कभी भी सामान्य व्यापार तर्क नहीं होना चाहिए।

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

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

Answer 6

के रूप में कई अन्य लोगों का सुझाव दिया है, "यह निर्भर करता है ..."

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

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

Answer 7

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

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

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

Answer 8

केंट बेक आपके प्रश्न का उत्तर देते हैं। 'क्लीन कोड ए हैंडबुक ऑफ़ एग्इल सॉफ्टवेयर क्राफ्ट्सशिप' पुस्तक में जेफ लैंगर ने केंट बेक द्वारा निर्दिष्ट चार डिजाइन नियमों पर चर्चा की।

(महत्व के क्रम में)

1. सभी परीक्षणों
2. कोई दोहराव
3. प्रोग्रामर
4. की मंशा व्यक्त शामिल कक्षाएं और तरीकों

की संख्या को कम करता है चलाता है

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

(! ध्यान दें, यह केंट बेक्स राय, इतना नहीं मेरा है)

Answer 9

दार्शनिक:

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

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

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

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

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

पहचान:

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

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

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

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

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

यदि आप अपनी कक्षाओं को देखते हैं तो आप कुछ चीजें उठा सकते हैं। कोड कितना ओओ है और एफओ कितना है (ऑब्जेक्ट ओरिएंटेड बनाम कार्यक्षमता ओरिएंटेड)?

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

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

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

कारणों:

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

बहुत से वर्गों के सबसे बड़े ड्राइवरों में से एक क्लाउड में मानक से पालन करने का प्रयास है जो वास्तव में आपकी स्थिति पर लागू नहीं होता है। इस मामले में आप अपनी समस्या के जवाब में प्रोग्रामिंग नहीं कर रहे हैं। आप अन्य लोगों की समस्याओं के जवाब में प्रोग्रामिंग कर रहे हैं।

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

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

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

काउंटर उदाहरण:

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

मैंने हाल ही में बहुत कम कक्षाओं के साथ ऑनलाइन लाइब्रेरी का उपयोग किया है। इसमें कई जिम्मेदारियों वाले एक वर्ग शामिल थे। यह फ़ाइल फ़ाइल हैंडल (एक आदिम प्रकार के रूप में) को लिखने के लिए लिखने के लिए स्वचालित रूप से आउटपुट HTTP हेडर को स्वचालित रूप से आउटपुट करने के तरीकों के आधार पर उत्पन्न होता है (जैसे addImage, addText, आदि)।

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

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