窗体类的成员变量 CQ

窗体类是一个很特殊的类，这个类有由于要响应界面控件的事件，所以这个类的入口除了构造函数，公有成员方法，还有事件处理方法。我之所以很关心窗体类的成员变量，那是因为它具有的类似全局变量的负面影响，不能忽视。

虽然我们用private把窗体的成员变量的作用范围已经变得很小了，但是它仍然可以被类的其它成员方法随读写(除了readonly,const)例如下面一段代码：

 1//窗体成员变量声明
 2private long mTableCount = 0;//桌子数量
 3
 4//在Load事件处理方法中
 5private void Form_Load(object sender, EventArgs e)
 6{
 7   GetTableCount();
 8
 9   .
10
11   if (mTableCount > 0)
12   {
13       Label1.Visible = true;
14   }
15   else
16   {
17       Label1.Visible = false;
18   }
19}
20
21..
22//获取桌子的数量
23private void GetTableCount()
24{
25   long tableCount;
26   .
27   mTableCount = tableCount;   
28}

在上面的代码中，对成员变量mTableCount的写操作看起来很畸形，但是是滥用成员变量的一种典型。
这样写代码至少有下面两个问题：
1、逻辑不连贯。在Form_Load函数中，可以看见对mTableCount的读操作，确看不见对它的写操作。只有打开GetTableCount的定义后才会发现。
2、代码的负面效应。这种负面效应通一般的全局变量的负面效应是一样的。你不容易发现它在什么地方被读取，在什么地方被赋值。这样造成的后果是，代码逻辑同数据的关系不紧密，代码逻辑同数据关系的松散就很容造成数据被错误处理。

那么该如何处理类成员变量呢？这个问题值得讨论，我在这里也发表一下自己的看法：
在文章的开头，我就提到了窗体处理类的入口，我认为类的成员变量只在入口处被读取和写入，如果其它非入口方法要读取类成员变量，那么只能通过参数传递。这样写出来的代码的逻辑关系的清晰度将会大幅度提到，代码处理逻辑的出错率也会降低不少。
例如以上的代码可以重构成：

//窗体成员变量声明
private long mTableCount = 0;//桌子数量

//在Load事件处理方法中
private void Form_Load(object sender, EventArgs e)
{
   mTableCount = GetTableCount();

   .

   if (mTableCount > 0)
   {
       Label1.Visible = true;
   }
   else
   {
       Label1.Visible = false;
   }
}

..
//获取桌子的数量
private long GetTableCount()
{
   long tableCount;
   .
   return tableCount;   
}

个人的一点想法，没有考虑到的地方，还希望同各位同行多多交流！