之前的是2005、2006年间在msn空间上的部分blog，觉得也许能作参考，所以搬过来了。这里打个标记。
顺便说一下msn空间，先是我的帐号失效了，后来又看到空间要关闭（因为帐号已经失效，我的空间本来也是无主空间了），记得当时与同事一起用spaces时就是看它是微软搞的，总不致于关闭，结果。。。
近来试验着重写一个C++的委托功能，就是.net里的delegate关键字描述的东东，似乎C++里喜欢说是成员函数closure，记不太清楚了。
原来的实现跟loki库里的思路差不多，就是利用虚函数描述委托函数的原型，这个原型与具体实现类无关，子类实现函数的功能，实现
里可以记住具体实现函数的类实例，现在看来没有什么很巧妙的东东了：
1、接口层，纯虚接口，与实现对象无关。
class IEvent
{
public:
virtual ~IEvent(){}
public:
virtual bool operator () (const EventArg& arg)=0;
};
2、实现层，利用模板参数化实现对象类型。
template<typename Obj>
class Event : public IEvent
{
typedef bool (Obj::*Fptr)(const EventArg&);
public:
Event(Obj* pObj,Fptr fptr)
{
mObj=pObj;
mFunc=fptr;
}
bool operator () (const EventArg& arg)
{
return (mObj->*mFunc)(arg);
}
private:
做了一个小的试验，一个DataGridView,一个BindingSource,然后用List<T>作实际的数据源。
当T为struct时，编辑功能失效，修改完按enter，cell里的内容立即恢复为初始值。
大致看了一下DataGridView的操作过程，
1、DataGridView用户操作的事件处理，比如按键、鼠标等;
2、DataGridView.CommitEdit方法;
3、DataGridViewCell.SetValue方法;
5、PropertyDescriptor.SetValue方法。
以前在用PropertyGrid时曾经研究过像PropertyDescriptor这一类.net设计时架构的关键元素，依稀记得对于struct与对object的处理有很大
的不同，于是试了试将T由struct改为class，再试，编辑功能正常。
前一阵子探讨一个项目,甲方说这个功能很简单的,只要你实现数据库表的创建就可以了,回来我一想,觉得有点不对劲,没理由只提供新建的功能的,哪里只让加,不让修改与删除的?你既然允许添加,那就意味着可以加错,错了还不让改吗?当然也就可以加多,多了还不让删吗?如此看来,增删改的功能是一体的,进一步,有了增删改,暗含着就需要提供浏览的功能了.
现在从形式化一些的角度来看,
增加 => 删除 | 修改
反过来
删除 => 增加 | 修改
修改 => 增加 | 删除
换句话说,这几个功能是对称的,并且是传递的,这样一来就很接近于等价关系了,当然,功能是个很泛的说法,没有数学上的关系那么精确,不过我确实感觉到这三个功能事实上形成
近来做项目时发现一个继承关系失效的情形，感觉应该还是比较常见的。
我们的项目中有一个水利上要用的点、线、面的概念，它们是在传统的几何所说的点、线、面的基础上扩充了相关的水利方面的属性，从概念上粗略看，带有水利属性的点也是一个几何意义上的点，带有水利属性的线也是一个几何意义上的线，带有水利属性的面也是一个几何意义上的面，似乎是很合适的继承关系，所以一开始我也就这么认为了，结果在细化时遇到了麻烦，麻烦出在研究点、线、面的关系的时候。
我们首先按继承考虑，所以有一个几何意义上的点、线、面层次，也有一个水利意义上的点、线、面层次，后者分别是前者的子类，现在来看横向的关系，在几何意义上线由点组成，面由线组成，所以存在一个组合关系，我们为几何意义层次的点、线、面加上这些关系：
几何意义层面的类：
class Point
{
}
class Line
{
Point[2] points;
}
class Plane
{
Line[] lines;
}
水利意义层面的类:
发博文
加载中…
