==========
以下是引用 精灵 于 2011-11-7 9:34:02 发表的文字:
非常感谢谢老师的指点，我是否可以这么理解“this.BiblioStatisForm.Channel”，“this”是代指“MyStatis”类，而这个类本身叫什么其实并不重要，它可以叫任意的名字，只要不与系统内置类名冲突就行（这里使用“this”其实是便于移植脚本，因为无论“MyStatis”这个类叫什么“this”始终成立）。这个类是“BiblioStatis”的派生类，而“BiblioStatis”本身只是一个接口类，“this.BiblioStatisForm”其实，是在调用“BiblioStatis”这个接口类中的“BiblioStatisForm”这个成员，而这个成员来自“BiblioStatisForm”类的一个实例，而“Channel”是“BiblioStatisForm”类中的某个类的实例，所以，“this.BiblioStatisForm.Channel”其实是“MyStatis”调用“BiblioStatis”类中的“BiblioStatisForm”这个类的“BiblioStatisForm”实例中的“Channel”实例，而后面的一些函数都是“Channel”这个类中的方法。。。。。
==========
对。
不过在一个类中书写函数代码的时候，在成员函数中，说类(实例化以后的对象)自己是this恐怕是一个唯一的做法，没有替代办法吧。
为二次开发服务的一次开发代码，一个重要任务是维持以前的二次开发脚本代码的兼容性。这需要动用语言的各种设施来确保。脚本代码需要的通常是一种“形式主义”地兼容，并不深究OM的细节实现方法。
我这里举两个例子：
1) 一个类以前的成员是普通的类变量，后来改为getter / setter方式存取的成员。或者反之。从脚本源代码的角度，这没有什么区别，只要能照常编译通过就可以了。
例：
以前是
public class SomeClass
{
public MainForm = null;
}
后来修改为：
public class SomeClass
{
private MainForm m_mainForm = null;
public MainForm
{
get
{
return this.m_mainForm;
}
set
{
this.m_mainForm = value;
}
}
}
2) C#在某个版本以后增加了函数参数的缺省值能力。可以将原有的函数扩展后，保持调用处的兼容。
以前是：
public void TestFunction(string s1)
{
....
}
后来修改为：
public void TestFunction(string s1, string s2 = null)
{
....
}
目前dp2系统中的脚本代码都是即时编译的。这为脚本代码的兼容提供了更大的空间。因为这只要求“源代码”级的兼容，只要能重新编译通即可。比要求“二进制的兼容”例如已经编译好的DLL之间的兼容要简单很多。
~~~
有二次开发接口的产品项目，由于二次开发的需求和特点，就等于为项目上了一个紧箍咒，如果这个项目运行不错，那么我们可以认为它的水平要维持在某个较高的线以上。
这正是某些优秀的项目经理所希望的效果。有点像时下常说的“倒逼”概念 --- 项目的基本特征和用户的需求，逼迫项目水平至少要在某个线以上。
为了要服务于二次开发，开发人员时刻要想着对象模型怎么向用户解释和推行，理解这些概念的代价有多高，变量的命名规则该如何通俗...。好像项目被装进了一个透明的盒子，提供电视台24小时直播，一点一滴都会被用户看在眼里。
水平在某个线以下的公司和项目小组，根本不敢碰这个领域。本来就是一团乱麻的源代码和架构设计，如果再提供给用户“二次开发”，该是多么可怕的一种“社会实践”。当然，反过来说，如果公司创始人和技术骨干能意识到这种倒逼的价值，引入外力强力脱胎换骨也许是一种坏事变好事的机会，但风险非常大，可能会陷入一种邯郸学步的境地 --- 旧的方法破坏了，新的方法还没有建立起来...。
数字平台当然不是主要取这种额外的“效果”而用二次开发这种特性的。因为让产品总是具有二次开发能力，是其设计师职业生涯的一个恒定的追求。从dt1000中完全自己设计的dtscript脚本语言，甚至追溯到这个的前身 --- DOS版就开始的打印卡片专用语言的尝试，很早就开始了这方面的努力和渐进的过程。也可以说“吃的就是这碗饭”，既然这样，所以正作用副作用也都不觉得有什么了。