ऑब्जेक्ट ओरिएंटेड ऍनालिसिस आणि डिझाइनच्या मॉड्यूल 09 मध्ये आपले स्वागत आहे. आपण ऑब्जेक्ट मॉडेल्सच्या एलिमेंट्स बद्दल चर्चा करत आहोत. ऑब्जेक्ट मॉडेल्समध्ये 4 प्रमुख एलिमेंट्स आणि 3 किरकोळ एलिमेंट्स आहेत हे आपण शेवटच्या मॉड्यूलमध्ये नोंदवले आहे.
4 प्रमुख एलिमेंट्स पैकी आपण अॅब्स्ट्रॅक्शन बद्दल आधीच चर्चा केली आहे. आपण पाहिले आहे की सिस्टिम मधील मुख्य संकल्पना ओळखण्यासाठी अॅब्स्ट्रॅक्शनचा मोठ्या प्रमाणावर वापर केला जातो आणि ते प्रामुख्याने डिझाइन फॉर्मलायझेशनशी संबंधित आहे. तर एनकेप्सुलेशनला सिस्टिमच्या अंमलबजावणीच्या पैलूंशी अधिक सामोरे जावे लागते जे अंमलबजावणी एनकेप्सुलेट करते किंवा पॅकेज करते आणि वापरकर्त्यांना काँट्रॅक्च्युअल इंटरफेस चे फक्त मर्यादित आवश्यक दृश्य देऊन सार्वजनिक दृष्ट्या दूर ठेवते आणि आपण 2 भिन्न उदाहरणे पाहिली आहेत.
एनकेप्सुलेशन आणि अॅब्स्ट्रॅक्शन आपापसात इंटरकनेक्ट. पुढे बनवताना, आपण या मॉड्यूलमध्ये ऑब्जेक्ट मॉडेल्सच्या इतर 2 आवश्यक वैशिष्ट्यांचा विचार करू जसे की मॉड्यूलरिटी . ही रूपरेषा आहे; आपण पटकन एक रीकॅप सादर करू आणि नंतर मॉड्यूलरिटी आणि हायरार्कीच्या वैशिष्ट्यांवर चर्चा करू.
तर, हे फक्त तुम्हाला आठवण करून देण्यासाठी आहे की हे ऑब्जेक्ट मॉडेल्सचे वेगवेगळे एलिमेंट्स आहेत ज्यांची आपण मॉडेलच्या या मालिकेत चर्चा करत आहोत आणि आपण आता मॉड्यूलरिटीवर लक्ष केंद्रित करू. तर, मॉड्युलरिटीमध्ये प्रोग्राम किंवा सॉफ्टवेअरचा कोड, सॉफ्टवेअरचा डेटा , तो कसा आयोजित केला जातो या सर्व गोष्टींमध्ये लक्षणीय काम करावे लागते. त्यामुळे मॉड्युलॅरिटी म्हणजे प्रोग्रामचे वैयक्तिक कंपोनंट मध्ये विभाजन करणे आणि आपल्याला हे करायचे आहे की आपल्याला मॉड्यूलर डिझाइन बनवायचे आहे जेणेकरून आपण पुन्हा कॉम्प्लेक्सिटी मॅनेजमेंट करू शकू.
त्यामुळे सिस्टम मॅनेजमेंटचा हा आणखी एक पैलू आहे जो आपण सॉफ्टवेअर बद्दल, सॉफ्टवेअरच्या इन्हेरेंट कॉम्प्लेक्सिटी बद्दल उपस्थित केलेल्या मूळ समस्यांचे निराकरण करतो. आणि कोणत्याही डिझाइन मध्ये किंवा कोणत्याही अंमलबजावणीमध्ये सिमॅटिक आहेत. तर, एका उदाहरणाने सुरुवात करू, त्यामुळे कृपया या डायग्रॅमच्या गोंधळाबद्दल काळजी करू नका, हे हेतुपुरस्सर आहे.
आपण हे दाखवण्याचा प्रयत्न करत आहोत की जर तुम्ही मशिन लर्निंग सिस्टमच्या डिझाईनवर काम करत असाल तर तुम्हाला अशा प्रकारचे वेगवेगळे कंपोनंट हाताळण्याची आवश्यकता आहे आणि वेगवेगळ्या रंगात दाखवलेले हे वेगवेगळे सेट वेगवेगळे मॉड्यूल दाखवतात. म्हणून मी पटकन मॉड्यूल्स भोवती फेरफटका मारेन. एक मॉड्युल म्हणजे डेटा ट्रान्स्फॉर्मेशन किंवा व्हेक्टर मॅनिफोल्ड्सच्या विविध स्टॅंडर्ड फॉर्म्समध्ये रिप्रेझेंट करावे लागेल आणि असेच सर्व.
या ट्रान्सफॉर्मेशन टास्कशी संबंधित कंपोनंट डेटा ट्रान्सफॉर्मेशन मॉड्यूलमध्ये एकत्र ठेवले जातात. दुसरे मॉड्यूल किंवा दुसरे मॉड्यूल हे स्ट्रक्चर प्रेडिक्शन आहे जे डेटाच्या एका विशिष्ट पॅटर्न बद्दल बोलते जे तुम्ही काय करू शकता, तुम्ही त्यासाठी प्रेडिक्शन येण्याजोग्या मॉडेल कसे लावू शकता, आपण बर्याचदा मार्कोव्ह रँडम फील्डचा वापर करू किंवा स्ट्रक्चर प्रेडिक्शन करण्याच्या इतर मार्गांनी. पुन्हा याचे तपशील मशीन लर्निंगच्या क्षेत्रामध्ये आहेत त्यामुळे तुम्हाला ते समजेल अशी अपेक्षा नाही आणि ती देखील गरज नाही.
मी फक्त हे दाखवण्याचा प्रयत्न करत आहे की हे विविध प्रकारचे मॉड्यूल आहेत जे कॉम्प्लेक्स सिस्टिम मध्ये असू शकतात. क्लस्टरिंग साठी आपल्याकडे एक वेगळे मॉड्यूल असेल जे किती वेगवेगळ्या श्रेणी किंवा उपश्रेणी किंवा क्लासशी संबंधित आहेत हे आपल्याला माहिती नसताना, क्लासचा चांगला सेट काय आहे हे ठरवण्यासाठी आपण क्लस्टरिंग करतो. आपल्याकडे वर्गीकरण मॉड्यूल असेल ज्याने क्लासचा सेट दिलेला आहे आणि टेस्ट डेटा दिलेला आहे तो वेगवेगळ्या मशीन लर्निंग अल्गोरिदमचा वापर करून कोणत्या वर्गाशी संबंधित आहे हे ठरवू शकतो.
आणि मग एक रीग्रेशन मॉड्यूल आहे जे वेगवेगळ्या चाचणी प्रकरणांवर आधारित तपासते की ते योग्यरित्या वर्गीकृत केले गेले आहे की नाही किंवा वर्गीकरण प्रत्यक्षात मागे गेले आहे की वर्गीकरणात काही त्रुटी आहेत. आणि शेवटी, हे सर्व भिन्न मॉड्यूल्स एकमेकांमध्ये परस्पर क्रिया करतात म्हणून हे विशिष्ट क्षेत्र जर तुम्ही वेगवेगळ्या बाजूंनी पाहिले तर तुम्हाला दाखवलेले वेगवेगळे मॉड्यूल दाखवत आहे. डेटा ट्रान्सफॉर्मेशन, स्ट्रक्चर प्रेडिक्शन, क्लस्टरिंग, वर्गीकरण, रीग्रेशन, त्यामुळे हे सर्व वेगवेगळे मॉड्यूल आहेत ज्यात तुम्ही तुमचा कोड क्लब केला आहे परंतु जेव्हा तुम्ही मॉड्यूल मध्ये इंटरकनेक्शन करता तेव्हा हे एकत्र एक सिस्टम बनते.
म्हणून, जेव्हा आपण मॉड्यूलरिटी बद्दल बोलतो तेव्हा एक म्हणजे ग्रुपिंग करणे, प्रोग्राम कोडला फाइल्स आणि डेटाच्या इंटरकनेक्ट शब्दार्थाने इंटरकनेक्शन सेट मध्ये विभाजित करणे. त्याच वेळी, काही इंटरकनेक्शन भाग आहेत. उदाहरणार्थ, जर तुम्ही या सर्व भिन्न सबकंपोनंटचा विचार केला तर त्यांचे कार्य मुळात वेगवेगळ्या मॉड्यूल्स मधील इंटरकनेक्शन वाचणे आहे आणि हे सामान्यत: कोणत्याही कॉम्प्लेक्स सिस्टिमचे मॉड्युलराइज्ड दृश्य असेल.
हे फक्त तुम्हाला एक झलक देण्यासाठी होते की सिस्टिममध्ये प्रत्यक्षात कोणत्या प्रकारची कॉम्प्लेक्सिटी समाविष्ट असेल आणि मॉड्युलरायझेशन यापैकी काही गुंतागुंत कशी कमी करू शकते. त्यामुळे तुम्ही चांगल्या प्रकारे समजू शकता की जर तुम्ही मूळ सिस्टिम बद्दल विचार केला तर आपण फक्त एक गोंधळ पाहिला, त्या तुलनेत जेव्हा तुम्ही प्रत्येक मॉड्यूल घेता तेव्हा ते हाताळणे खूप सोपे आहे आणि हे पुन्हा श्रेणीबद्ध पद्धतीने जाऊ शकते. मॉड्यूल पुन्हा छोट्या मॉड्यूल्समध्ये सबमॉड्युलराइज्ड केले जाऊ शकते आणि असेच.
आणि आपण त्यापैकी काही तत्त्वे पाहू. तर, टार्गेट सेट करण्यासाठी, मॉड्यूललायझेशनची काही विशिष्ट ओब्जेक्टिव आहेत. चला तर मग एक एक करून पाहू.
एक म्हणजे डिकंपोझिशन म्हणजे आपल्याला कोड फाईल्सचा संपूर्ण सेट द्यायचा आहे ज्यांना आपण मॉड्यूल्सच्या संदर्भात, संबंधित गटांच्या संदर्भात पद्धतशीर रीतीने व्यवस्थापित करू इच्छितो जेणेकरून पद्धतशीरपने याचा अर्थ काय आहे ते आपण फक्त एकत्र ठेवू. प्रोग्रामचे ते भाग, कोडचे ते भाग एका मॉड्यूल मध्ये बनवतात ज्यामध्ये काही प्रकारची चांगली डिफाइन फंक्शण्यालीटी असते. आपण फक्त आर्बीटरिली आहे जी आपण सिस्टिमला लहान मॉड्यूल्समध्ये, प्रत्येक मॉड्यूलला सब-मॉड्युलमध्ये विभागतो आणि असेच.
आपण ते पुन्हा तयार करण्यास सक्षम असले पाहिजे म्हणजे तुम्ही लहान मॉड्यूल्स घेऊ शकता आणि त्यांना एका मोठ्या मॉड्यूलमध्ये एकत्र ठेवू शकता. त्यामुळे प्रोग्रामच्या दोन किंवा अधिक भागात समान कार्यक्षमता असल्यास, आपल्याकडे एकच सब मॉड्यूल असू शकतो जो पुन्हा वापरला जाऊ शकतो, इतर मॉड्यूलमध्ये बनवला जाऊ शकतो आणि पुन्हा वापरण्यायोग्यता वाढवू शकतो. त्यामुळे तुमच्यापैकी अनेकांना परिचित असलेल्या पारंपरिक C प्रोग्रामिंगच्या संदर्भात जर तुम्हाला विचार करायचा असेल तर मॉड्युलॅरिटी लक्षणीयरीत्या रियुझेबिलिटी वाढवते.
तुम्हाला आढळेल की आपण अनेकदा स्टँडर्ड लायब्ररी वापरतो जसे तुम्हाला माहीत आहे की c स्टँडर्ड लायब्ररी वापरते ठीक आहे. आणि स्टँडर्ड लायब्ररीत तुम्ही काय करता? तुम्ही वेगवेगळे स्टँडर्ड लायब्ररी हेडर समाविष्ट केले आहेत तुम्ही म्हणता की आपल्याकडे stdio.
h आहे, आपल्याकडे # समाविष्ट आहे , आपल्याकडे #include आहे आणि असेच. आता या सर्व हेडर फाइल्स मध्ये फंक्शन हेडरचा एक सेट असणे आवश्यक आहे. कारण आपण c प्रोग्रामिंग बद्दल बोलत आहोत त्यामुळे कोणताही वर्ग नाही परंतु तरीही तुम्ही मॉड्यूलरिटीचा सुस्पष्ट वापर पाहू शकता, मॉड्यूलरिटीचा अतिशय व्यवस्थित वापर.
मग आपण काय करत आहोत? या सर्व भिन्न हेडर फाइल्स आपल्याकडे का असणे स्टँडर्ड आहे? कारण मला असे म्हणायचे आहे की दुसरा पर्याय काय असू शकतो, माझ्याकडे एक स्टँडर्ड लायब्ररी h मध्ये सर्व फंक्शन हेडर समाविष्ट आहेत.
परंतु आपण तसे करत नाही. तर आपण जे केले आहे, आपण एक विशिष्ट डिकंपोझिशन आणि कोम्पोजिबिलिटी केली आहे. म्हणून जेव्हा आपण stdio.
h बद्दल बोलतो तेव्हा आपण ते सर्व फंक्शन हेडर जसे की प्रिंट f हेडर, स्कॅन f हेडर, f प्रिंट f हेडर, f स्कॅन f हेडर आणि इतर काही प्रकारच्या इनपुट आऊटपुट यंत्रणेशी संबंधित असतात. परंतु जेव्हा आपल्याला वेगवेगळ्या गणिती क्रियांचा सामना करावा लागतो जसे की अँगल च्या टँजेन्ट ची गणना करणे, टॅन फंक्शन किंवा हाफ टॅन फंक्शन किंवा स्क्वेअर रूट फंक्शन, तेव्हा आपल्याकडे एक वेगळी हेडर फाइल असेल जी त्यांना एकत्र ठेवते. त्यामुळे हे सहजपणे दाखवून देईल की डिकंपोझिशन करताना, सर्व भिन्न स्टँडर्ड फंक्शन्सच्या सर्व भिन्न स्टँडर्ड हेडर फाइल्स ज्या तुम्हाला C प्रोग्रामरला प्रदान करायच्या आहेत, तुम्ही त्यांना ध्वज म्हणून प्रदान करत नाही.
तुम्ही त्यांचे कार्यक्षमतेने एकरूप होऊन डिकंपोझिशन करता, हे प्रत्यक्षात त्यांच्यात कधीच संवाद साधत नाहीत. प्रिंट f स्कॅन f शी संवाद साधत नाही, स्कॅन f, f प्रिंट f शी संवाद साधत नाही आणि नक्कीच rtan sin शी संवाद साधत नाही पण तरीही तुम्ही त्यांना कंसेप्च्युअली एकत्र ठेवता कारण त्यामुळे युजरला ते मॉड्यूल वापरणे खूप सोपे होते. त्यामुळे कोम्पोजिबिलिटी सुलभ होते, युजरने एक प्रोग्राम तयार केला पाहिजे ज्याचा तिला विचार करणे आवश्यक आहे की मी येथे एक io करत आहे का, नंतर मला stdio.
h समाविष्ट करणे आवश्यक आहे, मी मेमरी ऍलोकेशन आणि रीऍलोकेशन याच्याशी संबंधित काहीतरी करत आहे का, मला स्टँडर्ड lib. h वगैरे वापरायलाच हवे. हे मूलभूत प्रोग्रामिंगशी संबंधित फक्त एक साधे उदाहरण आहे जे दर्शविते की मॉड्यूलरिटी ही एक महत्त्वाची आवश्यकता आहे, हे चांगले डिकंपोझिशन, चांगली कोम्पोजिबिलिटी प्रदान करण्याच्या दृष्टीने चांगले आयोजन करण्याच्या दृष्टीने एक महत्त्वाचे साधन आहे.
आणि त्याचा परिणाम जेव्हा तुम्ही हे चांगले करू शकलात तेव्हा तुम्ही बनवलेले दुसरे ओब्जेक्टिव म्हणजेच मॉड्यूलर समजण्यायोग्यता. मी म्हटल्याप्रमाणे जर मला इनपुट आउटपुट करायचे असल्यास, मला फक्त stdio. h समाविष्ट करावे लागेल.
त्यामुळे ही समजूतदारता आहे जी मला समजते की त्या मॉड्युलचा एक अर्थपूर्ण अर्थ आहे जरी मी म्हटल्याप्रमाणे त्या मॉड्यूलचे वेगवेगळे कंपोनंट भिन्न फंक्शन्स त्यांच्यामध्ये इंटरऍक्ट करणार नाहीत परंतु एक कंसेप्च्युअल बाऊंड्री आहे जी म्हणते की सर्व इनपुट आउटपुट ऑपरेशन्स असतील. येथे त्यामुळे, मी मॉड्यूलला एक प्रकारचे युनिट समजू शकतो जे वापरण्यास सोपे करते आणि जे मला काही बदल करायचे असल्यास ते बदलणे देखील सोपे करते. चौथा उद्देश मॉड्यूलर कंटिन्युटी आहे.
मॉड्यूलर कंटिन्युटी थोडे अधिक सखोल आहे. कंटिन्युटीकाय करायचे आहे ते म्हणजे आपल्याला सिस्टिमला अशा मॉड्यूल्समध्ये विभाजित करायचे आहे जेणेकरून भविष्यात आपल्याला काही बदल करायचे असल्यास आणि बदल वेगवेगळ्या कारणांमुळे होऊ शकतात उदाहरणार्थ बदल हे साधे दोष निराकरणे असू शकतात त्यात कोड काही समस्या आहेत आणि मला ते दुरुस्त करावे लागेल, ते दुरुस्त करा. स्पेसिफिकेशनमध्ये बदल झाल्यामुळे बदल होऊ शकतात; बदल व्यवसाय प्रक्रियेतील बदलांमुळे होऊ शकतात आणि याप्रमाणे.
म्हणून मला असे वाटते की आपण अशा प्रकारे मॉड्यूल्स तयार केले पाहिजेत जेणेकरून जेव्हा काही बदल आवश्यक असतील तेव्हा ते बदल वेगवेगळ्या मॉड्यूल्समध्ये जाऊ नये, बदल एका मॉड्यूल पर्यंत मर्यादित असावा किंवा मॉड्यूल्सच्या अगदी लहान संख्येपर्यंत मर्यादित असावा. मॉड्युलरायझेशन खूप योग्य नाही, नंतर बदल वेगवेगळ्या मॉड्यूल्स मध्ये पसरतील. उदाहरणार्थ, जर मी math.
h त्रुटींचा सेट दोन वेगवेगळ्या मॉड्यूल्समध्ये विभाजित केला असेल किंवा मी math. h ला stdio. h सोबत जोडले असेल तर संख्यात्मक अल्गोरिदम मधील कोणताही बदल मॉड्यूल्स मध्ये पसरलेल्या वेगवेगळे त्रिकोणमितीय फंक्शन्स कंप्युट करेल.
त्यामुळे हे एक प्रकारे कमी होईल, हे कमी करेल सर्वात महत्वाचे म्हणजे साइड इफेक्ट कमी करणे जे एका मॉड्युलच्या बदलामुळे दुस-यावर परिणाम करतात आणि निश्चितपणे त्या उद्दिष्टाशी संबंधित मॉड्यूलर प्रोटेक्शन आहे जे म्हणतात की त्रुटी लोकेलाइज्ड केल्या पाहिजेत. मला त्रुटी आढळते म्हणा की मी शून्य त्रुटीने भागाकार केला तर मला math. h मध्ये स्थानिकीकरण केले पाहिजे.
जर मला मेमरी ऍलोकेशन अयशस्वी त्रुटी आढळली, तर ती memory. h आणि याप्रमाणेच मर्यादित असेल. तर ही ठराविक ओब्जेक्टिव आहेत जी कोडचे मॉड्युलरायझेशन करताना लक्षात ठेवली पाहिजेत.
परंतु तुम्हाला ज्या डिझाइनचा सामना करण्यासाठी देण्यात आला आहे त्याचे मॉड्युलरायझेशन करताना. आता जीवनात निश्चितच कोणतेही दुपारचे जेवण मोफत नसते त्यामुळे जेव्हा तुम्ही मॉड्युलरायझेशन मध्ये गुंतता तेव्हा हे ओब्जेक्टिव पूर्ण करण्याचा प्रयत्न करता तेव्हा तुम्हाला अनेकदा आव्हाने येतात. उदाहरणार्थ, सामान्य सिस्टिम पाहता, लहान मॉड्यूल्सच्या संदर्भात त्याचे डिकंपोझिशन करणे सहसा सोपे नसते, बर्याचदा त्यास सिस्टिमचा सखोल अभ्यास, डिझाइनचा अनुभव समजून घेणे आणि ऑब्जेक्ट मॉडेल्सच्या इतर एलिमेंट्सचा वापर करणे आवश्यक असते.
ऍब्स्ट्रॅक्ट संकल्पना काय आहेत. संभाव्य एनकेप्सुलेशन काय आहेत जरी काहीतरी अस्तित्वात असल्यास हायरार्की काय आहे आणि असेच. त्यामुळे हे नेहमीच सोपे, क्षुल्लक काम नसते.
हे फक्त तुम्हीच ठरवता की तुम्ही कोणत्या फाइल्स एका किंवा दुसर्या मॉड्यूलमध्ये ठेवू शकता असे नाही. वेगवेगळ्या फाइल्समध्ये आपण कोणती फंक्शन्स ठेवतो, हेडर फाइल्समध्ये तुम्ही कोणते हेडर ठेवता, वेगवेगळ्या फाइल्समध्ये तुम्ही कोणती क्लास डेफिनेशन ठेवता हे ठरवणे, हे सर्व मॉड्युलरायझेशन किती चांगले होत आहे हे ठरवण्यासाठी खोलवर जाते. आणि हे लक्षात ठेवा की जर मॉड्युलरायझेशन अनियंत्रित असेल तर बरेचदा ते प्रत्यक्षात अधिक विनाशकारी ठरते ते मॉड्यूलरायझेशन अजिबात न करण्यापेक्षा वाईट असते.
कारण तुम्ही ड्राइव्ह बाउंडेड आहात जे ऍब्स्ट्रॅक्शन आणि एन्कॅप्सुलेशनच्या डिझाइन बाऊंड्रीशी संरेखित नाहीत ज्यावर नेहमीच जोर दिला जातो. म्हणून मॉड्युलरायझेशनने सामान्य आणि इंटरकनेक्शन फंक्शणचे सिमॅटिक ग्रुपिंग केले पाहिजे. म्हणून कृपया हे मुद्दे लक्षात घ्या कारण ते सिमॅटिक ग्रुपिंगचे पालन करतात की अर्थानुसार ते समान असले पाहिजेत आणि ते इंटरकनेक्शन असले पाहिजेत आणि सामान्य आयटम सामान्य कार्यक्षमता आणि इंटरकनेक्शन फंक्शण कशाशी संबंधित असाव्यात.
इंटरकनेक्शन फंक्शणमुळे खात्री होईल की मी पुन्हा stdio. h च्या उदाहरणाकडे परत जाईन, printf फंक्शन बद्दल विचार करा म्हणजे ते आउटपुट आउटपुट फंक्शन आहे जे c प्रोग्रामर वापरतील. तर तुम्ही ते stdio.
h मध्ये ठेवले आहे. आता अशी कार्य आहेत जी तुमच्यापैकी काहींना काही कार्य माहित असतील जसे की काही कार्य जसे वाचन जे इनपुट आउटपुटसाठी देखील वापरले जाऊ शकते परंतु ते तपशीलाच्या वेगळ्या स्तरावर आहेत. ते बायनरी डेटा रीड राइट इत्यादीसारखे बरेच काही करतात.
आता जर तुम्ही printf एका मॉड्युलमध्ये, एका हेडर फाईलमध्ये टाकला आणि रीड राइट वेगळ्यामध्ये टाकला तर तुम्हाला असे दिसून येईल की या दोन मॉड्युलमध्ये तुमचा बर्याचदा इंटरकनेक्शन असेल, कारण printf स्वतः कधीच लागू होणार नाही. Printf नियमितपणे रीड राइट ऑपरेशन्स वापरेल, लेखन ऑपरेशन्स इतर प्रकारच्या इनपुट कार्यचा वापर करेल, इनपुट नावाची कार्य आहेत इत्यादी. fwrite वगैरे फंक्शन्स आहेत.
त्यामुळे कार्यक्षमतेची समानता आणि इंटरकनेक्शन हे एक प्रमुख साधन आहे ज्याद्वारे तुम्ही मॉड्युलरायझेशन केले पाहिजे. आव्हानांच्या बाबतीत मी जे ust ने आणखी काही सिस्टिम्सचे वर्णन करण्याचा प्रयत्न केला, तुम्ही डिस्ट्रीब्युटेड सिस्टिमचा विचार करू शकता ज्यामध्ये अनेक प्रोसेसर आहेत आणि तुमच्याकडे अनेक संदेश जात आहेत, हे प्रोसेसर आहेत, शेकडो विविध प्रकारचे संदेश आहेत. दुसरा प्रश्न असा आहे की आपण काय मॉड्यूलराइझ करावे.
तुम्ही मॉड्युलराइज केले पाहिजे आणि प्रत्येक मॉड्युल शक्य तितके स्वतंत्र असले पाहिजे म्हणून तुम्ही प्रत्येक मॉड्युल आवश्यक संदेश प्रकार त्या मॉड्यूलमध्ये टाकाल, तुम्ही ते करू शकता. परंतु जर तुम्ही असे केले तर बर्याचदा तुमचे स्ट्रक्चर खूपच खराब असेल कारण आता प्रत्येक मॉड्युलचे स्वतःचे मेसेज स्ट्रक्चर असल्याने ज्या युजरला या मेसेजला सामोरे जावे लागते ते कोणत्या मॉड्युलमध्ये कोणते स्ट्रक्चर अस्तित्वात आहे हे जाणून घेतल्याशिवाय त्यांचा सामना करू शकणार नाही. डॉक्युमेंटेशन कठीण होईल; ते राखणे खरोखर कठीण होईल.
त्यामुळे काही पैलू आहेत जसे की जेव्हा तुम्ही ते सर्व एकत्र ठेवता तेव्हा नक्कीच तुम्ही चांगल्या एनकेप्सुलेशनचे पालन करत आहात कारण तुम्ही म्हणाला होता की या प्रकारचा संदेश या मॉड्यूलशी संबंधित आहे. मला ते आत ठेवू द्या, म्हणजे तुम्ही सर्वकाही लपवत आहात. परंतु खूप जास्त लपविल्याने प्रत्यक्षात मॉड्युलरायझेशनवर अधिक परिणाम होऊ शकतो, त्याचा उलट परिणाम होऊ शकतो कारण आता तुम्हाला माहित नाही की कोणते विविध संदेश जाणे आवश्यक आहे, त्यांचे स्वरूप काय आहेत इत्यादी.
त्यामुळे तुम्हाला बॅलन्स स्ट्राइक करणे आवश्यक आहे. वेगवेगळे मॉड्युलरायझेशन करून बॅलन्स स्ट्राइक करणे आवश्यक आहे जेथे तुम्ही ते चांगल्या प्रकारे ओळखू शकता कारण तेथे अनेक प्रकारचे संदेश आहेत, मग एक मॉड्यूल का तयार करू नये जे प्रत्यक्षात संदेशांशी संबंधित असेल आणि त्यांना कोणत्या प्रकारच्या संदेशांची आवश्यकता आहे यावर आधारित वेगवेगळे मॉड्यूल वापरू शकतील असे इंटरफेस प्रदान करा. आपण यापैकी आणखी काही पाहू.
परंतु संभाव्य आव्हाने कोणती असू शकतात याची ही फक्त एक झलक आहे. या पार्श्वभूमीवर मॉड्युलरायझेशनची ओब्जेक्टिव लक्षात ठेवण्यासाठी आपण अनेकदा इंटेलिजेंट मॉड्युलरायझेशन बद्दल बोललो, ते म्हणजे हे काही थंब रुल आहेत किंवा काही मूलभूत मार्गदर्शक तत्त्वे आहेत जी ओब्जेक्टिव अधिक चांगल्या प्रकारे साध्य करण्यासाठी तुम्ही पाळू शकता. म्हणूनच मी नुकतेच त्यातील महत्त्वाचे शब्द हायलाइट केले आहेत, मला माफ करा हे बदलले आहे.
लॉजिकली संबंधित अॅब्स्ट्रॅक्शन ग्रुपिंग केलेले हायलाइट कीवर्ड. तुमच्याकडे सिस्टिमवर अॅब्स्ट्रॅक्शन आधीपासूनच आहे, त्यामुळे एका मॉड्यूलमध्ये तुम्ही सामान्यत: आता नैसर्गिकरित्या तुम्ही वेगळ्या मॉड्यूलमध्ये ठेवलेल्या प्रत्येक अॅब्स्ट्रॅक्शन मध्ये एक टोक असावे. हे तुम्हाला बरेच फ्रॅक्चर केलेले मॉड्यूलरायझेशन देऊ शकते ज्यामध्ये बरेच इंटरकनेक्शन असतील त्यामुळे तुमचे मॉड्यूल सोपे असतील परंतु तुमच्याकडे बरेच इंटरकनेक्शन असतील, तुम्हाला फक्त मशीन लर्निंग सिस्टिममध्ये दाखवलेले उदाहरण आठवते की इंटरकनेक्शनचा भाग देखील कॉम्प्लेक्सिटी असावी.
त्यामुळे प्रत्येक अॅबस्ट्रॅक्शन वेगळ्या मॉड्यूलमध्ये ठेवण्याऐवजी तुम्ही त्यांना लॉजिकली संबंधित अॅबस्ट्रॅक्शन मध्ये ग्रुपिंग करण्याचा प्रयत्न कराल. त्यामुळे इनपुट आउटपुट ऑपरेशन्सच्या अॅबस्ट्रॅक्शनने एका मॉड्यूलकडे नेले पाहिजे, मॅथेमॅटिकल मॉडेलिंगचे अॅबस्ट्रॅक्शन दुसऱ्या मॉड्यूलकडे नेले पाहिजे, सिस्टिमशी संबंधित ऑपरेशन्सच्या अॅबस्ट्रॅक्शनने तुम्हाला stdlib. h आणि असेच काही दिले पाहिजे.
आणि जसे तुम्ही तसे करता तेव्हा तुम्ही जे साध्य करण्याचा प्रयत्न करता ते म्हणजे मॉड्यूल्स मधील डिपेंडेंसि कमी करणे. त्यामुळे हे आता स्पष्ट झाले पाहिजे की जर मी लॉजिकल अॅब्स्ट्रॅक्शन्सचे मॉड्युलमध्ये लॉजिकल ग्रुप केले तर निश्चितपणे मला मॉड्युलमध्ये खूप कमी जावे लागेल जेव्हा मी केवळ मॉड्युल ओलांडून जातो तेव्हाच मला फंक्शण्यालीटीची हाय लेव्हल गाठायची असते. आणि या दोन्ही लॉजिकल ग्रुपिंग्ज आणि मॉड्युल मधील डिपेंडेंसि कमी केल्याने प्रत्येक मॉड्यूल सोपे होईल.
समजून घेण्यास पुरेसे आहे आणि ती एक प्रमुख कल्पना असेल साधेपणा ही मॉड्युलरायझेशनची मुख्य कल्पना असावी. कारण लक्षात ठेवा की आपण मॉड्युलरायझेशन का करत आहोत. कारण आपल्याला कॉम्प्लेक्सिटी समाविष्ट करायची आहे.
क्लिष्टता खूप जास्त आहे आणि आपण या सर्व गोष्टी सोप्या बनवण्यासाठी करत आहोत त्या संकल्पना, प्रॉब्लम डोमेन च्या शब्दसंग्रहाचा फायदा घेऊन मी आधीच तयार केलेल्या ऍब्स्ट्रॅक्शनचा फायदा घेऊन, संभाव्य एनकेप्सुलेशनचा फायदा घेऊन त्याकडे परत जाईन जे आपल्याकडे आहे. आणि शेवटी, मॉड्यूल पूर्ण असणे आवश्यक आहे. इंटेलिजेंट मॉड्युलरायझेशन तत्त्वांचे अंतिम परंतु ओव्हरराइड म्हणजे बदल करणे सोपे आहे.
आपण जेव्हा एखादी रचना करतो तेव्हा आपण कोड आयोजित करणारी अंमलबजावणी सुरू करतो तेव्हा आपल्याला खात्री असते की आपण योग्य काम करत आहोत. परंतु अनुभव दर्शवतो की विविध मर्यादांसाठी सिस्टिम आणि व्यवसाय परिस्थितीतील बदलाचे मानवी मन हे सिस्टम डिझाइन आणि अंमलबजावणीच्या सॉफ्टवेअर डेव्हलपमेंटचे एक अपरिहार्य वास्तव आहे. त्यामुळे बदलाची सहजता नेहमी लक्षात ठेवली पाहिजे की आपण मॉड्युल पुरेशा हुशारीने व्यवस्थित केले पाहिजे, जेणेकरून एका मॉड्युल मधील काही बदलांचा इतर मॉड्युलवर कमीत कमी प्रभाव पडेल.
तर, या तत्त्वांसह आपण नियमितपणे पुढे जाऊ आणि वेगवेगळ्या मॉड्यूल्सकडे लक्ष देऊ. आधीच्या उदाहरणांचे काही संदर्भ आहेत, हायपोटोनिक बागकाम सिस्टिम, म्हणून समजा आपल्याला एक ऑटोमेशन सिस्टिम तयार करायची आहे ज्याची आपण चर्चा सुरू केली आणि निश्चितच काही प्रमुख ऍब्स्ट्रॅक्शन. आपण पाहिले आहे की यात वाढणारी वनस्पती समाविष्टीत आहे विविध प्रकारच्या वनस्पती वाढवण्यासाठी सिस्टिमद्वारे विविध धोरणे लागू करणे.
इंटरफेस युजर म्हणून ही काही प्रमुख अॅब्स्ट्रॅक्शन्स आहेत जी सिस्टम अॅब्स्ट्रॅक्शनच्या ऍनालिसिस ने तुमच्याकडे आधीच असतील. म्हणून मी वाढत्या योजनेसाठी मॉड्यूल्स तयार करणे खूप तर्कसंगत आहे, म्हणून वाढत्या योजनेच्या मॉड्यूलमध्ये, तुमच्याकडे फळांसाठी वाढणारी योजना, धान्यांसाठी वाढणारी योजना इत्यादी असू शकतात. हे सर्व एकत्र ठेवणे शक्यतो चांगले होईल आणि हेच इंटरकनेक्शन अॅबस्ट्रॅक्शन्सचे एकत्रीकरण करण्याशी संबंधित असेल.
हे साधेपणाशी संबंधित असेल, हे सुनिश्चित करेल की तुम्हाला बदलणे खूप सोपे आहे कारण फळांच्या वाढीच्या योजनेत बदल केल्यास सामान्य वाढीच्या योजनांच्या धोरणांवर याप्रमाणेच परिणाम होईल. दुसरीकडे जर तुमच्याकडे असलेल्या सर्व इंटरफेस युजर फंक्शनॅलिटीज एका वेगळ्या मॉड्यूलमध्ये एकत्र ठेवणे नक्कीच चांगले होईल. तर, यासह आपण जे पाहिले ते म्हणजे ऑब्जेक्ट मॉडेल्ससाठी एक प्रमुख एलिमेंट म्हणून मॉड्यूलरिटीचा परिचय आपण पाहिला आहे.
आपण येथे थांबू आणि पुढे हायरार्की घेऊ.
