🕧 🏡 👨‍⚖️ शुद्ध PHP वास्तुकला। इसे कैसे मापें और नियंत्रित करें? 🤖 🤹🏻 🎒

प्रस्तावना

जैसा कि आप पहले ही नाम से समझ गए हैं, यहां मैं सबसे "उच्च" - शुद्ध वास्तुकला के बारे में बात करने जा रहा हूं। और इस पूरी कहानी के विकास के लिए प्रेरणा रॉबर्ट मार्टिन की पुस्तक "शुद्ध वास्तुकला" थी। अगर मैंने इसे अभी तक नहीं पढ़ा है, तो मैं इसकी सिफारिश करने की हिम्मत करता हूं! लेखक कई महत्वपूर्ण विषयों का खुलासा करता है, सक्रिय रूप से अपने समृद्ध जीवन के अनुभव (निश्चित रूप से एक पेशेवर क्षेत्र से) और उसके आधार पर किए गए निष्कर्षों को साझा करता है, कभी-कभी कहानी के अध्यायों में भी बुनता है कि कैसे हमारे पिता और दादाओं ने मास्टर-हेड (केवल और केवल नहीं) 60, 70, 80 के दशक में वापस, और यहां तक कि 90 के दशक के दाने, जैसे अनाज के दाने, हर कोई SOLID के पसंदीदा सिद्धांतों और घटकों की दुनिया में उनके एनालॉग एकत्र किए गए थे, और उन्होंने पिछली आधी सदी में क्या सीखा। पुस्तक को पढ़ने की प्रक्रिया में, सॉफ्टवेयर विकास उद्योग की विकास रेखा अच्छी तरह से पता लगाया जाता है, लड़कों के साथ व्यवहार करने वाली विशिष्ट समस्याएं,और उन्हें हल करने के लिए तरीके।

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

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

सुविधा के लिए, लेख को 2 भागों में विभाजित किया गया है।

सबसे पहले मैं उन प्रमुख विचारों के बारे में बात करूंगा जो मेरे सिर में इस पूरी चीज को स्वचालित करने की इच्छा उत्पन्न करते हैं, क्या हम प्रोग्रामर हैं या अंत में कौन हैं? यहां मैं लेखक से बहुत कुछ उद्धृत करूंगा, साथ ही साथ पुस्तक के विभिन्न अध्यायों से सक्रिय रूप से अर्क और चित्र भी डालूंगा।

दूसरा भाग, लगभग पूरी तरह से, उस उपकरण का वर्णन करने के लिए समर्पित होगा जो अपनी क्षमताओं और चरण-दर-चरण मार्गदर्शन का खुलासा करता है।

यदि आप अपने आप को उन लोगों की श्रेणी मानते हैं, जो आपके दिल के बहुत करीब हैं, तो मैं आपको सलाह देता हूं कि आप आफ्टरवर्ड से पढ़ना शुरू करें ।

भाग 1

सॉफ्टवेयर आर्किटेक्चर क्या है?

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

वास्तुकला का उद्देश्य क्या है?

केवल एक ही उत्तर है:

सॉफ्टवेयर आर्किटेक्चर का लक्ष्य सिस्टम बनाने और बनाए रखने के लिए आवश्यक मानव श्रम को कम करना है।

थोड़ा परिचयात्मक ।।

कई परियोजनाएँ कहाँ से शुरू होती हैं?

"हम बाद में ऑर्डर को बहाल करने में सक्षम होंगे, हम केवल बाजार में प्रवेश करेंगे!"
नतीजतन, आदेश बहाल नहीं किया गया है, क्योंकि बाजार में प्रतिस्पर्धा का दबाव कभी भी कम नहीं होता है।

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

सॉफ्टवेयर उत्पादों के दो मूल्य

व्यवहार (कुछ जरूरी लेकिन हमेशा महत्वपूर्ण नहीं)
वास्तुकला (कुछ महत्वपूर्ण, लेकिन हमेशा जरूरी नहीं)

कई अक्सर पहले में डूब जाते हैं, और दूसरे की पूरी तरह से उपेक्षा करते हैं।

प्रकार: "क्यों वास्तुकला पर अच्छी तरह से सोचने में समय बर्बाद करना, मुख्य बात यह है कि यह सही ढंग से काम करता है!" ।

लेकिन वे एक महत्वपूर्ण बिंदु को याद करते हैं: "यदि एक ठीक से काम करने वाला कार्यक्रम इसे बदलने की संभावना नहीं देता है, तो यह आवश्यकताओं को बदलने पर सही ढंग से काम करना बंद कर देगा, और वे इसे सही ढंग से काम करने में सक्षम नहीं होंगे। यानी कार्यक्रम बेकार हो जाएगा।

यदि प्रोग्राम सही ढंग से काम नहीं करता है, लेकिन आसानी से बदलने के लिए उत्तरदायी है, तो वे इसे सही ढंग से काम करने में सक्षम होंगे और आवश्यकताओं में बदलाव के बाद अपने प्रदर्शन को बनाए रखेंगे। यही है, कार्यक्रम हमेशा उपयोगी रहेगा। ”

मुझे यह कथन पसंद आया:"यदि आपको लगता है कि अच्छी वास्तुकला महंगी है, तो खराब वास्तुकला का प्रयास करें।" (ब्रायन फूटे और जोसेफ योडर)

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

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

आप SOLID के साथ क्यों आए और यह अकेले पर्याप्त क्यों नहीं है?

हम सभी शायद SOLID के सिद्धांतों को जानते हैं।

उनका लक्ष्य मध्य स्तरीय सॉफ्टवेयर संरचनाएं बनाना है:

परिवर्तन का सहिष्णु;
सरल और समझने योग्य;
कई सॉफ्टवेयर सिस्टम में उपयोग किए जा सकने वाले घटकों के लिए आधार तैयार करें।

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

मैं इन विषयों पर बहुत सतही रूप से स्पर्श करूंगा, और अधिक विवरण पुस्तक में मिल सकते हैं। चलो चलते हैं!

घटकों और उसके निर्धारित सिद्धांतों की कनेक्टिविटी

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

REP: पुन : उपयोग / रिलीज समतुल्यता सिद्धांत - पुन: उपयोग और रिलीज के समतुल्यता का सिद्धांत।

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

एक घटक में संयुक्त कक्षाएं और मॉड्यूल एक साथ जारी किए जाने चाहिए।

CCP: सामान्य समापन सिद्धांत - सुसंगत परिवर्तन का सिद्धांत।
यह एसआरपी (एकल जिम्मेदारी) घटकों के लिए rephrased का सिद्धांत है।

समान कारणों से और एक ही समय में बदलने वाली कक्षाओं को एक घटक में शामिल किया जाना चाहिए। विभिन्न घटकों में ऐसी कक्षाएं शामिल होनी चाहिए जो अलग-अलग समय पर और विभिन्न कारणों से बदलती हैं।

सीआरपी: सामान्य पुन : उपयोग सिद्धांत - साझा पुन: उपयोग का सिद्धांत।
यह सिद्धांत आईएसपी (इंटरफ़ेस अलगाव) के समान है।

घटक उपयोगकर्ताओं को इस बात पर निर्भर करने के लिए मजबूर न करें कि उन्हें क्या ज़रूरत नहीं है।

सिद्धांत इंगित करता है कि कक्षाएं जो निकट से संबंधित नहीं हैं उन्हें एक घटक में शामिल नहीं किया जाना चाहिए।

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

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

घटक संगतता

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

एडीपी: एसाइक्लिक डिपेंडेंसी सिद्धांत - निर्भरता की अम्लीयता का सिद्धांत।
घटक निर्भरता ग्राफ में छोरों की अनुमति नहीं है!

ग्राफ पर प्रदर्शित किसी भी घटक से, आप निर्भरता की दिशा को इंगित करने वाले तीरों के साथ आगे बढ़ना शुरू करते हैं, आप मूल बिंदु पर वापस जाने में सक्षम नहीं होंगे। यह एक एसाइक्लिक ओरिएंटेड ग्राफ (DAG - डायरेक्टेड एसाइक्लिक ग्राफ) है।

इस छवि में, हमारे पास एक चक्र के रूप में अग्रणी निर्भरता है। परिणामस्वरूप चक्रीय निर्भरता हमेशा टूट सकती है।

चक्रीय निर्भरता को तोड़ने के लिए तरीके

1. डीआईपी (निर्भरता उलटा सिद्धांत) लागू करके

2. नए घटक का परिचय

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

टॉप-डाउन डिज़ाइन, या इसकी अव्यवहारिकता

“घटक संरचना को ऊपर से नीचे तक डिज़ाइन नहीं किया जा सकता है। जैसे ही वे सिस्टम को डिजाइन करना शुरू करते हैं, यह निष्कर्ष तुरंत नहीं पहुंचता है, लेकिन यह अनिवार्य रूप से सिस्टम के विकास और परिवर्तन के साथ होता है।

एक बड़े ब्लॉक आरेख को ध्यान में रखते हुए, जैसे कि घटक निर्भरता की संरचना, हम मानते हैं कि घटकों को किसी न किसी तरह से सिस्टम के कार्यों का प्रतिनिधित्व करना चाहिए। लेकिन वास्तव में, यह घटक निर्भरता आरेखों का एक अनिवार्य विशेषता नहीं है।

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

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

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

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

अरे, आप अभी भी यहाँ हैं? यार, यह महत्वपूर्ण है, आपको कम से कम यह कहने की ज़रूरत है कि अगले भाग के अर्थ में प्रवेश करने के लिए, तुल्ज़ा का उपयोग करने पर एक कच्चा ट्यूटोरियल होगा।

एसडीपी: स्थिर निर्भरता सिद्धांत - स्थिर निर्भरता का सिद्धांत।
निर्भरता को स्थिरता की ओर निर्देशित किया जाना चाहिए!

"स्थिरता" से क्या अभिप्राय है? एक किनारे खड़े सिक्के की कल्पना करो। क्या उसकी स्थिति स्थिर है? सबसे अधिक संभावना है कि आप "नहीं" का जवाब देंगे। हालांकि, यदि आप इसे कंपन और हवा के झोंके से बचाते हैं, तो यह इस स्थिति में मनमाने ढंग से लंबे समय तक बना रह सकता है। यही है, स्थिरता परिवर्तन की आवृत्ति से सीधे संबंधित नहीं है। सिक्का नहीं बदलता है, लेकिन शायद ही कोई कहेगा कि, किनारे पर खड़ा है, यह एक स्थिर स्थिति में है।

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

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

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

Fan-in ( ): . , .
Fan-out ( ): . , .
I: : I = Fan-out ÷ (Fan-in + Fan-out). [0, 1]. I = 0 , I = 1 – .

तो, यह सिद्धांत कहता है कि I घटक का मीट्रिक I घटकों के मीट्रिक से अधिक होना चाहिए जो इस पर निर्भर करते हैं। यही है, निर्भरता की दिशा में मीट्रिक मैं घटनी चाहिए।

यह ध्यान रखना महत्वपूर्ण है कि यदि सिस्टम के सभी घटक यथासंभव स्थिर हैं, तो ऐसी प्रणाली को बदलना संभव नहीं होगा। इसलिए, सभी घटकों को स्थिर नहीं होना चाहिए।

यार, मैं सो रहा हूँ, मैं पास हूँ बस थोड़ा सा बचा है!

SAP: स्थिर सार सिद्धांत - सार की स्थिरता का सिद्धांत। एक घटक की स्थिरता इसकी अमूर्तता के लिए आनुपातिक है।

“सॉफ्टवेयर सिस्टम के कुछ हिस्सों को बहुत कम ही बदलना चाहिए। ये टुकड़े उच्च-स्तरीय वास्तु और अन्य महत्वपूर्ण निर्णयों का प्रतिनिधित्व करते हैं। कोई नहीं चाहता कि ऐसे फैसले अस्थिर हों। इसलिए, उच्च-स्तरीय नियमों को समाप्‍त करने वाले सॉफ़्टवेयर को स्थिर घटकों (I = 0) में रहना चाहिए। वाष्पशील (I = 1) में केवल परिवर्तनशील कोड होना चाहिए - एक कोड जो आसानी से और जल्दी से बदला जा सकता है।

लेकिन यदि आप स्थिर घटकों में उच्च-स्तरीय नियम रखते हैं, तो इससे स्रोत कोड में परिवर्तन को जटिल बनाया जाएगा जो उन्हें लागू करता है। यह पूरी वास्तुकला को अनम्य बना सकता है। अधिकतम स्थिरता (I = 0) के साथ एक घटक कैसे इतना लचीला है कि यह परिवर्तनों के दौरान स्थिर रहता है? उत्तर खुलेपन / बंद करने (OCP) के सिद्धांत में निहित है। यह सिद्धांत कहता है कि ऐसी कक्षाएं बनाना संभव और आवश्यक है जो पर्याप्त लचीली हों ताकि बदलाव के बिना उन्हें विरासत में (विस्तारित) प्राप्त किया जा सके। कौन से वर्ग इस सिद्धांत का अनुपालन करते हैं? सार।

SAP (अमूर्तता की स्थिरता का सिद्धांत) स्थिरता और अमूर्तता के बीच संबंध स्थापित करता है। एक ओर, वह कहता है कि एक स्थिर घटक को भी सार होना चाहिए ताकि उसकी स्थिरता का विस्तार न हो, और दूसरी ओर, वह कहता है कि एक अस्थिर घटक को ठोस होना चाहिए, क्योंकि अस्थिरता से उसका कोड बदलना आसान हो जाता है।

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

सार (एसएपी) और स्थिर निर्भरता (एसडीपी) की स्थिरता के सिद्धांत एक साथ घटकों के लिए निर्भरता व्युत्क्रम (डीआईपी) के सिद्धांत के अनुरूप हैं। यह सच है क्योंकि एसडीपी सिद्धांत की आवश्यकता है कि निर्भरता स्थिरता की ओर निर्देशित की जाए, और एसएपी सिद्धांत बताता है कि स्थिरता का मतलब है सार। यही है, निर्भरता को अमूर्तता की ओर निर्देशित किया जाना चाहिए।

हालांकि, डीआईपी सिद्धांत कक्षाओं के लिए तैयार किया गया है, और कक्षाओं के मामले में कोई मिडटोन नहीं हैं। वर्ग या तो अमूर्त है या नहीं। एसडीपी और एसएपी के सिद्धांत घटकों पर लागू होते हैं और ऐसी स्थिति की अनुमति देते हैं जहां एक घटक आंशिक रूप से सार या आंशिक रूप से स्थिर होता है। "

एक घटक की अमूर्तता को कैसे मापें? यहाँ भी, सब कुछ बहुत सरल है।
अमूर्त घटक के माप का मूल्य इसके इंटरफेस और अमूर्त वर्गों की कुल संख्या के वर्गों के अनुपात से निर्धारित होता है।

एनसी: घटक में कक्षाओं की संख्या।
ना: घटक में अमूर्त वर्गों और इंटरफेस की संख्या।
A: सार। ए = ना ÷ एनसी ।

मीट्रिक ए का मान 0 से 1. की सीमा में भिन्न होता है। इसका मतलब घटक में सार तत्वों की पूर्ण अनुपस्थिति है, और 1 का अर्थ है कि घटक में सार वर्ग और इंटरफेस के अलावा कुछ भी नहीं है।

I और A के बीच की निर्भरता

यदि आप ग्राफ़ (Y - अमूर्त, X - अस्थिरता) पर साजिश करते हैं, तो दोनों प्रकार के "अच्छे" घटक: अमूर्त स्थिर और ठोस अस्थिर होते हैं, हमें यह मिलता है:

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

इस सेट को उन क्षेत्रों को परिभाषित करके प्राप्त किया जा सकता है जहां घटकों को स्थित नहीं होना चाहिए - दूसरे शब्दों में, बहिष्करण क्षेत्रों को परिभाषित करना।

दर्द क्षेत्र

बिंदु (0, 0) के पास स्थित घटकों पर विचार करें।

वे बहुत स्थिर और विशिष्ट हैं। ऐसे घटक तब से अवांछनीय हैं बहुत कठिन हैं। उनका विस्तार नहीं किया जा सकता, क्योंकि वे अमूर्त नहीं हैं और उनकी महान स्थिरता के कारण इसे बदलना बहुत मुश्किल है। जितना अधिक हम उस घटक को बदलते हैं जो दर्द क्षेत्र में प्रवेश करता है, उतना ही अधिक दर्द होता है। यह इसके परिवर्तन की जटिलता के कारण है।

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

बेकार क्षेत्र

बिंदु (1, 1) के पास स्थित घटकों पर विचार करें।

इस तरह के घटक भी अवांछनीय हैं, क्योंकि वे यथासंभव सारगर्भित हैं और उनकी कोई निर्भरता नहीं है। वे बस बेकार हैं। अक्सर ये अमूर्त वर्ग होते हैं जिन्हें कभी लागू नहीं किया गया।

बहिष्करण क्षेत्र में आने से कैसे बचें?

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

मुख्य अनुक्रम की दूरी

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

डी: दूरी। D = | A + I - 1 | । यह मीट्रिक सीमा [0, 1] से मान लेता है। 0 का मान इंगित करता है कि घटक सीधे मुख्य अनुक्रम पर है। 1 का मान इंगित करता है कि घटक मुख्य अनुक्रम से अधिकतम दूरी पर स्थित है।

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

लेखक का निष्कर्ष (रॉबर्ट मार्टिन)

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

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

दूसरा दिन। उम्म, यानी। भाग 2

परिचय

मैं इतने लंबे समय से क्या रगड़ रहा था? "आह, हाँ ... हम आर्किटेक्ट की तरह हैं, या हम वास्तव में उन्हें होना चाहते हैं, है ना?"

हमारे पास क्या है? - किसी तरह की दयनीय प्रक्षेपण, या शायद एक राक्षसी प्रणाली, परियोजना, उसकी मां, अच्छी तरह से, या अंत में अभी तक कोई निफ़्ट नहीं है, लेकिन हम सिर्फ अपने हाथों को रगड़ते हैं, कैलेंडर को देखते हैं और पता लगाते हैं कि हमें कितनी अच्छी तरह से बात करनी होगी।

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

वास्तव में, यह कोई बात नहीं है। यह क्या महत्वपूर्ण है: हम सभी, अंत में, बस चाहते हैं कि हमारे दिमाग की उपज समय से पहले झुकना नहीं चाहिए, ठीक है, कम से कम हमारे जाने से पहले, और उसके लिए सभी संभावनाएं हैं। हाँ, हाँ ...

और अब क्या करना है, आप पूछें? इसलिए, यदि आपके पास कार्यालय में एक बड़ा भाई नहीं है, तो तीसरी आंख के बिना भाई ऐसा नहीं कर सकता है।

पहले भाग का सारांश

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

एक - घटक के अमूर्त
मैं - घटक की अस्थिरता
डी - ग्राफ पर मुख्य अनुक्रम के लिए दूरी ए / मैं ~~के वासनोत्तेजक क्षेत्र~~ दर्द और निरर्थकता क्षेत्रों रहे थे

पता चला । हम इस निष्कर्ष पर पहुंचे कि, आदर्श रूप से, ए को घटने के अनुपात में वृद्धि और कमी करनी चाहिए और, तदनुसार, I में वृद्धि

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

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

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

उपकरण और परीक्षण परियोजना। विषय का परिचय

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

इसलिए, परियोजना स्वयं यहाँ github.com/Chetkov/php-clean-altecture-example-project पर स्थित है ।

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

हालाँकि यह इतना बुरा नहीं है। फिलहाल इसके पास है: उपयोगकर्ता, उत्पाद और ऑर्डर , साथ ही परिदृश्य: उपयोगकर्ता पंजीकरण, पासवर्ड परिवर्तन, एक उत्पाद जोड़ना और ऑर्डर बुक करना ।

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

भविष्य में, मैं लेख में वर्णित तकनीकी बिंदुओं को तुरंत ठीक करने के लिए विशिष्ट कमिटों के लिंक को फेंक दूंगा।

प्रारंभिक अवस्था

। मुझे लगता है कि आप पहले से ही संरचना से परिचित होने में कामयाब रहे। तो हम आगे बढ़ सकते हैं।

हम PHP साफ वास्तुकला शामिल हैं :

composer require v.chetkov/php-clean-architecture:0.0.3

हम कॉन्फ़िगरेशन फ़ाइल बनाते हैं और कॉन्फ़िगर करते हैं

विश्लेषण के लिए दृश्य

हम कंसोल में (प्रोजेक्ट रूट में) निष्पादित करते हैं:

vendor/bin/phpca-build-reports

या

vendor/bin/phpca-build-reports /path/to/phpca-config.php

और प्रतिक्रिया में हम प्राप्त करते हैं:

Report: /path/to/reports-dir/index.html

रिपोर्ट में 3 स्क्रीन शामिल हैं:

1. सिस्टम के बारे में सामान्य जानकारी

यह स्क्रीन प्रदर्शित करती है:

घटकों के फैलाव को दर्शाने वाला समान ए / आई ग्राफ:

मुख्य अनुक्रम से घटकों के दूरस्थता को दर्शाने वाला ग्राफ:

और घटकों के बीच संबंधों को दिखाने वाला एक ग्राफ:

तीर निर्भरता की दिशा को इंगित करते हैं, और उन पर संख्या कनेक्शन की ताकत का संकेत देती है।

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

उदाहरण के लिए: सेवा मॉड्यूल के तत्व मॉडल मॉड्यूल के 12 तत्वों के बारे में जानते हैं , और बुनियादी ढांचे के तत्व सेवाओं के 1 तत्व के बारे में जानते हैं । आदि।

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

यदि, हालांकि, आप इस तरह से विन्यास को सही करते हैं:

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

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

सक्षम करने के बाद_बेड_मॉड्यूल ग्राफ बदल गया है, हालांकि हमने खुद मॉड्यूल के विन्यास को नहीं बदला है

2. घटक के बारे में विस्तृत जानकारी

यहाँ हम भी देखते हैं:

इंटरकनेक्ट का ग्राफ , लेकिन पूरे सिस्टम का नहीं, बल्कि इसमें शामिल घटकों का ही
ए / I चार्ट केवल वर्तमान घटक दिखा रहा है
मुख्य मॉड्यूल सुविधाएँ

तथा

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

और आने वाले निर्भरताओं का एक ग्राफ , वर्तमान मॉड्यूल के आधार पर अन्य मॉड्यूल में फाइलों की संख्या और सूची दिखा रहा है।

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

3. घटक तत्व के बारे में विस्तृत जानकारी

यहाँ आप देख सकते हैं:

तत्व की मुख्य विशेषताएं , जैसे कि अमूर्तता, अस्थिरता, आदिम, और किस घटक से संबंधित है और एक्सेस संशोधक ।

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

निर्भरता ग्राफ , जो सिस्टम के अन्य तत्वों के साथ विचार के तहत तत्व की बातचीत को दर्शाता है

और आउटगोइंग और इनकमिंग निर्भरता वाली टैबलेट

स्क्रीन के विवरण समाप्त होने के साथ, इसे लेने और इसे कैसे कॉन्फ़िगर किया जा सकता है, यह जानने के लिए कॉन्फ़िगर पर जाएं।

कॉन्फ़िगरेशन विकल्प

मुख्य अनुक्रम के लिए अधिकतम स्वीकार्य दूरी को सीमित करना (सभी घटकों के लिए)

सबसे पहले, सभी घटकों को मुख्य अनुक्रम के लिए अधिकतम स्वीकार्य दूरी पर सेट करने का प्रयास करें। यह सोचना मूर्खता होगी कि वे सभी मुख्य विकर्ण पर झूठ बोलेंगे, क्योंकि दुनिया सही नहीं है, इसलिए हम यथार्थवादी बनें। मुझे क्या करना 0.3

पुनरारंभ रिपोर्ट जनरेशन आदेश और तुरंत मुख्य पृष्ठ पर उल्लंघन को देखते हैं। मॉडल घटक 0.192 द्वारा अनुमत दूरी से अधिक है

मुख्य अनुक्रम के लिए अधिकतम अनुमत दूरी को सीमित करना (एक विशिष्ट घटक के लिए)

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

मेरी राय में, मुख्य बात यह है कि वर्तमान स्थिति को ठीक करना, सुधार की दिशा में काम करना और स्थिति को नियंत्रित करना ताकि वृद्धि न हो।

फिर से, कॉन्फ़िगरेशन पर जाएं, और एक विशिष्ट मॉड्यूल के लिए, केवल अधिकतम_स्टेबल_डिस्टेंस सेट करें । मैं इसके मौजूदा मूल्य 0.492 पर ठीक करता हूं

ZBS, अब सब कुछ फिर से सामान्य है।

लेकिन अगर, कुछ ** का वास के साथ, वह फिर से कुछ धूम्रपान करता है और खराब हो जाता है - ~~उसके हाथ काट लें!~~ एक CI / CD जिसमें phpca-check कमांड चलाना शामिल है (हम इसके बारे में बाद में बात करेंगे) उसे डांटते हैं, शायद एक बेईमानी भाषा भी, और निश्चित रूप से यह त्रुटियों को उजागर करेगा।

घटक निर्भरता नियंत्रण

खराब वास्तुकला से निपटने के लिए हमारे शस्त्रागार में और क्या अच्छा होगा? बेशक, निर्भरता नियंत्रण। कौन किसके बारे में जान सकता है, या इसके विपरीत नहीं जानना चाहिए।

आपको क्या लगता है, क्या सिस्टम का बहुत केंद्रीय हिस्सा, डोमेन कह सकते हैं , ताकि DDDowski के लिए कुछ ~~बदबूदार~~ बुनियादी ढांचे के बारे में कुछ जानना पूरी तरह से संभव हो सके ?
बेशक, कुछ के लिए, सीधे, सफलता की एक विशेषता (ठीक है, मैं उन लोगों के बारे में बात कर रहा हूं जो HTML को व्यावसायिक तर्क के साथ मिश्रित करते हैं)। लेकिन अंत में, जैसा होना चाहिए, मुझे नहीं होना चाहिए ... मैं निश्चित रूप से एक्सएस हूं, लेकिन पुस्तकों में सभी प्रकार के अलग-अलग चतुर लोग कहते हैं कि यह पैतृक नहीं है।

फिर चलो इस तरह से हलचल करें ... सब कुछ एक ही स्थान पर है, मॉडल के लिए प्रतिबंधों के विन्यास में ।

हम्म ... अब तक, सभी नियम, क्योंकिइन्फ्रास्ट्रक्चर के बारे में मॉडल वास्तव में कुछ भी नहीं जानता है ...

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

github.com/Chetkov/php-clean-altecture-example-project/commit/6bad365176b30999035967319a9c07fae69fabf9

अब हम रिपोर्ट पर नज़र डालते हैं ... जैसा कि हम देख सकते हैं, रिपोर्ट के विभिन्न पृष्ठों पर दिए गए रेखांकन इस संबंध को नाजायज बताते हैं।

घर।

घटक की रिपोर्ट।

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

से मॉडल तत्वों के "आउटगोइंग निर्भरता" और इन्फ्रास्ट्रक्चर तत्वों के "इनबाउंड निर्भरता" की तालिकाओं में ।

PHPCAEP \ Model \ User \ उपयोगकर्ता

PHPCAEP \ Infrastructure \ Notification \ Sms \ SmsNotifier

साथ ही तत्व संबंधों के ग्राफ पर। मुझे लगता है कि भविष्य में इससे पूरी तरह छुटकारा पा लिया जाएगा, क्योंकि यह बहुत जानकारीपूर्ण नहीं है (विशेष रूप से सक्रिय रूप से इस्तेमाल की जाने वाली कक्षाओं के लिए, क्योंकि नोड्स के नाम की लंबाई + उनकी विशाल संख्या)

इसी तरह की कार्रवाइयां अनुमत_निर्भरता कॉन्फ़िगरेशन के साथ की जा सकती हैं ।

परिणाम पूरी तरह से विपरीत होगा।

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

PHP

ओके में पब्लिक / प्राइवेट क्लास , हमने सीखा कि कैसे घटकों के ज्ञान की सीमा को संकीर्ण और नियंत्रित किया जाए। पहले से ही बुरा नहीं है। आगे क्या होगा?

और फिर एक और समस्या। दुश्मन सोता नहीं है, हालांकि ज्यादातर मामलों में यह दुश्मन, हम खुद हैं, या कार्यालय में हमारे पक्षधर हैं।

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

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

आप: “सब कुछ अच्छा है, यह शर्मीला है। इस समस्या को कैसे सुलझाया जाए? "
Me: "केवल कक्षाओं को बातचीत के लिए अनुमति दें, और बाकी लोगों तक पहुंच को प्रतिबंधित करें।"
आप: "लेकिन PHP में कक्षाओं के लिए कोई पहुँच संशोधक नहीं हैं।"
मुझे: "मैं सहमत हूं, लेकिन एक PHP क्लीन आर्किटेक्चर है ।"

एक उदाहरण अब नशीली दवाओं की लत से फिर से होगा, लेकिन क्या करना है।

वास्तविक परियोजनाओं में, बेशक, मामलों की भरमार है, लेकिन वे सूचनाओं की निकासी के लिए एक बोतल ला सकते हैं और उन्हें बैठने के लिए कह सकते हैं। इसलिए आपको रचना करनी होगी।

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

अब हमारे पास क्या है?

मुख्य पर भरोसा करें।

आप तुरंत देख सकते हैं कि किन घटकों की समीक्षा करने की आवश्यकता है।

हम यह देखने के लिए चढ़ाई करते हैं कि बुनियादी ढांचे में क्या गलत है ।

"आउटगोइंग निर्भरता" के ग्राफ पर, हम ऐसे तत्वों को देखते हैं जो नियम का उल्लंघन करते हैं:

तत्व जानकारी पृष्ठ पर, इसी तरह।

यदि हम कॉन्‍फ़िगरेशन में Private_elements निर्दिष्ट करते हैं, तो हम ठीक विपरीत परिणाम प्राप्त करेंगे ।

उदाहरण के लिए, हम सभी को Fio के बारे में जानने के लिए मना करते हैं।

अब मुख्य

पृष्ठ पर : सेवा घटक सूचना पृष्ठ पर :

और तत्व जानकारी पृष्ठ पर PHPCAEP \ Model \ User \ Fio :

एडीपी और एसडीपी के सिद्धांतों के उल्लंघन की निगरानी करना

, फिर भी, शायद, हमें जांचों की संभावना को उजागर करने की आवश्यकता है:

एडीपी सिद्धांत के उल्लंघन के लिए, अर्थात्। ग्राफ़ में चक्रीय निर्भरता के अस्तित्व के लिए ( check_acyclic_d dependencies_principle )
और एसडीपी सिद्धांत के उल्लंघन के लिए, अर्थात अधिक स्थिर मॉड्यूल से कम स्थिर ( check_stable_d dependencies_principle ) के लिए निर्भरता के लिए निर्देशित

लेकिन यह अब तक केवल phpca-check में काम करता है और रिपोर्ट में प्रदर्शित नहीं होता है। भविष्य में, मुझे लगता है कि मैं इसे सही करूंगा।

CI / CD में स्वचालित नियंत्रण

इस बार मैंने पहले भाग के बारे में बात की - दृश्य। और विश्लेषण जो इसके आधार पर किया जा सकता है।

समय आ गया है कि हमारे ~~दोस्तों को गोवन्नोकोडेरा~~ माननीय सहयोगियों को पीड़ित किया जाए।

हम कंसोल में (प्रोजेक्ट रूट में) लॉन्च करते हैं:

vendor/bin/phpca-check

या

vendor/bin/phpca-check /path/to/phpca-config.php

यह माना जाता है कि इस कमांड को चलाने से आपके प्रोजेक्ट की CI / CD प्रक्रिया जुड़ जाएगी। इस स्थिति में, त्रुटि आगे की असेंबली को ब्लॉक कर देगी।

स्क्रिप्ट एक त्रुटि के साथ समाप्त होती है और कुछ इस तरह से फेंकता है:

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

डीब्रीफिंग

निर्भरता (एडीपी) की अम्लता के सिद्धांत का उल्लंघन
इसी तरह, लेकिन चक्र थोड़ा छोटा है
2 मॉडल तत्व (सूचीबद्ध) बुनियादी सुविधाओं पर निर्भर करते हैं , जो कि कॉन्फ़िगरेशन द्वारा अनुमत नहीं है
एडीपी ने फिर उल्लंघन किया
एक और लूप और एडीपी उल्लंघन
SDP का उल्लंघन अधिक टिकाऊ मॉडल कम टिकाऊ बुनियादी ढांचे पर निर्भर करता है
फिर से चक्रीय निर्भरता, गलत हो
1 सेवा तत्व (सूचीबद्ध) गैर-सार्वजनिक Fio पर निर्भर करता है

लगभग इस परिणाम के लिए हमारे प्रयासों ~~और परिश्रमी गोवनोकोडिंग के~~ लिए धन्यवाद है ।

अब चलो गांड में सब कुछ घुमा दो। खैर, यानी। काफी सब कुछ नहीं, मैं स्वाभाविक रूप से विन्यास छोड़ देता हूं। मैं केवल कोड का नियम रखता हूं।

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

समस्या निवारण

मैंने पहले से की गई लत को हटा दिया।

github.com/Chetkov/php-clean-architecture-example-project/commit/f6bbbff1313bb4a22dfb6061f347ef007ba3b422f

पुनः प्रारंभ विक्रेता / bin / phpca की जांच

ठीक है, वहाँ केवल संपादित करने के लिए एक config है, क्योंकि एक उदाहरण वास्तव में एक ड्रग एडिक्ट द्वारा आविष्कार किया गया था।

फिर से विक्रेता / बिन / phpca- जांच

और सीआई / सीडी पर चला गया!

बस इतना ही।

अंतभाषण

एक पांचवें को पकड़ो, यदि आप इसे अंत तक पढ़ते हैं, यदि नहीं, तो सड़क पर अपना पैर सूँघ लें (वैसे भी, आपने यह नहीं देखा था)।

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

अगर कुछ गलत था तो मैं फिर से माफी मांगता हूं।

शायद, मेरी प्रस्तुति का तरीका किसी को थोपना या अपमानजनक लग सकता है, मैं सिर्फ लेख को थोड़ा पतला करना चाहता था और किसी भी तरह से मैं किसी को नाराज नहीं करना चाहता था। मुझे लगता है कि इसके बिना, यह बहुत शुष्क हो गया होगा और पढ़ना मुश्किल होगा।

मैं वास्तव में आपकी राय जानना चाहता हूं और यदि आपके पास कोई विचार, विचार, सुझाव या आपत्ति है, तो टिप्पणियों में चर्चा करें।

आप के लिए स्वच्छ कोड और लचीला वास्तुकला!

शुद्ध PHP वास्तुकला। इसे कैसे मापें और नियंत्रित करें?