.Net 4.0 पर कोडोरबस या पैटर्न "रणनीति"

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

Action<Action> action = (Action action) => { action(); }; 

इससे पहले कि आप हैब्रैट के नीचे देखें, कुछ सवालों के जवाब देने की कोशिश करें (आइए दिखाते हैं कि आपने पोस्ट का शीर्षक नहीं देखा है):

• इस कोड को किस भाषा में लिखा गया है?
• क्या वह वाक्यात्मक रूप से सही है? क्या यह संकलन करेगा?
• क्या यह कोड समझ में आता है? वह क्या कर रहा है?
• ऐसा कोड क्यों लिखा जा सकता है?
• इस कोड को कैसे सुधारा जा सकता है? (आप इसे कैसे लिखेंगे?)
• इस कोड के लिए वास्तविक उपयोग के मामले दें।
• इसका उपयोग करते समय क्या संभावित समस्याएं उत्पन्न हो सकती हैं?

क्या आपने जवाब दिया है? फिर हम पृष्ठभूमि और स्पष्टीकरण के लिए कैट के नीचे गोता लगाते हैं।


मुझे तुरंत कहना होगा कि यह C # के तहत .Net फ्रेमवर्क 4.0 में लिखा गया एक पूरी तरह से काम करने वाला कोड है। बेशक, हमने जानबूझकर इसे मज़ाकिया पलट के रूप में बदल दिया, उत्पादन कोड में ऐसा दिखता है:

  private Action<Action> doWork = work => { work(); }; 

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

  public class MyWorker { private void DoWorkInternal() { Thread.Sleep(1000);//simulate work IsWorkDone = true; } public void DoWork() { DoWorkInternal(); } public bool IsWorkDone { get; private set; } } 

और एक परीक्षण जो काम के परिणाम की जांच करता है:

  [TestMethod] public void TestDoWork() { MyWorker worker = new MyWorker(); Assert.IsFalse(worker.IsWorkDone); worker.DoWork(); Assert.IsTrue(worker.IsWorkDone); } 

समय के साथ, युद्ध की परिस्थितियों में, यह पता चला कि DoWorkInternal विधि लंबे समय तक चलती है, और इसके निष्पादन का परिणाम आवेदन के आगे के संचालन को प्रभावित नहीं करता है (यहां आप अनुमान लगा सकते हैं कि यह क्या कर सकता है)। स्वाभाविक रूप से मैं इसके निष्पादन को अतुल्यकालिक बनाना चाहता था:

  public void DoWork() { Task.Factory.StartNew(DoWorkInternal); } 

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

  public class MyWorker { private Action<Action> doWork = work => { work(); }; private void DoWorkInternal() { Thread.Sleep(1000);//simulate work IsWorkDone = true; } public void DoWork() { doWork(DoWorkInternal); } public bool IsWorkDone { get; private set; } } 

यानी तुल्यकालिक संचालन की रणनीति इस प्रकार है:

  (Action work) => { work(); } 

अतुल्यकालिक निष्पादन के लिए रणनीति:

  (Action work) => { Task.Factory.StartNew(work); } 

हमारी कक्षा में ऐसी विधि जोड़ें जिससे आप डिफ़ॉल्ट (सिंक्रोनस) की रणनीति को दूसरे में बदल सकें:

  public void SetDoWorkStrategy(Action<Action> doWork) { this.doWork = doWork; } 

हो गया। सबूत के रूप में परीक्षण करें:

  [TestMethod] public void TestDoWork() { MyWorker worker = new MyWorker(); Assert.IsFalse(worker.IsWorkDone); worker.DoWork(); Assert.IsTrue(worker.IsWorkDone); MyWorker worker2 = new MyWorker(); Action<Action> asyncWorkStrategy = (Action work) => { Task.Factory.StartNew(work); }; worker2.SetDoWorkStrategy(asyncWorkStrategy); Assert.IsFalse(worker2.IsWorkDone); worker2.DoWork(); Assert.IsFalse(worker2.IsWorkDone);//work is in progress } 

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

दिए गए कोडबोर का पीएस चर्चा .Net डेवलपर की स्थिति के लिए एक उम्मीदवार के साथ बातचीत के लिए एक अच्छा विषय हो सकता है