कोर डिजाइन तकनीक

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

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

तकनीक को CORE क्यों कहा जाता है और इसे कैसे डिकोड किया जाता है? आंशिक रूप से क्योंकि मुझे सुंदर नामों की लालसा है। पत्र द्वारा:
संदर्भ - गणना का संदर्भ (जिसने गणना शुरू की)
ऑब्जेक्ट - एक ऑब्जेक्ट जो गणना करता है
अनुरोध - एक क्रिया जिसे करने की आवश्यकता है ताकि ऑब्जेक्ट कंप्यूटिंग जारी रख सके
घटना - एक घटना जो किसी वस्तु के साथ होती है

मानक विकास विधियों की तुलना में पेशेवरों:
- एक औपचारिक डिजाइन योजना के कारण डिजाइन चरण का त्वरण
- स्मार्ट कोड निर्माण के कारण विकास चरण का त्वरण
- इकाई परीक्षण बनाने का स्वचालन
- लगभग किसी भी जटिलता के व्यावसायिक तर्क का अवैध कार्यान्वयन
- सरल कोड समर्थन
- कोड साझा करने में आसानी

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

सिद्धांत की एक बिट।

कोड कनेक्टिविटी, प्रतिरूपकता और स्ट्रीमिंग

प्रोग्रामिंग में, सब कुछ सामान्य और सरल है: यदि हम निष्पादन के बिंदु पर हैं, तो किसी ने हमें बुलाया।

 ओ WebDispatcher
  \
    o ArticleController
     \
      o ArticleMapper
       \
         ओ डीबी
        /
      ओ
     /
    ओ
     \
      o विजेट प्रबंधन
       \
        o विजेटफॉरनोवाइस
       /
      ओ
       \
        o WidgetForExpirienced
       /
      ओ
     /
    ओ
     \
      ओ स्टेट
     /
    ओ
   /
 ओ
  \
   o ViewRenderer
  /
 ओ

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

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

आइए संभावित प्रकारों को वर्गीकृत करने का प्रयास करें:

- मैं, फोन करने वाला, तार्किक रूप से "को बुलाया वर्ग" जानता है और इसे कॉल करता है क्योंकि यह क्रियाओं के अपने तर्क का हिस्सा है (उदाहरण के लिए, मैपर डेटाबेस को कॉल करना जानता है और इसके साथ कैसे काम करना है - वास्तव में, वह डेटाबेस के बारे में सब कुछ जानता है।
- फोन करने वाला तार्किक रूप से "नहीं जानता" वर्ग कहलाता है, लेकिन जिस वर्ग को बुलाया जा रहा है उसे बुलाया जाना चाहिए (उदाहरण: नियंत्रक को सफलतापूर्वक काम करने के लिए आँकड़ों की आवश्यकता नहीं है, लेकिन आँकड़ों को नियंत्रक से बुलाने की आवश्यकता है, क्योंकि अन्यथा यह काम नहीं करेगा)
- कॉलिंग पार्टी को पता नहीं है कि किसे कॉल करना है, लेकिन इसे करने की आवश्यकता है (उदाहरण: WidgetManager को यह नहीं पता है कि WidgetForNovice और WidgetForExpirienced में से किसे दिखाया जाएगा, लेकिन यह सुनिश्चित करने की आवश्यकता है कि विजेट जो शर्तों से मेल खाता है)

इसे व्यावहारिक पक्ष से कैसे देखें,
- DB वर्ग इस बात की परवाह नहीं करता है कि इसका इस्तेमाल कौन करेगा - मैपर या कोई और - यह तर्क से बंधा नहीं है
- इसके विपरीत, मैपर डेटाबेस पर बहुत निर्भर है, यह इसके साथ बंधा हुआ है, और यदि MySQL के बजाय यह रेडिस को इसमें खिसकाता है, तो यह टूट जाएगा
- ArticleController वर्ग, द्वारा और बड़े, यह एक लानत नहीं है कि यह रास्ते में आँकड़े खींचने की जरूरत है - यह उसके कर्तव्यों द्वारा उसे सौंपे गए डेटा प्रदर्शन को प्रभावित नहीं करेगा
- स्टेट क्लास, इसके विपरीत, यह जानना चाहता है कि यह किन स्रोतों से डेटा एकत्र करता है - इसे सही तरीके से काम करने के लिए इसके स्रोतों के बारे में सब कुछ जानना होगा
- WidgetManager वर्ग को परवाह नहीं है कि सिस्टम में कितने विजेट पंजीकृत हैं, लेकिन यह महत्वपूर्ण है कि उनमें से एक प्रदर्शित करता है
- विजेट कक्षाओं के लिए यह सत्यापित करना महत्वपूर्ण है कि उन्हें प्रदर्शित किया जा सकता है और उसी तरह प्रदर्शित किया जा सकता है - वे WidgetManager के सहायक होने के लिए बनाए गए हैं

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

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

प्रदान किए गए संसाधनों के प्रकार से, घटकों को दो प्रकारों में विभाजित किया जा सकता है:
- बाहरी कॉल करने वाले घटक (ArticleController कक्षाओं का एक गुच्छा कॉल करना चाहिए)
- ऐसे घटक जो बाहरी कॉल नहीं करते हैं (उदाहरण के लिए, केवल कॉल करने के लिए कुछ नहीं है)

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

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

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

अच्छी तरह से संरचित कोड सिद्धांत

यदि हम प्रोग्रामिंग करते समय निम्नलिखित सिद्धांतों का पालन करते हैं तो यह अच्छा है:

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

- उलटा निर्भरता से बचें
यह तब होता है जब निम्न-स्तरीय ऑब्जेक्ट उच्च-स्तरीय ऑब्जेक्ट को आमंत्रित करते हैं। उदाहरण के लिए, कुछ WebDispatcher जिसमें पेज या व्यावसायिक तर्क स्तर कक्षाओं के लिए कॉल सीधे पंजीकृत हैं। क्योंकि एक बार यह बहुत सुविधाजनक था, लेकिन वे रिफैक्टिंग के बारे में भूल गए। खैर, परवाह मत करो, यह काम करता है।

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

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

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

- घटकों में अच्छी तरह से कोड को तोड़ने
घटक को समझना आसान है। घटक का परीक्षण करना आसान है। एक घटक संरचना के साथ, एक परियोजना को भागों में विभाजित करना और छोटे समूहों में काम को व्यवस्थित करना आसान है। मैंने आगे टिप्पणी नहीं की, यहाँ सब कुछ स्पष्ट है।

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

इसके अलावा, खुद को जोड़े:

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

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

अभ्यास करना

तो, आइए किसी भी विकासशील वेब परियोजना के जीवन से एक सार व्यावहारिक समस्या को हल करने का प्रयास करें।

एमवीसी मॉडल के शास्त्रीय संगठन में कोड की सुंदर संरचना को तोड़ते हुए, कार्य बहुत तुच्छ नहीं है: “एक प्रयोग करें: सत्र में 5 वें खुले पृष्ठ पर 27 से 35 वर्ष के मास्को के 50% उपयोगकर्ताओं के लिए गेम-मुद्रा खरीदने के लिए एक पॉपअप कॉलिंग दिखाते हैं, और सत्र की औसत लंबाई (साइट / विचारों पर समय) में परिवर्तन पर आंकड़े एकत्र करें और प्रति अद्वितीय आगंतुक की कुल बिक्री में वृद्धि करें। "

हम समस्या को औपचारिक रूप देते हैं:

पॉपअप शो:
- हम 27 से 35 साल के उपयोगकर्ताओं का चयन करते हैं, चलो समूह का नाम TargetGroupMsk27to35 है
- हम उपयोगकर्ताओं को समूह A और B में विभाजित करते हैं (परीक्षण और नियंत्रण समूह)
- जब उपयोगकर्ता खेल में प्रवेश करता है, तो समूह A के लिए हम 5 वें पृष्ठ की गिनती करते हैं, इस घटना को "समूह A में 5 वाँ दृश्य" कहते हैं (GroupMsk27to35TargetView)
- जब GroupAView इवेंट होता है, तो वांछित पॉपअप दिखाएं

सत्र के आँकड़े:
- जब TargetGroupMsk27to35 पर सत्र शुरू हुआ, तो हम इसकी शुरुआत का समय नोट करते हैं
- जब TargetGroupMsk27to35 पर सत्र समाप्त हो गया है, तो हम इसके अंत के समय को मापते हैं और आंकड़ों में डालते हैं
- जब PageView लक्ष्य समूह Msk27to35 समूह में उपयोगकर्ता में होता है, तो हम दृश्य काउंटर को बढ़ाते हैं
- जब TargetGroupMsk27to35 पर सत्र समाप्त हो गया है, हम व्यू काउंटर से मान लेते हैं और इसे आंकड़ों में डालते हैं

मुद्रीकरण सांख्यिकी:
- जब कोई उपयोगकर्ता TargetGroupMsk27to35 से खरीदारी करता है, तो हम अपने चयनित आंकड़ों में मूल्य डालते हैं

अलग-अलग, हम ध्यान दें कि शब्द "वांछित पॉप-अप दिखाओ" काफी सार है, इसलिए हम औपचारिक करते हैं:
- जब आप PopupMsk27to35 पॉपअप दिखाना चाहते हैं, तो हम इसे PopupMsk27to35.tpl, PopupMsk27to35.css और PopupMsk27to35.js फाइलों से लेते हैं।

जैसा कि आप देख सकते हैं, हमारा व्यापार कार्य आसानी से CORE में विघटित हो गया था:
संदर्भ: वेब अनुरोध, सत्र अंत का पता लगाने वाली स्क्रिप्ट
ऑब्जेक्ट्स: ExperimentMsk27to35 प्रयोग, पॉपअप Msk27to35 पॉपअप, StatMsk27to35 आँकड़े
घटनाएँ: PageView, UserStartSession, UserEndSession, UserBuyMoney, GroupMsk27to357rarViewView

औपचारिक विवरण के अनुसार हम कोड उत्पन्न करते हैं:

//   ,   php class ExperimentMsk27to35 { function isOn() { return Config::get('ExperimentMsk27to35_enabled'); //    } function inTargetGroup(User $User) { return $User->getAge() >= 27 && $User->getAge() <= 35; } function inGroupA(User $User) { //  ,    ,  md5,    //  50%     id return self::inTargetGroup($User) && $User->getId()%2 == 0; } function inGroupB(User $User) { return self::inTargetGroup($User) && $User->getId()%2 == 1; } function onPageView(User $User, Page $Page, Session $Session) { if (self::inGroupA($User)) { //    memcached $count = Memcached::getInstance()->increment('Msk25to37GroupAPageViews_'.$Session->getId()); if($count == 5) new Event('GroupMsk27to35TargetView', $User, $Page); } } } class PopupMsk27to35 { function onGroupMsk27to35TargetView() { if(ExperimentMsk27to35::isOn()) { new Request('ShowPopupMsk27to35', $Page); } } } class PopupMsk27to35View extends ViewElement { protected $render = false; function requestShowPopupMsk27to35() { $this->render = true; } function onPageRender(Page $Page) { if($this->render) { $this->renderTo($Page, 'PopupMsk27to35.tpl', 'PopupMsk27to35.css', 'PopupMsk27to35.js'); } } } class StatMsk25to35 extends Stat { function onSessionStart(User $User, Session $Session) { if(ExperimentMsk27to35::inTargetGroup($User)) { Memcached::getInstance()->set('Msk25to37sessionStartTime_'.$Session->getId(), time()); } } function onPageView(User $User, Page $Page, Session $Session) { if (ExperimentMsk27to35::inTargetGroup($User)) { //    memcached Memcached::getInstance()->increment('Msk25to37PageViews'.$Session->getId()); } } function getSuffix(User $User) { if(ExperimentMsk27to35::inGroupA($User)) { return "a"; } if(ExperimentMsk27to35::inGroupB($User)) { return "b"; } return $stat_suffix; } function onSessionEnd(User $User, Session $Session) { if(ExperimentMsk27to35::inTargetGroup($User)) { $time0 = Memcached::getInstance()->get('Msk25to37sessionStartTime_'.$Session->getId()); $sessoin_time = time() - $time0; $page_views = Memcached::getInstance()->get('Msk25to37PageViews'.$Session->getId()); $stat_suffix = $this->getStatSuffix($User); $this->writeUserStat($User, 'session_time_'. $stat_suffix, $session_time); $this->writeUserStat($User, 'page_views_'. $stat_suffix, page_views); } } function onIncomingMoney($User, $MoneyOperation) { if(ExperimentMsk27to35::inTargetGroup($User)) { $stat_suffix = $this->getStatSuffix($User); $this->writeUserStat($User, 'money_'. $stat_suffix, $MoneyOperation->getAmount()); } } } 

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

(ऑफटॉप: "यहाँ क्या सुधार किया जा सकता है" विषय पर चर्चा की आशंका - कुछ किया जा सकता है, उदाहरण के लिए, आंकड़ों को स्थगित किया जा सकता है, ताकि वेब अनुरोध में मेमेकैच के लिए अनुरोध न उत्पन्न हो सके)

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

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

क्यू एंड ए

प्रश्न: अर्थात्, घटकों के बीच निर्भरताएँ स्पष्ट रूप से निर्दिष्ट हैं? कहीं अंदर, घटनाओं को ट्रिगर किया जाता है और यह पता लगाने का कोई तरीका नहीं है कि कौन सी घटना चल रही है।
उत्तर: कुछ भी नहीं है। तथ्य यह है कि बंडल कोड सांख्यिकीय रूप से उत्पन्न होता है, और आप कॉल के अंदर जा सकते हैं, देखें कि क्या और कहाँ कहा जाता है। यहां तक ​​कि आईडीई द्वारा भी कोड उठाया जाएगा और सब कुछ काम करेगा - स्वतः पूर्ण, वाक्यविन्यास हाइलाइटिंग। बाह्य रूप से, सब कुछ ऐसा दिखता है जैसे कि इवेंट / अनुरोध और हैंडलर्स के बंडलों के लिए कोड एक प्रोग्रामर द्वारा लिखा गया था, लेकिन व्यवहार में, प्रोग्रामर को इसका समर्थन करने की आवश्यकता नहीं है।

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

सवाल: क्या लेफ्ट सब्सक्राइबर पूरे आवेदन को डालेगा? जब सब कुछ घटकों में विभाजित होता है, और घटक "ब्लैक बॉक्स" होते हैं, तो गोवनोकॉड के कारण गिरने की उच्च संभावना होती है।
उत्तर: विशुद्ध रूप से सैद्धांतिक रूप से, हाँ, आप एक घातक त्रुटि पैदा कर सकते हैं (यदि हम php की बात करें)। व्यवहार में, प्रत्येक कॉल कोशिश / कैच में बदल जाती है, निष्पादन की गति के बारे में जानकारी प्रत्येक ग्राहक के लिए स्वचालित रूप से एकत्र की जाती है, और सामान्य तौर पर सब कुछ नियंत्रण में होता है, गलती से एक परियोजना को डालना इतना आसान नहीं है। साथ ही, यूनिट परीक्षण। वैसे, मैं ऊपर दिए गए कोड के लिए यूनिट टेस्ट लिखने की कोशिश कर सकता हूं। यह वास्तव में बहुत सरल है।
इसके अलावा, आंकड़ों के लिए आंकड़ों का प्रसंस्करण, उदाहरण के लिए, विन्यास में एक पंक्ति के साथ कतार में धकेल दिया जा सकता है। और यह है - रनटाइम अलग है। यह स्केलेबिलिटी के लिए एक प्लस है (हम स्वचालित रूप से घटनाओं से कतार प्राप्त करते हैं)।

प्रश्न: यदि संचालकों का निष्पादन आदेश महत्वपूर्ण है तो क्या होगा? यह तरीका काम नहीं करेगा?
उत्तर: बेशक, यह महत्वपूर्ण है! कार्यान्वयन में, प्राथमिकताओं (भार) के आधार पर या घटनाओं के लिए और अनुरोधों के बाद सीधे / पहले निर्दिष्ट करके आदेश को नियंत्रित करना संभव है।

प्रश्न: कहाँ रहते हैं?
उत्तर: मौजूदा कोड अब बंद हो गया है, मैं इन विचारों के अनुसार php और js के लिए OpenSource कार्यान्वयन की रूपरेखा पर काम कर रहा हूं। यदि आप रुचि रखते हैं, तो टिप्पणियों में सदस्यता छोड़ें और मैं उस समय की अधिक सटीक योजना बनाऊंगा जब मैं सार्वजनिक पहुंच के लिए रूपरेखा कोड खोल सकता हूं।