श्रेणीबद्ध विघटन

तुम्ही तुमच्या अर्जासाठी लेखन वर्ग लगेच सुरू करू नये. प्रथम ते डिझाइन करणे आवश्यक आहे. डिझाइनचा शेवट विचारशील आर्किटेक्चरसह झाला पाहिजे. आणि हे आर्किटेक्चर मिळविण्यासाठी, आपल्याला सिस्टममध्ये सातत्याने विघटन करणे आवश्यक आहे.

विघटन पदानुक्रमानुसार केले जाणे आवश्यक आहे - प्रथम, सिस्टम मोठ्या कार्यात्मक मॉड्यूल्स / उपप्रणालींमध्ये विभागली गेली आहे जी त्याच्या ऑपरेशनचे सर्वात सामान्य स्वरूपात वर्णन करते. नंतर परिणामी मॉड्यूल्सचे अधिक तपशीलवार विश्लेषण केले जाते आणि सबमॉड्यूल किंवा ऑब्जेक्ट्समध्ये विभागले जातात.

ऑब्जेक्ट्स निवडण्यापूर्वी, सिस्टमला मूलभूत सिमेंटिक ब्लॉक्समध्ये विभाजित करा, कमीतकमी मानसिकदृष्ट्या. लहान ऍप्लिकेशन्समध्ये, हे करणे सहसा खूप सोपे असते: पदानुक्रमाचे दोन स्तर पुरेसे आहेत, कारण सिस्टम प्रथम उपप्रणाली / पॅकेजेसमध्ये विभागली गेली आहे आणि पॅकेजेस वर्गांमध्ये विभागली गेली आहेत.

श्रेणीबद्ध विघटन

ही कल्पना दिसते तितकी क्षुल्लक नाही. उदाहरणार्थ, मॉडेल-व्ह्यू-कंट्रोलर (MVC) सारख्या सामान्य "आर्किटेक्चरल पॅटर्न" चे सार काय आहे?

हे सर्व व्यवसाय तर्कशास्त्र पासून सादरीकरण वेगळे करण्याबद्दल आहे . प्रथम, कोणताही वापरकर्ता अनुप्रयोग दोन मॉड्यूलमध्ये विभागलेला आहे - एक व्यवसाय तर्कशास्त्र स्वतः लागू करण्यासाठी जबाबदार आहे (मॉडेल), आणि दुसरा वापरकर्त्याशी संवाद साधण्यासाठी जबाबदार आहे (वापरकर्ता इंटरफेस किंवा दृश्य).

मग असे दिसून आले की मॉड्यूल्सने कसा तरी संवाद साधला पाहिजे, यासाठी ते एक नियंत्रक जोडतात, ज्याचे कार्य मॉड्यूल्सचे परस्परसंवाद व्यवस्थापित करणे आहे. तसेच MVC च्या मोबाइल (क्लासिक) आवृत्तीमध्ये, निरीक्षक पॅटर्न त्यात जोडला गेला आहे जेणेकरून दृश्य मॉडेलमधून इव्हेंट प्राप्त करू शकेल आणि रिअल टाइममध्ये प्रदर्शित डेटा बदलू शकेल.

सर्वात मोठ्या घटकांमध्ये सिस्टमच्या प्रथम विभागणीच्या परिणामी प्राप्त झालेले ठराविक उच्च-स्तरीय मॉड्यूल्स तंतोतंत आहेत:

  • व्यवसाय तर्क;
  • वापरकर्ता इंटरफेस;
  • डेटाबेस;
  • संदेश प्रणाली;
  • ऑब्जेक्ट कंटेनर.

प्रथम विभाजन सहसा संपूर्ण अनुप्रयोगास 2-7 (जास्तीत जास्त 10 भाग) मध्ये विभाजित करते. जर आपण ते अधिक भागांमध्ये विभाजित केले तर त्यांना गटबद्ध करण्याची इच्छा असेल आणि आम्हाला पुन्हा 2-7 शीर्ष-स्तरीय मॉड्यूल मिळतील.

कार्यात्मक विघटन

मॉड्यूल्स / उपप्रणालींमध्ये विभागणी प्रणाली सोडवलेल्या कार्यांच्या आधारे उत्तम प्रकारे केली जाते . मुख्य कार्य त्याच्या घटक उपकार्यांमध्ये विभागले गेले आहे, जे स्वतंत्रपणे स्वतंत्रपणे सोडवता/करता येते.

प्रत्येक मॉड्यूल काही सबटास्क सोडवण्यासाठी जबाबदार असले पाहिजे आणि त्याचे संबंधित कार्य पार पाडले पाहिजे . कार्यात्मक उद्देशाव्यतिरिक्त, मॉड्यूलला त्याचे कार्य करण्यासाठी आवश्यक असलेल्या डेटाच्या संचाद्वारे देखील वैशिष्ट्यीकृत केले जाते, म्हणजे:

मॉड्यूल = फंक्शन + डेटा कार्यान्वित करण्यासाठी आवश्यक आहे.

जर मॉड्यूल्समध्ये विघटन योग्यरित्या केले गेले असेल, तर इतर मॉड्यूल्सशी संवाद (इतर फंक्शन्ससाठी जबाबदार) कमीतकमी असेल. हे असू शकते, परंतु त्याची अनुपस्थिती तुमच्या मॉड्यूलसाठी गंभीर असू नये.

मॉड्यूल हा कोडचा अनियंत्रित तुकडा नाही, परंतु एक स्वतंत्र कार्यात्मक अर्थपूर्ण आणि संपूर्ण प्रोग्राम युनिट (उपप्रोग्राम) जो विशिष्ट कार्यासाठी उपाय प्रदान करतो आणि आदर्शपणे, स्वतंत्रपणे किंवा दुसर्या वातावरणात कार्य करू शकतो आणि पुन्हा वापरला जाऊ शकतो. मॉड्यूल एक प्रकारचा "वर्तणूक आणि विकासामध्ये सापेक्ष स्वातंत्र्य करण्यास सक्षम अखंडता" असावा. (क्रिस्टोफर अलेक्झांडर)

अशा प्रकारे, सक्षम विघटन सर्व प्रथम, सिस्टम फंक्शन्सच्या विश्लेषणावर आणि ही कार्ये करण्यासाठी आवश्यक डेटावर आधारित आहे. या प्रकरणात फंक्शन्स क्लास फंक्शन्स आणि मॉड्यूल नाहीत, कारण ते ऑब्जेक्ट नाहीत. जर तुमच्याकडे मॉड्यूलमध्ये फक्त दोन वर्ग असतील, तर तुम्ही ते जास्त केले आहे.

मजबूत आणि कमकुवत कनेक्टिव्हिटी

मॉड्यूलरायझेशनसह ते जास्त न करणे फार महत्वाचे आहे. जर तुम्ही नवशिक्याला मोनोलिथिक स्प्रिंग ऍप्लिकेशन दिले आणि त्याला मॉड्यूलमध्ये तोडण्यास सांगितले, तर तो प्रत्येक स्प्रिंग बीन वेगळ्या मॉड्यूलमध्ये काढेल आणि त्याचे काम पूर्ण झाले आहे असे समजेल. पण ते नाही.

विघटनाच्या गुणवत्तेचा मुख्य निकष म्हणजे मॉड्यूल्स त्यांचे कार्य सोडवण्यावर कसे केंद्रित आहेत आणि स्वतंत्र आहेत.

हे सहसा खालील प्रमाणे तयार केले जाते: "विघटनाच्या परिणामी प्राप्त झालेले मॉड्यूल जास्तीत जास्त अंतर्गत संयुग्मित असावेत (उच्च अंतर्गत एकसंध) आणि कमीतकमी एकमेकांशी जोडलेले असावे (कमी बाह्य जोडणी).

उच्च समन्वय, उच्च समन्वय किंवा मॉड्यूलमधील "एकसंध", हे सूचित करते की मॉड्यूल एका संकुचित समस्येचे निराकरण करण्यावर केंद्रित आहे, आणि विषम कार्ये किंवा असंबंधित जबाबदाऱ्या पार पाडण्यात गुंतलेले नाही.

सामंजस्य मॉड्यूलद्वारे केलेली कार्ये एकमेकांशी संबंधित आहेत त्या प्रमाणात वैशिष्ट्यीकृत करते.

उच्च समन्वयाचा परिणाम म्हणजे सिंगल रिस्पॉन्सिबिलिटी प्रिन्सिपल - पाच सॉलिड तत्त्वांपैकी पहिले , ज्यानुसार कोणत्याही ऑब्जेक्ट/मॉड्यूलची एकच जबाबदारी असली पाहिजे आणि ती बदलण्यासाठी एकापेक्षा जास्त कारणे नसावीत.

लो कपलिंग , लूज कपलिंग , म्हणजे ज्या मॉड्यूल्समध्ये सिस्टीमची विभागणी केली आहे ते शक्य असल्यास स्वतंत्र किंवा सैलपणे एकमेकांशी जोडलेले असावेत. ते संवाद साधण्यास सक्षम असले पाहिजेत, परंतु त्याच वेळी एकमेकांबद्दल शक्य तितके कमी जाणून घ्या.

प्रत्येक मॉड्यूलला इतर मॉड्यूल कसे कार्य करते, ते कोणत्या भाषेत लिहिले आहे आणि ते कसे कार्य करते हे माहित असणे आवश्यक नाही. बहुतेकदा, अशा मॉड्यूल्सची परस्परसंवाद आयोजित करण्यासाठी, एक विशिष्ट कंटेनर वापरला जातो, ज्यामध्ये हे मॉड्यूल लोड केले जातात.

योग्य डिझाइनसह, तुम्ही एक मॉड्यूल बदलल्यास, तुम्हाला इतर संपादित करावे लागणार नाहीत किंवा हे बदल कमी असतील. कपलिंग जितके सैल होईल तितके प्रोग्राम लिहिणे/समजणे/विस्तारित करणे/दुरुस्ती करणे सोपे आहे.

असे मानले जाते की चांगल्या प्रकारे डिझाइन केलेल्या मॉड्यूलमध्ये खालील गुणधर्म असावेत:

  • कार्यात्मक अखंडता आणि पूर्णता - प्रत्येक मॉड्यूल एक फंक्शन लागू करते, परंतु ते उत्तम आणि पूर्णपणे अंमलात आणते, मॉड्यूल स्वतंत्रपणे त्याचे कार्य अंमलात आणण्यासाठी संपूर्ण ऑपरेशन्स करते.
  • एक इनपुट आणि एक आउटपुट - इनपुटवर, प्रोग्राम मॉड्यूल प्रारंभिक डेटाचा एक विशिष्ट संच प्राप्त करतो, अर्थपूर्ण प्रक्रिया करतो आणि परिणाम डेटाचा एक संच देतो, म्हणजे, मानक IPO तत्त्व लागू केले जाते - इनपुट -\u003e प्रक्रिया -\u003e आउटपुट
  • तार्किक स्वातंत्र्य - प्रोग्राम मॉड्यूलच्या कार्याचा परिणाम केवळ प्रारंभिक डेटावर अवलंबून असतो, परंतु इतर मॉड्यूलच्या कार्यावर अवलंबून नाही.
  • इतर मॉड्यूल्ससह कमकुवत माहिती दुवे - मॉड्यूल्समधील माहितीची देवाणघेवाण शक्य असल्यास कमी केली पाहिजे.

मोड्यूल्सची कनेक्टिव्हिटी आणखी कशी कमी करावी हे समजणे नवशिक्यासाठी खूप कठीण आहे. अंशतः हे ज्ञान अनुभवासह येते, अंशतः - स्मार्ट पुस्तके वाचल्यानंतर. परंतु विद्यमान अनुप्रयोगांच्या आर्किटेक्चरचे विश्लेषण करणे सर्वोत्तम आहे.

वारसा ऐवजी रचना

सक्षम विघटन ही एक प्रकारची कला आहे आणि बहुतेक प्रोग्रामरसाठी एक कठीण काम आहे. येथे साधेपणा फसवा आहे, आणि चुका महाग आहेत.

असे घडते की समर्पित मॉड्यूल एकमेकांशी जोरदारपणे जोडलेले आहेत आणि ते स्वतंत्रपणे विकसित केले जाऊ शकत नाहीत. किंवा त्यापैकी प्रत्येक कोणत्या कार्यासाठी जबाबदार आहे हे स्पष्ट नाही. जर तुम्हाला अशीच समस्या आली असेल, तर बहुधा मॉड्यूल्समध्ये विभाजन चुकीच्या पद्धतीने केले गेले असेल.

प्रत्येक मॉड्यूल कोणती भूमिका बजावते हे नेहमी स्पष्ट असले पाहिजे . मोड्यूल्स स्वतंत्र आणि मौल्यवान सबरूटीन असतील तर ते विघटन योग्यरित्या केले गेले आहे हा सर्वात विश्वासार्ह निकष आहे ज्याचा वापर उर्वरित अनुप्रयोगापासून अलग ठेवला जाऊ शकतो (आणि म्हणून पुन्हा वापरला जाऊ शकतो).

सिस्टमचे विघटन करताना, स्वतःला प्रश्न विचारून तिची गुणवत्ता तपासणे इष्ट आहे: "प्रत्येक मॉड्यूल कोणते कार्य करते?", "मॉड्यूलची चाचणी घेणे किती सोपे आहे?", "मॉड्यूल स्वतः वापरणे शक्य आहे का? किंवा दुसर्‍या वातावरणात?" इतरांवर परिणाम करतात?"

तुम्हाला मॉड्यूल्स शक्य तितक्या स्वायत्त ठेवण्याचा प्रयत्न करणे आवश्यक आहे . आधी सांगितल्याप्रमाणे, योग्य विघटनासाठी हे एक प्रमुख मापदंड आहे . म्हणून, हे अशा प्रकारे केले पाहिजे की मॉड्यूल्स सुरुवातीला एकमेकांवर कमकुवतपणे अवलंबून असतात. जर तुम्ही यशस्वी झालात तर तुम्ही महान आहात.

जर नाही, तर येथे सर्व काही गमावले नाही. अशी अनेक विशेष तंत्रे आणि नमुने आहेत जी तुम्हाला उपप्रणालींमधील दुवे आणखी कमी आणि कमकुवत करण्याची परवानगी देतात. उदाहरणार्थ, MVC च्या बाबतीत, निरीक्षक नमुना या उद्देशासाठी वापरला गेला होता, परंतु इतर उपाय शक्य आहेत.

असे म्हटले जाऊ शकते की डीकपलिंगची तंत्रे मुख्य "आर्किटेक्टचे टूलकिट" बनवतात. केवळ हे समजून घेणे आवश्यक आहे की आपण सर्व उपप्रणालींबद्दल बोलत आहोत आणि पदानुक्रमाच्या सर्व स्तरांवर कनेक्शन कमकुवत करणे आवश्यक आहे , म्हणजे केवळ वर्गांमध्येच नाही तर प्रत्येक श्रेणीबद्ध स्तरावरील मॉड्यूल्समध्ये देखील.