सॉफ्टवेयर डिजाइन में ओ-नोटेशन

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

परिभाषा

हम कहते हैं कि प्रोग्रामर को च (n) क्रियाओं के लिए "O" की आवश्यकता होती है, अगर प्रोग्रामर को f (n) से अधिक परिवर्तन करने की आवश्यकता नहीं है, तो प्रोग्राम में लगातार बदलाव को लागू करने के लिए लॉजिकल रूप से अलग-अलग बदलाव किए जाते हैं, जहाँ n का अर्थ प्रोग्राम का आकार है।

मैट्रिक्स

रॉबर्ट मार्टिन की कुछ डिज़ाइन विशेषताओं पर विचार करें और O- अंकन के संदर्भ में उनका मूल्यांकन करें।

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

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

जब एक बार बदलाव किया जाता है, तो फ्रैगिलिटी कई स्थानों पर क्षतिग्रस्त होने वाले प्रोग्राम की संपत्ति है। अक्सर नई समस्याएं उन हिस्सों में पैदा होती हैं जिनका कोई वैचारिक संबंध नहीं है जो बदल गया था।

हम मॉड्यूल के तार्किक कनेक्शन के प्रश्न पर विचार नहीं करेंगे जिसमें परिवर्तन होते हैं। इसलिए, संकेतन के दृष्टिकोण से, नाजुकता और कठोरता के बीच कोई अंतर नहीं है, और कठोरता के लिए मान्य तर्क नाजुकता पर लागू होते हैं।

एक डिजाइन अक्रिय है यदि इसमें ऐसे हिस्से होते हैं जो अन्य प्रणालियों में उपयोगी हो सकते हैं, लेकिन इन भागों को मूल प्रणाली से अलग करने की कोशिश से जुड़े प्रयास और जोखिम बहुत महान हैं।

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

चिपचिपापन।

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

O संकेतन के संदर्भ में निम्नलिखित चिपचिपाहट को लघुदृष्टिता कहा जा सकता है। हां, पहले तो डेवलपर के पास वास्तव में O (n) (कठोरता या नाजुकता के कारण) के बजाय O (1) में बदलाव करने का अवसर होता है, लेकिन अक्सर ऐसे बदलावों से और भी अधिक कठोरता और नाजुकता हो जाती है, अर्थात कठोरता की गहराई में वृद्धि। यदि आप इस तरह की "घंटी" को अनदेखा करते हैं, तो बाद के बदलावों को "हैक" के साथ हल करना संभव नहीं हो सकता है और आपको कठोरता की शर्तों ("घंटी" से पहले की तुलना में अधिक) में बदलाव करना होगा या सिस्टम को अच्छी स्थिति में लाना होगा। यही है, जब चिपचिपाहट का पता लगाया जाता है, तो सिस्टम को ठीक से फिर से लिखना बेहतर होता है।

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

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

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

ठोस अधिसूचना के बारे में आवेदन

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

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

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

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

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

मार्टिन इस स्थिति के बारे में कहते हैं कि आपको अनुमान नहीं लगाना चाहिए (यदि आप निश्चित रूप से नहीं जानते हैं, तो निश्चित रूप से) पहले बदलाव को कैसे बंद करें, लेकिन पहले बदलाव के बाद यह बंद होने के लायक है, क्योंकि पहला परिवर्तन एक मार्कर था कि सिस्टम वर्तमान स्थिति में जरूरी नहीं रहेगा। यह तार्किक है, क्योंकि हम गैर-निकटता के कारण O (1 * n) क्रियाएं करते हैं, और फिर बाद के परिवर्तनों से खुद को बंद करने के लिए O (m) क्रियाएं करते हैं। कुल मिलाकर, हमें समग्र जटिलता ओ (एन + एम) मिलती है, लेकिन साथ ही हम सभी क्रियाएं ठीक उसी समय करते हैं जब वे आवश्यक हो जाते हैं और अग्रिम में कुछ भी नहीं करते हैं, यह जानने की आवश्यकता नहीं है कि क्या इसकी आवश्यकता होगी।

पैटर्न और O- संकेतन

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

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

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

चूंकि डेटा संरचनाएं कुछ स्पर्शोन्मुख दवाओं के साथ कुछ कार्यों का समर्थन कर सकती हैं, और कुछ बुरे लोगों के साथ, इसलिए पैटर्न कुछ परिवर्तनों के संबंध में और दूसरों के संबंध में कठोरता से व्यवहार करते हैं।

उचित सीमा

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