早在去年丹麦项目的时候,就接触了DAO (Data Access Object) 的概念,不过下面我想说我的理解的,有些像是DAO和DTO(Data Transfer Object)的结合。

背景是这样的:

我现在正在写今年学校ACM要用的赛事服务系统,用来管理队伍注册,志愿者的信息的。

对于系统,有三个角色,管理员、志愿者、带队。而对于管理的对象,有队伍和队员。

举志愿者这个角色举个例子说:

队员的信息自然用一个表保存,也就是生成一个独立的类。考虑到志愿者需要填写个人信息,所以,这个类都有队员信息表那个类的对象作为成员。

志愿者是需要登录的,所以有个登录表。

所以,实际上,志愿者的信息分成了两块。

如果说,将志愿者独立建立一个表了存也可以,不过有些操作就重复了,代码没有合理利用。

如果说,志愿者类继承队员信息那个类,实际上,队员的数据库操作也跟队员信息的不一样,因为他要查两个表(队员信息的增删改查只要一个表),所以,所有的操作都需要覆盖重写——基本上代码也是很多相似地重复,而且没有利用现有工作量。

我现在的做法呢,是志愿者类里面有队员信息的对象作为成员。是可以利用上原来的工作了,不过问题也来了——这样做的话,效率不高:志愿者的生成要查询两次数据库,虽然总复杂度和跨表查询大致是一致的,但是额外开销变大。这个做法显然为了偷懒。

当然,面向对象除了为了代码复用之外,多态也是好处之一。我这两天写代码,一味只想着怎么偷懒,虽然也考虑效率,但是也没想过如何利用多态来简化代码的。现在的写法呢,多态就被废了,比如用户登录时,我现在必须先生成用户表对象,然后在判断角色,创建志愿者或者是领队,如果写成的是继承关系的话,大可以开始就生成目标对象——但话说回来,这种控制我没实践过。

这都是设计的问题,我从来没实战经验,而很不幸,没能在软件工程学到相关的知识。

其实这个系统就是写成面向过程的,也没问题,功能还是很小的,角色和对象并没有十分复杂的关系。我是按照我理解的MVC模型(诶,就是自己左看一点右看一点各种材料的理解,并不很成体系)去建模写的。我这样写,内聚和耦合的代码多,比起直接写面向过程的,工作量还大些,当然,之前给别人写一个CMS的小网站用了这种方法,也体验到后来进行代码维护的时候的甜头。

当然,每次实践都意识到自己懂的东西很微薄,软件设计很高深。自己那些,内聚、耦合、数据隐藏、接口开放什么的,都不知道做得对不对,好不好——各种无限未知。

嗯,真的需要去多交流,多看书,多读读别人的代码。