कोर प्रौद्योगिकी

छह महीने पहले, मैंने अपनी प्रोग्रामिंग तकनीक ( habrahabr.ru/post/163881 ) के बारे में एक पोस्ट लिखी, जिसने मुझे (और सिर्फ मुझे नहीं) तेजी लाने और अपना काम बेहतर तरीके से करने में मदद की।

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

स्पष्टीकरण को सरल बनाने के लिए, मैं संदर्भ-वस्तु-अनुरोध-घटना प्रणाली से संदर्भों को बाहर निकाल दूंगा, और हम कार्यों की स्थापना और वे वस्तुओं, घटनाओं और अनुरोधों से कैसे संबंधित हैं, इस बारे में बात करेंगे।

समस्या कथन और बहने वाले सार

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

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

ऐसा इसलिए है क्योंकि प्रोग्रामिंग लैंग्वेज उस टास्क डिस्क्रिप्शन लैंग्वेज के समान नहीं हैं जिसका हम फॉर्म्युलेशन में उपयोग करते हैं।

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

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

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

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

यह समझना क्यों महत्वपूर्ण है? निम्नलिखित अमूर्त खेल कोड पर विचार करें (या कुछ और) js में:

addMoney: function(amount) { this.balance+=amount; if(this.balance > 250) { $('.you_win!').animate({css:{opacity: 1}}) } } 

यह कोड बहुत बुरा है। क्यों? क्योंकि इसमें पैसे के तर्क को प्रदर्शन के तर्क के साथ मिलाया जाता है। और भी बदतर:

 $('.coin').click(function(){ this.balance+=15; if(this.balance > 250) { $('.you_win").animate({css:{opacity: 1}}) } }) 

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

हम कार्य को तीन ऑब्जेक्ट में विभाजित करते हैं, जिनमें से एक डिस्प्ले और UI के लिए जिम्मेदार होगा, दूसरे खाते की स्थिति के लिए, तीसरा उपयोगकर्ता की जीत या हार का निर्धारण करने के लिए:

 var UI = { handleCoinClick: function() { .... }, showWinAnimation: function() { .... }, ... } var Balance = { addCoins: function() { ... }, ... } var WinWatcher = { watchForWin: function() { .... } ... } 

यहां यूआई केवल प्रदर्शन और क्लिक - उपयोगकर्ता इंटरैक्शन के लिए जिम्मेदार है।

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

 var UI = { handleCoinClick: function() { // ,   DOM Init,   ,      .... $('.coin').click(function(){ //       Event_CoinClick ..... }); }, showWinAnimation: function() { // ,        Request_ShowUserWin $('.you_win').animate({opacity: 0}); }, ... } var Balance = { addCoins: function() { // ,    «  » Event_CoinClick this.balance+=15; //   ,     Event_BalanceChanged }, ... } var WinHandler = { watchForWin: function(balance) { // ,   ,    Event_BalanceChanged if(balance > 250) { //   ,    Request_ShowUserWin } } ... } 

अब आपको उन कोड के टुकड़ों को लिंक करने की आवश्यकता है जहां टिप्पणियां "जब कॉल करें ..." और "यहां ड्रॉप / अनुरोध करें"। लेकिन यहाँ हम एक ही बहने वाले अमूर्त का सामना कर रहे हैं। यदि आप यूआई से सीधे बैलेंस और विनहैंडलर विधियों को कॉल करते हैं, तो हमें आंकड़े, या कुछ अन्य जटिलताएं एकत्र करने की आवश्यकता हो सकती है, और अन्य कार्यों से संबंधित कॉल यूआई विधि में जोड़े जाएंगे। विधि साफ हो जाएगा।

इसलिए, हम विधि को सरल बनाने का प्रयास करेंगे। घटना प्रेषण के लिए निर्भरता संकल्प प्रदान करें

Core.js

पिछली बार मैंने एक ओपन-सोर्स कार्यान्वयन करने का वादा किया था। वर्तमान में जावास्क्रिप्ट github.com/okneigres/corejs के लिए एक कार्यान्वयन है

पुस्तकालय ब्राउज़र में और Node.js के तहत दोनों काम करता है

 <script src="core.js"></script> var Game = { }; //  Game.UI = { CoinClickEvent: new Core.EventPoint, handleCoinClick: function() { Core.CatchEvent(Event.DOM.Init); $('.coin').click(function(){ new Game.UI.CoinClickEvent(); }); }, showWinAnimation: function() { Core.CatchRequest(Game.WinHandler.ShowUserWinRequest); $('.you_win').animate({opacity: 0}); }, ... } Game.Balance = { ChangedEvent: new Core.EventPoint, addCoinsOnClick: function() { Core.CatchEvent(Game.UI.CoinClickEvent) this.balance+=15; new Game.Balance.ChangedEvent; } ... } Game.WinHandler = { ShowUserWinEvent: new Core.EventPoint, ShowUserWinRequest: new Core.RequestPoint, watchForWin: function(balance) { Core.CatchEvent(Game.Balance.ChangedEvent) if(balance > 250) { new Game.WinHandler.ShowWinRequest; } } ... } Core.processNamespace(Game); 

अब इस कोड के साथ कुछ भी करना आसान है: नई कार्यक्षमता जोड़ें:

 //       Game.GatherStat = { sendClick: function() { Core.CatchEvent(Game.UI.CoinClickEvent); $.post('/stat/gather/ajax', {click: 1, date: new Date}); }, sendWin: function() { Core.CatchEvent(Game.WinHandler.ShowUserWinEvent); $.post('/stat/gather/ajax', {win: 1, date: new Date}); } } 

रिफैक्टर UI (दो वस्तुओं में विभाजित - UI और UIWin):

 Game.UI = { CoinClickEvent: new Core.EventPoint, handleCoinClick: function() { Core.CatchEvent(Event.DOM.Init); $('.coin').click(function(){ new Game.UI.CoinClickEvent(); }); } }; Game.UIWin = { showWinAnimation: function() { Core.CatchRequest(Game.WinHandler.ShowUserWinRequest); $('.you_win').animate({opacity: 0}); }, ... }; 

अब जब कोड तर्क के अनुसार सख्त लिखा गया है, तो कोड के साथ काम करना आसान है।

एक निष्कर्ष के बजाय

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

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