发条橙子

                                     .net真的不用管内存吗？

         上周拜读了<你必须知道的.net> ,获益良多,现在只看完了一章，和中间IL描述的章节，很精彩，自己总结一下第一章的一个观点(原话已经不记得的了)：

所有对象存活，运作的平台就是CLR(Common language runtime),这句话我琢磨了很久，加上最近自己写的代码中出现的一些有趣的现象，让我对.net有了一些有趣的想法。拿来和大家分享下，以证谬误，求得真知。好，闲话不说了。先拿出自己碰到写程序时碰到的一个小插曲。和大家聊聊。

         先聊一下List<T>

         MSDN上的解释Represents a strongly typed list of objects that can be accessed by index. Provides methods to search, sort, and manipulate lists.        

         我的理解：List<T>存储具有相同数据信息类型的列表，这个对象提供对这个列表的增删改查的功能接口。

         请大家看一下我碰到的一个对List<T>操作时碰到的有趣的问题，我把它贴出来，我想看到这篇文章的人有很多已经碰到过这个问题：

        稍作说明：Error1 编译错误，Error2 ,Error3 运行错误。话说回来，这个编译器还是很强大的。至于为什么第一个是编译错误，第二，三是运行时错误，我觉得这也是一个有趣的问题，如果那个大虾还是小虾有见解的话，叫上我一起讨论下。在语义分析阶段，不能发现第二个和第三个错误吗？

        我们先不管软硬件问题，先看逻辑分析：

         List<T> 列表的意义，和我们去超市买东西都会拿到这个东西，里面有时间，日期，价格，商品，等等，每一个信息类型基本都是一样的。记录我们的购买信息，我们假设拿到了这个列表，我们从第一行遍历看起，第一个，第二个，第三个。。。。。。第n个。突然兴奋的发现。超市的机器发生了错误。把原本1.00元的产品，读成了0.01元。我的天！走狗屎运啦。我们兴奋的拿笔自己修改这个选项。回家可以兴奋的向你女朋友邀功。今天省了0.9毛哦。

        我们看这个过程，遍历，修改其中的一项。逻辑上成立吗？一点问题都没有， 信息传输正确吗？当然。我们记录了我们修改的信息。这次我们对信息的修改完全正确无误。并用遍历，修改的逻辑完成了一次完美的操作。

       那为什么把这个工作交给.net，它就干不了？

       以下分析纯粹是个人理解，没有经过事实的佐证。如果那位有正解，在对本人想法嗤之以鼻的同时，万望贴出自己的想法。

       我想从机器读我们写的上面的高级指令开始分析

       编译它，形成IL代码，这个IL 其中，蕴含了什么信息。此次，限于本人时间和水平有限，请那位说明一下 。如果读到此贴的大虾。写过了解C#编译有什么特点，请贴出，本人除了知道语法，词法，语意原理，大概是什么流程结构外。没有动手实践过，所以此步完全靠原理分析。略过

       中间IL

       (请那位有空补上)

       最后的执行猜测

       内存中数据与指令的猜测。

 稍作说明：左边为数据堆栈就是List<T>，右边为对数据进行操作的指令就是add(),delete(),move()....最后形成的指令集合。下面单独拿出一个块获取数据堆状态，这个图是一个数据逻辑图，我自己猜测的。不是汇编指令形成的物理结构图。不讨论寻址，指针级别的内容。

     回到最初，为什么？foreach()之中不可以delete,remove,modify

     返回头我们想想，如果它支持在foreach的时候改，增，删 的话又要做些什么工作呢？

     比如要删一个。

     程序大概要做几件事情：第一 ：记录数据堆删之前的状态，第二做数据处理，copy历史记录，第三：执行操作，第四：将新的数据堆返回给原地址或压根就改个读的首地址得了。如果，其它对象引用了这堆数据操作就更复杂啦。这几步只是我个人的一个理解模板，如果真要深究，什么地址，算法，压栈，出栈什么的，程序要做的事情就更多了。

     回到我们发现这个问题的起点。以及OO的理解，有趣的问题就会接总而来，如果，你写程序的时候，模拟我上面讲的那个修改账单的过程，用OO思想又怎么样设计呢？ 把人做一个对象，把账单做一个对象？我想如果是一个非程序员，让他或她用面向对象的思想分析一下。至少有一半的人会这么分解这个对象图。那如果我们也这么分解。有没有这么问题？这中间是不是少了有价值的分解。如果那样分解的话，软件平台，机器能不能直接理解我们的程序意图，支持不支持呢？

    想起我上一次发的那个帖子，从设计，数学，指令，甚至从哲学上来看OO.OO 实在是一个强大又非常难控制的思想。 我们是不是需要在学习了解精美的设计模式之外，去理解程序，甚至数学的本质，那样是不是能让我们更有效的去掌控这个平台的威力。

    另外提一下：如果用for(int index = 0; index < myList.count; index++) 这种方式去执行上面那短程序，结果有会不一样。

          设计阶段

         Public  Class Chessboard :Status: Color , Schema  Function : Run(); HandleError();

          怎么办？

          这就是我的亲身经历。我开始反问自己。到底什么是对象。对象就是你写的那一长串不加注释就很难读懂的字符串？对象就是你脑子里面描述的一个抽象概念？对象是什么？到现在为止，我也没有找到一个合适的概念去理解它。只能从几个侧面去想想。

从我目前的经验来说，我认为在需求分析，功能分析等等的最初阶段，就压根儿不用考虑计算机的问题，这种工作最好让市场人员来做。用一个一个的对象把客户的要求描述出来，比如说上面的棋盘和棋手，（在这我只是描述我的观点与线程设计回溯设计无关），客户想干嘛，想得到什么，客户是什么类型，。。。这些信息组合起来。得到一张最原始的需求图。同时对更改留下一部分的接口空间。这个图与计算机无关。

拿下棋的例子来说：我们需要用数学模型讲。棋手，棋盘，棋子，下棋的动作，棋盘面，甚至颜色，这些数据元素用结构严整的数学模型描述起来。建立一个健康的数学模型

         另外我的感觉是：

        面向对象的设计和代码编写，对程序员的要求更高了，它需要程序员掌握很多的设计，数学，硬件知识，我见很多人说，程序员离底层原来越远了，我实不以为然，不管是现在的面向对象还是将来面向服务啊。或什么的。要求程序员对机器的掌控能力更强了。机器是死的，软件是活的。拿现在的例子来说。对象这个数据类型设计容易，还是原来的只有int ,double.。。。设计容易？你可以很容易掌控int 在内存几个字节，在那.那，一个对象呢？用对象这个数据类型来处理对象容易，还是1+1 =2 容易？接触底层的意思不是说。一天到晚的敲汇编。就是接触底层了。如果，那一天，计算机硬件不用二进制了呢？程序不用键盘写了呢？cpu不用电平或脉冲信号了呢？是不是我们所学的就没有用了？计算机也只是工具而已。