求教：自定義一個類Tester，其中定義了一個事件：StateChanged，在Form1中new一個Tester，并且+=注冊StateChanged事件，提示的默認事件處理方法名為：Form1_StateChanged，也就是說Tab兩下后出來的方法為Form1_StateChanged，如何讓默認的方法名為Tester_StateChanged，而不是必須每次手動改，謝謝各位
uj5u.com熱心網友回復：
沒有必要，Forn1 并不知道你要注冊的函式名稱從何而來，最合理的當然是自己類里定義的函式（即默認函式前綴為 Form1，這樣不會引起誤解）。uj5u.com熱心網友回復：
uj5u.com熱心網友回復：
這個可能需要買下微軟。畢竟“不必須每次手動改”的需求能每一個程式員都能提出幾十個，眾口難調。uj5u.com熱心網友回復：
實際上，我覺得 .net 中的可修改配置、甚至直接用注入的動態太多太濫，引起各種底層技術爭論，已經對小白跟其它技術體系競爭造成了不好的影響。過去的 vs 下的框架總是提供相對簡單直觀的一套千錘百煉測驗好、中上等的默認引數，而且基本上不讓修改（要修改就得去手動修改注冊表），挺好的。實際上你可以選擇更簡潔的編程理念，例如匿名、顯式委托。例如
control.evt += (s,arg)=>或者
{
.....
};
var myProc = new EventHandlerXX( (s,arg)=>
{
.....
});
ctr1.evt += myProc;
ctr2.evt += myProc;
......
ctr1.evt -= myProc;
ctr2.evt -= myProc;
你想給處理程序起名字，就先“獨立”擁有這個程序物件。
uj5u.com熱心網友回復：
改是可以改的，比如我們用Resharp自己定義模板但是其實不建議。假設我有兩個控制元件，然后呢。
你覺著我應該寫成
object1_load
object2_load
還是應該寫成
form1_load1
form1_load2
uj5u.com熱心網友回復：
是的，處理程序是屬于 Form1 的而不是 Tester 的。這里起名字能說明 lz 對于事件的概念還是有誤區。在 Tester 所屬型別上定義事件，那么事件的介面定義都在 Tester，觸發也在 Tester。這樣 Tester 就是一個服務，而 Form1 是個宿主（客戶）。是 Form1 定義了處理程序，而 Tester 只是定義了介面規范。
uj5u.com熱心網友回復：
如果你在 new 一個 Tester 之后，宿主程式需要為它分別掛接2個甚至3個處理程序，你用“按Tab兩下”也還是沒法生成。你得寫 += ...... 這樣的代碼。所以別糾結 vs 的工具的問題。用 c# 語法去創造點代碼風格，就好了。uj5u.com熱心網友回復：
做起來很麻煩的。首先，你要理解如何擴展VisualStudio，可以先閱讀：
【開始開發 Visual Studio 擴展】
https://docs.microsoft.com/zh-cn/visualstudio/extensibility/starting-to-develop-visual-studio-extensions?view=vs-2019
然后，要理解Designer宿主設計架構，比如可以先閱讀（標記為dotnet2.0，但概念相同）：
【Create And Host Custom Designers With The .NET Framework 2.0】
https://docs.microsoft.com/en-us/archive/msdn-magazine/2006/march/create-and-host-custom-designers-with-the-net-framework-2-0
然后，你就可以通過實作IEventBindingService介面，并自定義其中的CreateUniqueMethodName，來按照你自己的規則生成你想要的事件回應函式名。
最后，安裝你開發的Visual Studio擴展，從此享用“不是必須每次手動改”的快樂;-)
uj5u.com熱心網友回復：
sp1234前輩你好，經常看到你說事件驅動，然后也看到訊息驅動，想請教一下，1：事件驅動的其一優勢是避免輪詢檢查（比如對值變化）的頻繁操作？2：事件驅動和訊息驅動的區別是啥？謝謝
uj5u.com熱心網友回復：
你可以反過來，先寫Tester.StateChanged += Tester_StateChanged;
然后因為Tester_StateChanged沒有，所以代碼補全，生成一個Tester_StateChanged的空方法
uj5u.com熱心網友回復：
事件的“優勢”這個簡單說出來也真的是眾口難調。而當你做專案、做架構時其實又是那么“自然而然”。當你設計一個物件，你想設計擴展介面，自然用委托屬性，進而用更標準的事件語法。如果寫public xxx StateChanged;（這里的xxx是一種委托）定義，那么任何宿主就可以寫代碼
Tester.StateChanged = aaa;來篡改委托了。而 Event 關鍵字告訴編譯器，不允許隨便修改這種委托，只能用 +=、-= 等少量語法，保護了安全性。
委托物件實際上在編譯之后會變為一種“符合委托串列”，也就是說盡管定義 StateChanged是一個委托，真正 c# 產生的代碼其實是一個“委托管理”物件，可以給它插入多個實體物件。這也是方便了 Event 的實作。
從設計模式上說，事件是通知的標準形式。然而如果你看《設計模式》這本書的作者四人幫（GOF）在上個世紀90年代并不懂事件機制（雖然那個時候微軟的 vb 1.0 for dos 早已經用事件機制來架構界面開發模式了），因此它寫了20幾種模式。實際上如果使用事件，那么那本書起碼可以縮小80%篇幅。事件是作為服務的一方主動回呼——通知——客戶宿主，它跟宿主代碼輪詢、不顧死活去沖擊人家服務是相反的。一旦有準確及時的通知機制，后者就會被精簡到原來的百分之一、千分之一，隔很長時間才輪詢一下了。
軟體工程的設計不要“為了編代碼而編代碼"。c# 代碼固然可以佐證軟體工程概念，但是軟體工程概念高于編程語言。當 c# 語法離良好的軟體工程需求過于離譜的時候，我們可能就拋棄 c# 語言而去選擇更好的語言了。因此先要了解“事件”的機制，去看看各種編程語言是如何定義和使用事件的，不要只糾結一種語言。脫離開某種編程語言而根據工程設計來寫代碼，才能更好地使用編程語言。
uj5u.com熱心網友回復：
復合委托串列我經常拿微信舉例子，微信假設有20萬臺服務器，幾十億用戶每一個用戶都連在某臺服務器上，當用戶A給用戶B發送訊息的時候，訊息最終推送給B用戶終端，可見只有服務器到B終端的一跳事件。而一些培訓班上的“專案”竟然教人說微信是B每隔1秒鐘去輪詢服務器去取訊息，這只能是當作一個練習，可見如果幾萬個用戶都是1秒輪詢一次“一臺”服務器，那么別說服務器，這時候網路早就癱瘓了。更何況20萬臺服務器呢？
事件是最基本的設計。能把初學的時候的那種訊息控制的思路“倒過來”，就好像你吃東西從被填鴨變為自己選擇營養，是個巨大進步。
uj5u.com熱心網友回復：
+=的時候改下不就是了，又費不了少事。不過VS自動生成的代碼確實丑，如果表單里有幾十個事件，那代碼簡直讓人反胃，還好有Lamda和Command模式。轉載請註明出處，本文鏈接：https://www.uj5u.com/net/24525.html
標籤：C#
上一篇：vb.net小白求救
下一篇：Chromium開發的那些事