A discussion on component design method of Visual C #

visual| Design

　　 Properties

Predefined properties for classes in C # are a simple thing to do, see Program 1.

Program 1

Using System;
Namespace Propertiesdemo
{
public class MyData
{
...............
}
public class Class1
{
Private MyData _data;
Public MyData Data
{
get {return _data;}
}
Public Class1 ()
{
_data = new MyData ();
}
}
}
This is a fairly common attribute-predefined way, but it is also a functioning program, but there is a design problem that is the time to create a MyData object. According to program 2-1, when the Class1 object was created, the _data object was created, which caused the Class1 object to pay the memory cost of a MyData object at the beginning of the creation, for simple classes or as yaks, But what if the Class1 object has a group of these attributes? To address this type of problem, lazy-allocate (slow allocation) technology is used heavily in the. NET framework, see Program 2.

Program 2 Lazy-allocate Example

public class Class1
{
Private MyData _data;
Public MyData Data
{
Get
{
if (_data = null)
data = new MyData ();
return _data;
}
}
Public Class1 () {}
}
Lazy-allocate's design concept is very simple, is not used before the cost upfront. In contrast to the pre-allocate (pre-allocation) concept used in program 2-1, program 2-2 takes a time space-swapping strategy, paying the cost of access judgments to mitigate space waste. Of course, Pre-allocate is not a good-for-nothing, no need to prejudge the fast access characteristics applicable to the user will inevitably access attributes, but on some specific properties, For example, the style attribute common in asp.net is not suitable for using the pre-allocate technique because the user does not necessarily use the attribute, in which case the lazy-allocate mode says that it can save the object some memory costs.

　　 Event

Event handling is an important part of component design where events are closely related to delegate in C #, and program 3 is a simple example of events.

Program 3 simple examples of events

Using System;
Namespace Eventdemo
{
public delegate void Processhandler (object sender);
public class Class1
{
Private event Processhandler _processhandler = null;
Public event Processhandler Processstart
{
Add
{
_processhandler + = value;
}
Remove
{
_processhandler = value;
}
}
public void Process ()
{
_processhandler (this);
for (int i = 0; i < i++)
i = i+1;
}
Public Class1 ()
{}
}
}
C # Delegate plays the role of function pointers, the user can add a function to a delegate, and a delegate allows users to join more than one function, when this delegate call is equivalent to the invocation of all the functions contained therein. However, the design of program 2-3 lurks a problem, that is, when the number of events, the object must pay the corresponding number of delegate variables, as shown in program 4.

Program 4 Traditional Event design

Private event Processhandler _processstart = null;
Private event Processhandler _processend = null;
Private event Processhandler _processstep = null;

Regardless of whether or not the user is using these events, the cost is incurred when the object is created, which is even more frightening in the window application because the number of Windows message (window messages) is in thousands, if a simple window program must pay relative to the Windows The variable cost of the number of message, so that the object is not a monster. To address this problem, the. NET framework takes a similar approach to Lazy-allocate, see program 5.

Program 5 new Event design pattern

public class Class1
{
Private Hashtable _eventlist = new Hashtable ();
private static Object _processstart = new Object ();
private static Object _processend = new Object ();
Public event Processhandler Processstart
{
Add
{
_eventlist.add (_processstart,value);
}
Remove
{
_eventlist.remove (_processstart);
}
}
Public event Processhandler Processend
{
Add
{
_eventlist.add (_processend,value);
}
Remove
{
_eventlist.remove (_processend);
}
}
public void Process ()
{
Processhandler start = (Processhandler) _eventlist[_processstart];
Processhandler end = (Processhandler) _eventlist[_processend];
if (start!= null) Start (this);
for (int i = 0; i < i++)
i = i+1;
if (end!= null)
End (this);
}
A Hashtable type object is declared in the program: _eventlist, each entity of the Class1 class owns the object, and also declares two objects of type object: _processstart, _processend, note! These two objects are static (static) types, which means that no matter how many object entities there are, it takes only two object space to be spent. So how does this differ from the 2-4 paradigm approach? The answer is that the object occupies a different memory size, and when the user creates an object entity, the object occupies a Hashtable object's memory space, and when the user sets the Processstart event, This object takes up the memory space of a Hashtable element, and if the user does not set an event, the memory space of the element is not consumed, which saves the memory cost that is not required, compared to the prepaid behavior of the 2-4 paradigm. To be more specific, assuming that CLASS1 has 1000 events, program 2-4 takes the memory space of 1000 event variables at the beginning of the object's creation, while program 2-5 pays for the cost of a Hashtable object and 1000 static variables, When a user creates a second object, program 2-4 takes up the cost of 1000 event variables again, but program 5 takes up the price of a Hashtable object. Luckily, this design concept has provided infrastructure in the. NET Framework, As long as the design staff can apply, see program 6.

Event support built into program 6. NET Framework

public class Component1:component
{
private static Object _processstart = new Object ();
Public event EventHandler Processstart
{
Add
{
Events.addhandler (_processstart,value);
}
Remove
{
Events.removehandler (_processstart,value);
}
}
public void Process ()
{
EventHandler handler = (EventHandler) Events[_processstart];
if (handler!= null)
Handler (This,null);
}
}
You can use this method to handle events as long as you inherit from the component class or its subclasses.

　　 Static Helper Object

C # is a pure OOP language, this means that it does not allow designers to declare global functions or variables, and it advocates the substitution of static functions and static variables for the use of global functions and variables, since both static and static variables are declared in the class, which forms the effect of clustering. It also leads to another type of application: Static Helper Object, see program 7.

Program 7 Static Helper Object Example

public sealed class Domainhelper
{
public static string Getcurrentdomaindir ()
{
return AppDomain.CurrentDomain.BaseDirectory;
}
Private Domainhelper ()
{}
}
............
MessageBox.Show (Domainhelper.getcurrentdomaindir ());
Domainhelper is a class that is not allowed to inherit and has a private constructor, which means that the designer cannot create or inherit this class, Domainhelper provides a getcurrentdomaindir static function to return the current application The path where domain resides, which is more than the original call to AppDomain. Getcurrentdomain. The BaseDirectory function is a much shorter way to get the same result. The central concept of Helper object is to wrap the commonly used auxiliary functions as static functions, and designers do not have to write them over and over again, component design techniques are closely related to helper object, and readers will see more examples of this type in later chapters.