wxw_ysy

    我在把程序从silverlight3升级到silverlight4后，运行的时候发生了一种错误。
    我在m1.dll里面定义了一个Class1<P,L>它是一个泛型的类，我在另一个程序集中使用它，并且有一个方法T GetNew<T>() where T:new(){ return new T();}当我使用这个方法的时候是这样的GetNew<Class1<Point,L1>>(),其中Point是框架（.Net Framework）定义的，L1是我自己定义的类，当执行这样的语句的时候，产生一个错误MethodAccessException是在new T（）那一句，说找不到构造函数；但是当我用new Class1<Point,L1>()直接调用构造函数就找得到，值得注意的是，错误中说找不到 Class1<Point, system._canon>这个类的构造函数，而不是Class1<Point,L1>的。如果项目用silverlight3（2010）是可以的运行的，用silverlight4就不行了，运行到这里就报错，编译时候没错，不知道为什么，请教大家

     我是从2008年6月份开始推出我的qq机器人暖通小宝的，那时候我在复旦课程作业做的是msn机器人，后来在博客园里看到阿布的lumaqq.net的，一试用下就决定做一个qq聊天机器人。

      我是暖通（建筑的一小块，管空调的）行业的，所以做了和暖通行业功能，2008.06.13日起推出，一开始就挂在自己的机器上，自己开机，小宝也开着，关机，小宝就下线了。

      qq有好友上限，如果别人加机器人的时候机器人也加别人为好友，那么一旦到了上限（好像是600人）它就饱和了，所以别人加我的小宝的时候，小宝并不加别人为好友，到目前为止似乎还可以一直加，我的小宝的用户已经到了4500人了。

      2008.9月份开始我租了一个vps挂小宝，成本大啊，然后一直推广小宝，vps有一个缺点，就是会莫名奇妙重启，这样挂着好好的，就会掉线。到了09年的4、5月份时候，我换了vm，vm一直运行着不错，非常稳定。

      lumaqq.net用的是2005的协议，其中2005协议的qq关了好几个，lmaqq.net里面也经过一些调整。随着用户的增多，问题也来了，机器人掉线或者反复登录会被认为是网络不安全，或者qq被盗用，腾讯公司会要求输入验证码。但2005不支持验证码，所以只能等着，后来我发现给机器人的qq号码加一些密码保护会好一点，而且在qq号码受到限制的时候修改qq的密码会解除异常。

     一次介绍小宝的时候，有人说加不上，我申请了一个新号码试着加果然加不上，我一看小宝人数，大约1600，我以为到了上限了，就使用了4个qq号码，这样一来问题更大，四个号码不可以一齐登录的，登录两个就要等待一会儿，腾讯会认为你这里网络异常，有时候解除异常修改密码还要改四次，麻烦啊。从那时候开始我以为qq被加为好友也有上限，所以就一直没有推广。直到最近发现不是如此就又把四个号码改成1个了。

     我把加过我小宝的qq号码都记录下来的，包括加小宝的时间。我后来一直没做推广，但是从2010年开始小宝用户数量剧增，2009.12.31日用户数是2722.到了2010.2.28日是4466。看来流量这种东西，等到一定时机就会爆发。

    在前几天，我的机器人突然一直断线，登上了马上掉下，非常奇怪，我估计腾讯是放弃2005协议了，所以我以为我的机器人的寿命到了，我在网上找2008协议的开源项目，没有唉。有卖09的非常贵。

     我运气很好，认识了一个只有初二的小孩子，他说他会改qq协议，我给他代码让他改了，果然可以了，他第一次改成了2008的协议，非常不稳定，第二次改成了2009的协议，稳定了。我的机器人又活了。

      我发现我运行机器人的经验蛮多的，而他是个it高手，我们决定合作卖机器人服务。

      大家如果有兴趣包括购买开发包或者有qq机器人的项目可以找我们。保证您不会感到吃亏。

      可以发送给我邮件wss_qgg@163.com或者qq联系我77180955，

      我的机器人的qq就不公布了，因为是暖通行业的，如果大家有兴趣可以查找“暖通小宝”的昵称。

      另有一个机器人是一直挂着的：v]客机器人1404502676。大家可以加为好友试试看。

面向对象封装了变化，或者更加准确的说，应该是封装了不变的地方，留出了变化的地方可以在需要的时候再去变，那么什么地方会变化呢？

1 数据的变化

比如一个工厂生产一种纸盒子，程序要计算它的体积，需要有长、宽、高的尺寸，盒子的尺寸是固定的，那么在代码里面直接硬编码，比如长1，宽2，高3，方法返回1*2*3，甚至直接返回6，没有任何问题。现在需求发生了变化，这个工厂生产两种尺寸的盒子，另一种长2宽2高2，这时候变化的就是数据。使用变量来抵御数据的变化。我现在只要在计算体积的方法里设长宽高三个参数，在方法里返回长*宽*高就可以了。这里不变的是计算体积的过程、长宽高的变量，变化的是计算用到的数据。

 

 

2过程的变化

现在厂家又生产了另一种底面是三角形的三棱柱盒子，这时候原来计算体积的公式就不好用了。这里注意了，计算体积的这个过程是要的，但是这个过程怎么实现需要变化了。使用继承和重写来抵御过程的变化。可以把计算体积的方法变成一个虚方法，然后在继承的类里面重写它，返回长*宽*高/2。这里不变的是，必然会需要计算体积的这种行为，而这个行为的过程是变化的，行为需要的数据值也是变化的。

 

3参数的变化

厂家生产了第三种产品，底面积是圆形的，圆柱形的盒子。这时候需要的参数不是长宽高了，而是半径和高两个变量。这时候计算体积的方法已经不能用原来传入三个参数了。使用属性来抵御参数的变化。这时候我们在抽象的父类里面只要提供计算体积的无参数方法，然后在子类里面自定义不同的属性就可以了。比如在长方体盒子子类里定义长宽高、在圆柱形盒子子类里定义半径和高。等等。

 

4行为的增加

现在又有第二家工厂来找我们做程序了，它们计算体积时除了盒子的体积后还需要在加一个包装的体积。然后第三家工厂需要在体积上乘以一个1.05的材料消耗系数。虽然它也可以用继承来抵御变化，但是它并不是纯粹的计算盒子的体积了。而且各种厂家行为古怪，无法预知会有什么样子的行为变化。用事件来抵御行为的增加。在计算盒子体积的方法里面引发一个计算盒子体积后的事件，让处理事件的人可以得知计算的参数以及计算的结果，并且可以改变它。那么在为第二、三家工厂做程序时候，就可以在计算盒子体积的事件里面处理新的行为。在这里不变的仍然是需要计算体积这种行为，变化的是在这种行为后会有很多附加的行为，而且是未知的。

 

 

 

 

 

 

      MVC纵向切割了开发过程中的代码，从服务器到浏览器层层分离，层次之间耦合度很低，因为它是顺着底层的开发脉络进行封装，所以有利于开发者对整个程序过程流转的理解。但是MVC有一个非常大的缺点，这个缺点是和整个软件发展思路相背离的，那就是它无法封装、无法封装所以无法被重用。有谁看到过mvc下面的组件？有的只是一个个现成的案例，然后拿来修改。因为一个组件肯定牵涉到控制和显示，但是mvc的开发这两个层次是分离的。MVC只适合轻量级的开发，桌面开发是极少用到mvc模式的。然而web开发恰恰就是轻量级，至今所有的web开发都是轻量级的，因为网络硬件条件的限制，不需要也无法做到非常复杂的逻辑。这也是MVC非常非常适合web开发的原因。
     WebForm是微软前面一套web开发的机制。它横向切割了代码，控制和显示是封装在一起的。它从开发者思维逻辑上而不是实际情况上对代码进行封装，开发webform容易上手的原因也就在此了，但这个不利于开发者对底层程序流转机制的理解。WebForm中view和controller是放在一起的，WebForm一出现后，随之而来的是大量的组件诞生，这是mvc模式下看不到的。微软的经验之一是硬件发展很迅速。代码的封装是靠牺牲运行效率来提高开发效率，牺牲的运行效率通过提高硬件性能来解决。但微软在webform上犯了经验主义的错误，这个经验不适合网络硬件，网络硬件要考虑兼容性而且是国家的基础设施，更新的灵活性远比单机要差。大量的组件因为硬件的瓶颈无法给WebForm带来什么优势。在发展了几年webform后，微软觉得这样下去不行，等到网络硬件发展起来不知道到猴年马月了，所以就抄了一下成熟的mvc，通过Entity Framework做数据库和对象的映射，很明显，它是为了充当mvc中那个Model。通过mvc来控制和展示。
      webform生产关系是比mvc先进的，但是它不适合现在的网络设施生产力，如果要适合说不定要10年后。webform和mvc很好的印证了生产关系必须适合生产力，即使强大如微软也无法改变客观规律。
     

       我没做过大型项目，小型项目也才做了2个，就是分享些心法，也不知道对不对，希望大家指点。

       我主要想探讨一下面向对象和关系数据库的阻抗不匹配。

       数据库里各个有关系的表，其实可以合起来的，合起来就是一张表，一张很大很大的含有冗余的表。

       数据库的设计就是把一张大表有冗余的数据变得不冗余，设计数据库的时候，心里要知道那张大表是什么。

       如果数据库里只有一张表的话，操作起来会非常好办，因为表里的每一行，就是一个对象。

       为了不冗余而把大表拆分成为几个小表，那么每个小表里的一行数据的概念就模糊了，它不是一个对象。它无法映射到面向对象里面的一个对象，面向对象是不管冗余的。

       所以在程序里看到的，最好是那张有冗余的大表，而看不到那些小表，当然也不知道大表小表的关系。那么面向对象的味道就出来了，程序不去关心大表怎么拆分成小表的，那张大表就是数据库与面向对象的接口，是稳定的，接口每一行都对应着面向对象里的一个类的对象，即使大表有变化也只是增加列，而结构永远不会变化，因为程序的眼中只有一张表。

       这样的缺点就是牺牲效率，数据不是很多的项目是可以用的。

       面向对象天生就是以牺牲运行效率为代价而使得编码维护方便；关系数据库天生就是为了减少冗余，提高数据库的效率。两者永远会是矛盾，面向对象迁就关系数据库了，编码维护就麻烦些；关系数据库迁就面向对象，运行的效率就低些。小型项目，用牺牲运行效率来抵御变化是可以接受的；大型项目不妨牺牲人力成本来抵御变化好了。