面向对象的疑惑(200分)

>>我是一只小小鸟,
你能不能详细的说一下你的想法？谢谢！！！！

感觉你应该设计一个雇员类，该雇员类有其自己的属性。
而你的Employee应该是一个容器类，这个容器类应该按部门的编排设计成树结构。
其叶节点就是每个雇员。
同时Employee还维护两个链表分别是排班表、考勤，在每个链表项中都有一个雇员类指针或雇员的ID。
而且私下里认为考勤应该作为雇员类的属性，只有排班需要另外考虑啊。

>>wk_knife
这样有什么好处呢？我不太明白你所说的！可以详细点么？

随便说说,希望对你有帮助
现在的问题是,你把表类做为雇员类的一部分了,也就是他们是组合关系,你有可能是在雇员类的构造函数中生成表类.这样就使得它们有了共同的生命周期.类和类之间是一种强耦合的关系.
改进
只在雇员类的需要使用表类的过程中构造表类,并使得表类的生命周期和过程相同,也就是使用局部变量建立对象.这样做类和类之间是依赖的关系.它们的耦合度比组和关系要小.
如果表单是唯一的,及所以员工都用一张表.那可以在程序中独立的构造表单类,并使得他的生命周期和程序一样长.使用singleton 模式建立的类可以保证在一个进程中只有一个对象存在,并提供一个全局访问点来访问这个对象.这样表类的生命周期和雇员类无关了,类和类之间是合作的关系.它们之间的耦合度是最小的.

>>难道要有两个成员变量记录他的考勤记录、排班表是否加载的内存中？那样的话，如果在没加载之前，正好新增加了考勤记录，并且这些考勤记录已经存到数据库中了，这时我需要所有的考勤记录，是不是需要把链表中的考勤记录先删除，在从数据库中加载所有的考勤记录？
个人觉得，这样的面向对象是可怕的。
个人认为，面向对象编程，是编程技术向现实世界学习，以便更有效的编程和管理。但未必真能模拟现实世界。
比如你的Employee类，如果某天又增加了一个“Email”的属性，那你是不是又要在类里添加一个“Email”的成员呢，其实说穿了很简单，只不过表里多了一个字段而已，在程序中，能编辑查看就行了，最复杂不过来个点击后自动发邮件，真要去模拟现实世界，那这个类有多累啊。
再一个，把“考勤记录”加载到链表中，多可怕啊，有现成的数据集控件不用，干嘛还要自己去控制链表呢？
我觉得，编程中的“类”，就是封装编程对象，比如窗体、控件、功能模块什么的。如果象刘艺书中说的封装什么“车、汽车、自行车、赛车”，用来讲学玩玩还是可以的，因为只不过是在屏幕上显示了几个对话框，提示什么“正常在启动、正在加速，正在刹车”，实际的“启动、加速、刹车”让他模拟一下，累不死才怪。真正的模拟现实，简单的一个空气中自由落体轨迹，就累死人!

to pyzfl,说得好。
这也是正是我学买类的迷惑之处。

to pyzfl
如果你只是编一个小的桌面系统,如果程序永远不要升级或者你一直是它的管理者.那么使用面向对象编程或面向功能编程都能完成你的要求,甚至使用面向功能编程可能还跟快.
正如你所说的"面向对象编程，是编程技术向现实世界学习，以便更有效的编程和管理。但未必真能模拟现实世界",但是它是目前所有编程思想中最接近现实世界的.
刘艺的那个例子是用来说明类的继承的,当然没什么实用价值.现在我们假使有一个项目,使用计算机去模拟车的碰撞实验,要求可以用于所有的车包括汽车,摩托车,赛车(甚至是还没有设计好的),自动挡的或手动档的.试试看去构架这个程序.
如果一个表的的结构有改变比如你假设的增加一个Email字段,那无论你是否封装了Employee类,程序的界面,业务逻辑都必须改变.

增加一个Email之类的字段，其实很小改变的。
比如我们存储个人资料，原来只有编号、姓名、出生年月、性别几个基本字段；假如有些客户提出要添加电话、传真、地址......，那就加字段了，如果是用DBGRID来显示的话，程序、界面根本不用改。
如果又有客户要求添加什么身高、体重、血型、配偶、父母、三围、习惯、爱好、个人帐号、...。

是的,dbgrid是不要改变,但程序不是只显示数据,还要添加记录,修改记录,使用记录,如那个email不改变程序你能实现自动发邮件吗?对一个大的项目,不可能将所有的功能都用dbgrid实现,在上面我也有提级
"如果你只是编一个小的桌面系统,如果程序永远不要升级或者你一直是它的管理者.那么使用面向对象编程或面向功能编程都能完成你的要求,甚至使用面向功能编程可能还跟快."

昨天突然有事，没打完，我的意思是说，如果真的突然要添加一些字段，而且这些字段和业务逻辑关系并不大，但对用户来说，是资料一部分扩充。
如果用一般的方法，也就是数据表加字段，应用程序中相关数据集添加字段(如果是提前指定的话)，界面上添加相应的显示编辑控件(可能大部分是DBEdit之类的吧)。这样就行了，而新增、删除、编辑的操作，早在这个数据集中就处理好了的,这样很简单吧。
但如果用面向对象方法呢？无论添加什么字段，是不是都要打开Employee类，添加相应属性，再添加相应的Set、Get过程，再到进行上面说的一般过程(这一过程大概不能省吧，难道你的类能自动添加字段引用和界面控件？)，然后还要测试这个类和其它类的耦合度，......。不知是不是真有人这么做过？反正我是想着就累。
再一个，如果真用面向对象方法编辑Employee数据时，如果我想从某个员工移动另一个员工时，那是不是要把前一个Employee实例消毁，然后再创建另一个Employee实例呢？再一个，我查看某个员工资料时，可能只是查看他的一般资料，如果真是那样建立实例的话，那么他的那些考勤记录真有必要读进来吗？读哪段时间的数据呢？全部肯定是不可能的了，但如果我想查看刚好不在预先读取的范围之内的考勤记录，那又怎么办呢？
另外我觉得你说的“小的桌面系统”，是不是有点吓唬人的味道，什么是“小的桌面系统”？与之对应的是什么东西？是不是99%的人没见过呢？是不是请你描述一下？
麻雀虽小，五脏俱全，应该基本原理是一致的吧。

不好意思,可能我的语气有问题.“小的桌面系统”不是什么高深的东西,比如一个单机版的仓库系统,我曾经写过一个,就象你描述的那样,使用数据库感知控件.开发速度很快,功能也能满足要求.实际上对小的两层C/S也能达到这样的效果.当然系统的可扩展性会差点.
为和要有Employee类,我想楼主是想将业务逻辑和界面分离开.为何要用属性,直接用字段不是跟方便吗?这个问题在你说的那本刘艺的书中已经说的很明白了.我就不在重复了.
当某个员工移动另一个员工时,不一定要把前一个Employee实例消毁,只要将新员工的数据赋给它.面向对象的方法并不能减少我们的编程难度,对与基层的代码编写人员(比如在下),它的好处有限,有时可能会跟麻烦.但对与系统的设计和构架人员它的优势是明显的.可以这么说.对使用使用面向对象的方法的优势感觉最深的应该是系统的维护和再开发人员.
小的项目,大的项目,个人开发,团队开发,实施项目的预算,时间,资源的不同.使用的方法是不同的.很多时候在A和B之间选择A,并不是A是完美的,只是A更适合环境的需要.

>>当某个员工移动另一个员工时,不一定要把前一个Employee实例消毁,只要将新员工的数据赋给它.
其实这样的话，就不是“员工类”了，因为他并不代表某个员工，而是个“员工管理类”，或者是个“员工代理类”了，并不能真正代表某个员工，而是个可变的员工，一时代表张三，一时代表李四，其实是个外壳，也是个变量。
再一个说，比如我要找个年龄最小的员工，如果按“员工实例化”的方法，那么就应该把所有的员工实例化，然后用什么算法来找这个员工，但如果是“员工管理类”呢，没关系，我只要将数据表中的员工根据年龄排个序，马上就找出这个员工了，或者用更直接的方法，用SQL语句中的Min()函数，一步就可以直接找到了。
其实我觉得面向对象编程方法不能模拟现实，还有些其它理由，一、现实中的对象，是有主动性的，而程序中的对象，都是被动的，最起码要由程序驱动。二、现实对象的数据太多了，在系统中建立那么多实例，弊大于利。三、继承与多态之类，是分析现实的一种方法，但并不代表现实的全部。用这种方法编程，确实带来了很大的便利，但也有不足的地方。据李维讲，当初微软使用接口时，就有些公司讥笑微软不懂面向对象技术，但微软就反驳说纯面向对象会有XX(忘了那个词)问题，结果最终证明了接口的作用，造成了面向对象和接口技术的融合。
面向对象编程，就是要更好的组织自己的编程对象，更好更快也编制程序，象VCL中的类，全是编程对象，如Object、Wincontrol、Edit等对象，他们用面向对象技术，更好地赋予了各个类以在计算中工作的属性、方法、事件，如如何显示标题、如果显示数据、如何响应鼠标键盘事件。在这里，他很清楚，他的类、对象是计算机程序中的对象，而不是什么现实对象，他不会做超越出他能控制范围的事，而忘记自已的是程序开发工具的使命。

我们开发程序，也要清楚，我们的程序，只不过是个运行在电脑中、辅助人们工作的工具，只要管好你的工具是如何便于人们工作就行了，不一定非要用代码去代替现实。
《人月神话》中说：手里有个锤子，看到什么都是钉子!
我们有了面向对象这个“锤子”，也要清醒，他不是可以把任何东西都当钉子敲定的!