设计之美——极限反射之包装器

  又是一个睡不着的夜晚，当你知道由于自己误会了一个女孩而在手上多添加了一道伤痕的时候，我相信你也会和我一样。我很想告诉他我再也不会那样做了，我发誓！但是不忍吵醒她的美梦，只能来这里写几句，也许是记录吧。这里的blog写了一周，不知道为什么，发现自己开始有点喜欢这里了，每次总能怀着一种美好的心情来写一些东西，虽然总是乱七八糟的說一堆，但是至少自我感觉还好。虽然这个系统用起来那么不怎么感觉好，但是也没感觉不好，FCKediter 貌似是这个吧，这个玩意自己开发也用了多次了，至少这样的感觉还是相当熟悉的，虽然我从不编辑任何格式，总是一口气写完然后发表了事。不过我比较喜欢google的文档系统，可以有多个历史版本，让人感觉很有安全感。google也是一个拥有良好理念的公司，虽然不知道是什么宗旨但是肯定会让人向往的。

  废话說了一堆，这里也来点实质些的东西吧——极限反射之包装器。

  这里给出一种介意，另外一种基于委托反射的解决方式，上一篇，通过一个基类来对对象进行委托保存，不好的方式其实有一点，就是无法改善原有的系统，当你有一堆类的时候我相信修改起来也许就未必轻松了，很多项目习惯于一个封装一个简单的反射类，或者再增加一点缓存来提高性能，缓存有一点坏处就是要控制引用对象的问题，我就不说了，当你遇到莫名奇妙的错误的时候估计你也会有感受的，如果简单的通过一个类来解决呢？看起来也许有点难度，在所有的object类中都有个 memberclone 这样的一个方法，内部倒是可以调用，外部用反射么？性能可未必比建立要来得快。那如何呢？ 这里提供一办法就是使用一个包装器，构造一个通用的类，把反射的对象实例包装起来，然后同样，通过建立一个有效的委托来进行，这样你可以每次建立的时候获得有效反射速度，其他方法同样适用。嗯，其实要说的也就是这么多了。

   嗯？代码？想看代码么？恩。。。好吧。。。我告诉你，没有！

   不是我懒哦，我这里新建的系统估计也用不到，如果你和我一样喜欢把所有的类找个基类偷懒你也不会为此烦恼，但是你如果真的需要的话，我建议你自己编写一个，不会超过500行的，而且同样跑得很好。

　希望大家同样喜欢这篇乱七八糟的:)

   嗯，还没完呢，多看一段，昨天晚上在设想一个有趣的东西，不知道有人有兴趣没有。

  尝试这样的一种过程，窗体－>浏览器 -> javascript －>ASP.net小型服务器

  呵呵，有人会问了，这是桌面开发还是Web开发呢？

  我尝试使用javascript做程序脚本，后来觉得多加个服务器吧，然后又发现我还需要更方便的交互，于是这个四不像的东西就出现了，不知道你有兴趣没有。

  设想一下，如果能做到这样，那么B/S和C/S的界限还有多少？仅仅是把S运行在本地 还是运行在远端的区别吧。

而且不用取管如何去编写服务，有现成的。

  想法不错，也许改天可以实践一下 ：）

  今天到这里吧，真的结束了！

  欢迎大家来做客 :)