面向对象的疑惑
　

---

有一个Employee类，它有两个链表用来记录Employee的排班表、考勤记录。这些排班表，考勤记录数据量很大。我每次实例化一个Employee类的时候是不是都需要把它的排班表、考勤记录都从数据库加载的内存中？但有的时候我根本不需要操作它的排班表和考勤记录啊！但不加载Employee又是不完全的！我希望使用Employee的程序只知道去它的链表里取排班表和考勤记录。 难道要有两个成员变量记录他的考勤记录、排班表是否加载的内存中？那样的话，如果在没加载之前，正好新增加了考勤记录，并且这些考勤记录已经存到数据库中了，这时我需要所有的考勤记录，是不是需要把链表中的考勤记录先删除，在从数据库中加载所有的考勤记录？
同样的问题还有:有一个对所有的部门抽象的类Department，它有一个链表记录他的子部门，我实例化一个部门时是不是要加载他的子部门？那子部门的子部门呢？如此下去，实例化一个最上层部门时岂不是要把整个单位的部门加载进来？

本来我分析是作的好好的，但为什么涉及到对象持久化问题是就这么麻烦？以前作程序，需要时就直接去数据库中取，增、删、改都对数据库操作就没这么多麻烦！

愁死我了！

这好象和面向对象没有什么关系吧？
面向对象的目的好象也不是让你把问题复杂化吧？

你能不能详细些？谢谢！

针对我的问题，具体的界解决方法呢？能能写详细些？谢谢！

 把对数据库的查询/或者其他的初始化工作推迟到请求相应资源时进行
　

---

eg.

// 构造函数
public Employee()
{

}

// 取得排班表
public getTimeTable()
{
if (timeTable == null)
{
loadTimeTable();
}
return timeTable;
}

差不多就是这样子，数据要用到的时候才去取，另外要注意线程安全的问题

？

还有没有更好的意见呀？

怎么没有人说话？

怎么没有人发表意见？

？

？

?

zeng 同志，让我来发炎。

前面有同志发炎说了一些实现上的问题。我想发的炎是看了您第一篇发炎后的一些感觉。并且，我发炎结束之前，您只能听。

“我希望使用Employee的程序只知道去它的链表里取排班表和考勤记录。”

依常识，一个 Employee 的主要职责，不应该是保管其自己的某某表和某某记录。

而在您设计的世界里，每个 Employee 都背着一个箱子走来走去，里面是 n 张卡片。

“我不背行不行？”
“不行，因为随时会有人查。”
“我把箱子藏在家里行不行？”
“行啊！有人查就去你家查吧。”
“这是要逼死我啊！”
“行啊！！有人查的时候再激活你吧。”
“扑通。”

既然已经提到了数据库，那么，一个有权限的人只要知道该 Employee 的 id 就可以去查了。

所以，这箱子还可以背，但不是非背不可了。


我看啊，师傅，这里牵涉到这个这个逻辑类以及这个逻辑关联的设计问题。一不小心啊，我说，就可能把这个面向对象搞成这个面向物理对象了。

就这样啦。有什么意见吗？快点发炎！

?

?

?

我猜想您的系统中绝大多数地方都不会使用排班表和考勤记录的，所以您可以用一个EmployeeProxy对象来保存最常用的Employee的信息（如：id、姓名等）。
列雇员列表的时候您只需要构造出一系列EmployeeProxy对象就可以，而不是构造出Employee对象。只有在您要察看明细信息的时候，您才需要实例化Employee对象。

 回复: 面向对象的疑惑
　

---

J2ee兄的做法是不对的，排班、考勤不是员工的方法，而是单独的类,员工这个类跟排班和考勤没有必然的联系，因为公司内做不做排班和考勤，员工这个类总要存在的，如果把考勤和排班当做方法，那这个类的灵活性就会差了很多，如果此时公司又增加请假，休假等，把这些都当做员工的方法，就会很糟糕，实际上这些都是单独的类，只有这样结构才可以灵活。所以员工类只包含员工自身的属性，设计成如下结构即可：

class Empolyee｛
property Name;
property Sex；
......
Method setName(aName);
Method getName();
Method setSex(aSex);
Method getSex();
｝

排班、考勤、请假、休假等都是单独的类，它们属于控制类的范畴，排班记录、考勤记录等是另外的实体类，员工与考勤记录之间是一对多的考勤关系，结构如下，其他关系类似：
Class 考勤{
property Employee;
property 考勤记录;
......
Method 考勤();
}

Class 考勤记录{
property EmployeeID;
property 考勤时间
......
Method getEmpolyeeID();
Method setEmployeeID(aEmployeeID);
Method get考勤时间()；
......
}

当采用这种类结构时，你从DB中取员工，跟排班等没有关系，也就不会发生你提到的问题了，当你需要找一个人的排班、考勤等情况时，你是要必须实例化这个人的。
如果在完整一些的话，你还要有EmployeeList类和考勤记录List类。
class EmployeeList{
property EmployeeList --存放Employee的集合
......
Method getEmployee()
......
}
Class 考勤记录List{
property 考勤记录List --存放考勤记录集合
......
Method get考勤记录()
......
}
剩下的东西都差不多，自己考虑吧。

?

 回复: 面向对象的疑惑
　

---

同意楼上的说法，SRP应该在这里用上

 面向对象就是数据和操作的封装吗？－－－否
　

---

很多面向对象的书籍里都这样说，
面向对象就是数据和操作的封装，这样误导了很多人。

对象的数据结构是相对稳定的，而操作一直在变化，
把他们硬搞在一起，致使系统无法关闭。

如果数据影响了操作的流程，也就是影响了逻辑。
这种控制数据和对象放在一起比较好。

?