对象之所以成为对象
什么是对象？    
          对象是变量和方法的结合体，它就类似于我们现实生活中的事物。    
什么是类？    
          类是具有相同属性和方法的集合，是对象的抽象。    
          这是教科书上常用的描述方法。但我认为这种描述其实是最不负责任的。这种话谁都会说。我们所以看到的书都是这么说，大概也是缘于中国的一大特色--互相抄袭的缘故。他们中的大多数作者并不理解其中的概念，人云而亦云。--只要懂字便可以出书，这便是中国的特色。    
          对于文字描述的事物（所谓的概念）和现实事物之间的理解，人脑要把它们联系起来，主观上并不容易，因为客观上它们之间是存在脱钩情况的。用计算机代码描述的对象（比如杯子）和现实存在的对象本身几乎可以说风马牛不相干。比特和原子本来就是不可联系的东西。要让我们再把由它们叠加起来的更为复杂的东西联系起来，不仅需要事先对计算机环境有所熟悉，更需要一定的想象力，通俗来说就是要让学生们明白为什么一段由所谓变量和函数组成的计算机代码就可以称为是杯子的，以便于跟现实的杯子这个活生生的东西勾结起来，虽然中间还需要想象，但这种想象已变成常人都能完成的思考能力了，我认为这就是理解对象概念的第一初始要素，也就是第一要给予关注的关键点。    
          我在看来，要把比特物和原子物这两个本不相干的东西联系起来，唯一方法就是比较，通过对比把她们硬勾结起来。如果有人试图通过演绎和推理的方式来把她们联系起来，那是比较幽默的。    
          如何比较？指导思想其实很简单，就是让学生们明白一段代码怎么看起来就是现实中的杯子或是任何一件想表达的现实中存在的东西，比如一个美女。目的就是让学生们看到代码就同看到事物，即见码如见物。    
          如何达到以上目的，这需要从一个最初始的问题开始，就是回答什么是程序和程序的功能是什么？    
          简单说程序就是代码块，具体点就是由数据码和指令码组成的代码模块。这里需要突出的是数据和指令是组成程序的两个基本要素，缺一不可。注意：单独的数据或是单独的函数是不能工作的。并且一个程序除了数据就是指令，除了指令就是数据，再没有所谓的第三种要素。    
          程序有什么功能？我们的回答是由一定量的数据码（变量）和指令码（方法或函数）组成的程序，只要给予适当的设计，理论上均可以给出任何我们需要表达的东西，这些东西的表现形式可以是屏幕模式也可以是内在的存储模式（我们想从程序得到的无非也就是这些形式的东西），它们可以是一个返回值，或是一个显示在屏幕上的东西，如文字、按钮、窗口、杯子、动画、美女等。并且由于包含了可以互为操作的变量和函数，所有这些程序都可以设计成具有响应用户操作动作（即所谓事件）的能力，如响应键盘和鼠标输入并给出相应的结果等，具体例子有命令按钮、对话框、滚动条、窗口拖动和放大缩小等。所以我们在vb里随便拉出一个控件便可以对它添加进入具有响应任意动作的功能模块就是这个道理。问题的实质是，一段包含变量和函数的代码模块里，我们把它设计成什么样的功能不可以呢？除非你想不到或是不愿意那么做。这就是我们所谓的类体或对象体（或有曰之控件、组件、部件，本质不过是一段小程序）里都可以具有所谓属性、方法和事件的原因。因为别忘了，它们是程序。
          话说到此大家可能已有所明白，实际是只要我们把编程模块也包含进一定量的数据和函数，也就具有了程序的特性，因此也自然的便有了表达任何事物的能力了，比如画杯子、窗口、美女和响应用户输入动作的对话框及勾画出一个播放器等等，也就是它实际就是一个名副其实的程序了，只是看我们想把它做成一个大程序模块还是小程序模块而已。    
          问题的要害就在于此，目前我们所谓的面向对象的编程模式实际就是基于这样的思想开发出来的，就是把编程模块都做成包含数据和函数的小程序，这些小程序在语言中我们通常用类模块来表达。而既然类就是实际意义上的小程序，那么回答对象概念就变成一件简单的事情了。→因为类是一段小程序，因此其生成的所谓对象也是一段小程序；既然对象是一段小程序，那么它便可在内存模式或屏幕模式上表达出任何我们想要的东西，如一个桌子、一辆轿车、一个人、一匹马、一个小按钮、一段文字、一部电脑、一个美女、一幅动画、一门大炮、一堆土、一堆粪便、一只蚂蚁、一件衣服等等等等，并且所有这些东西都具有响应用户操作事件，除非你不设计进去。而只要你看到这些，你敢说它不是一种我们现实生活中的东西吗？敢说它不是我们现实生活中的对象体吗？除非你不是人。
       
        附：类这东西无论在源程序还是二进制目标程序都随程序一起，属于程序的一个重要组成部分。多数对象倒是需要时即时由类生成的。    


------解决方案--------------------
正如lz 之所以是 lz

------解决方案--------------------
U道理~
------解决方案--------------------
太长
------解决方案--------------------
up
------解决方案--------------------
OO 的特性在 LZ 这里荡然无存，OO 的内涵很丰富，而 LZ 讲的太过于简化了，以至于面目全非！

抽象才是类的本质所在！

就像一些人对抽象的概念理解比较困难一样，能编码的不一定都能设计类，因为他们不知道该如何去抽象？！
------解决方案--------------------
好长。。。有心了。。。
------解决方案--------------------
呵呵，LZ 这么晚了还没睡！

那俺就陪聊几句，

首先要声明一点：抽象本身就是将复杂问题简单化的一种有效手段！

抽象的问题具体化理解——在代码中称为实例化，new MyClass()
具体的问题抽象化理解——在代码中称为类的声明，Class MyClass {...}

俺所说的“抽象”化并不是简单的模块化处理，而是识别问题域中的相关对象以及它们所属的类和类之间的关系，因为它们才是问题的实质所在。

再回过头来说说“模块化”的问题，俺的理解是如果没有经过抽象处理的模块化处理仅仅是一种机械的数据码和指令码的切块，一个大流程被分割为若干子流程；而经过抽象处理后再进行模块化处理得到才是真正意义上的类（数据码和指令码的有机组合）。

可见产品都是若干行代码，然而经过抽象处理后产生的代码就被称之为类，因为经过精心的设计它具有了诸多优越的 OO 特性！

综上所述，抽象实际上是在代码层次之上的对问题进行分析、整理的过程，而非分析代码本身，抽象的结果是概念和关系。如果需要用代码来体现这些概念和关系的话，就必须数据码和指令码，为了避免代码太长以及其他原因，需要进行模块化处理，当发现面向过程的程序不能简便地体现我们的问题时，大师们发明了类，因为它可以更好地体现我们“抽象”出来的概念