Learning the Observer pattern again today inspired my thinking. The process monitoring program has written a few before, which is a different way of thinking, using delegates and events to implement. I have used the serial number to mark the key steps, to facilitate the rationalization of ideas. The code is as follows:
usingSystem;usingSystem.Collections.Generic;usingSystem.ComponentModel;usingSystem.Data;usingSystem.Diagnostics;usingSystem.Drawing;usingSystem.Linq;usingSystem.Text;usingSystem.Threading.Tasks;usingSystem.Windows.Forms;namespaceprocessmonitor{ Public Partial classProcessmonitorform:form { PublicProcessmonitorform () {InitializeComponent (); //ADD the processes into the combox. varprocesses =process.getprocesses (); foreach(varProcessinchprocesses) {PROCESSCOMBOBOX.ITEMS.ADD (process. Processname.tostring ()); } } //The method that starts the monitor. Private voidStartbutton_click (Objectsender, EventArgs e) { //4.Register the monitor.ProcessExit + =NewProcessmonitor (proexit); //Start the check.checkprocess (); } //The Mothod that checks the process. Private voidcheckprocess () {BOOLFlag =true; Do { varprocesses =process.getprocesses (); intCount =0; foreach(varProcessinchprocesses) { if(string. Compare (process. ProcessName, Processcombobox.text,true) ==0) {Count++; } } if(Count = =0) { //5.The event appears.ProcessExit ( This,NewEventArgs ()); Flag=false; } } while(flag); } //1.The delegate that monitor the process. Public Delegate voidProcessmonitor (Objectsender, EventArgs streventarg); //2.The event that encapsulates the delegate. Public EventProcessmonitor ProcessExit; //3.The method that the delegate calls. Private voidProexit (Objectsender, EventArgs streventarg) {MessageBox.Show ("The target process has been dispeared."); } }}
In order not to voluminous, the effect is simple implementation, the actual work can be arbitrarily extended (select the process, click the Start button to monitor. ):
Popup prompt when target program disappears:
Attach a release of the delegate and the event, the code is as follows (the implementation effect is the same):
usingSystem;usingSystem.Collections.Generic;usingSystem.ComponentModel;usingSystem.Data;usingSystem.Diagnostics;usingSystem.Drawing;usingSystem.Linq;usingSystem.Text;usingSystem.Threading.Tasks;usingSystem.Windows.Forms;namespaceprocessmonitor{ Public Partial classProcessmonitorform:form { PublicProcessmonitorform () {InitializeComponent (); //ADD the processes into the combox. varprocesses =process.getprocesses (); foreach(varProcessinchprocesses) {PROCESSCOMBOBOX.ITEMS.ADD (process. Processname.tostring ()); } } //The method that starts the monitor. Private voidStartbutton_click (Objectsender, EventArgs e) { //Start the check.checkprocess (); } //The Mothod that checks the process. Private voidcheckprocess () {BOOLFlag =true; Do { varprocesses =process.getprocesses (); intCount =0; foreach(varProcessinchprocesses) { if(string. Compare (process. ProcessName, Processcombobox.text,true) ==0) {Count++; } } if(Count = =0) {proexit (); Flag=false; } } while(flag); } Private voidProexit () {MessageBox.Show ("The target process has been dispeared."); } }}
The release of the delegate and event version of the code is significantly less than the number of delegate and event code, why should we choose to use delegates and events to do this thing? In what circumstances is it more appropriate to use delegates and events as a way to accomplish this? The book says that delegates can improve the extensibility of the method, yes, that's right, it's just because it's more advanced! Personal opinion ha, in the case of small amount of code, the future does not need to expand the method, do not have to use the way of delegates and events to complete, directly invoke the method is good. If I say it wrong, please correct me.
C # implements process monitoring through "delegates and events" and contrasts with "normal way"