一个软件设计模型的实例

一个酒店客房管理的设计模型。
客房基本的功能需求：散客预订、团队预订、散客开房、团队开房、散客退房、团队退房、换房、续住、房态查询、客史查询 ....

设计的UML如下图：

抽象出Room的基本形态

如果以后房间的状态有了新的需求，可以扩展在Room下，比如现在有单人房，双人房，标准房等，以后也许会有其他的房间类型

O-R模型是用Room类对应数据库中的Room table。使用hibernate的框架。

DAO这块基本上不需要额外的说明了吧，我只是从系统中抽离出一部分，因为以前没用过hibernate，我想这样的设计是否可以在hibernate下使用？

各位老大给点意见了！

首先，你的这个RoomDAO，好像不是接口，是抽象类吧。一般来说，我们把功能定义成接口，把公用属性定义成抽象类。在RoomDAO中只需要包含房间的checkin，checkout，它不需要关心房间的细节，也更不需要去聚合一个Room的对象了（在你图中采用了聚合，令人费解）。
   如果双人房、单人房只是简单状态的改变，那么就不需要去继承什么，因为不存在多态；当然，如果每种类型的房间的属性也存在不同（准确地说应该是属性触发的功能不同），这个时候，就可以采用你右边的结构，通过抽象类，实现多态。
   最后，hibernate只是一个数据持久层的实现，不需要你什么设计跟着它走的，只要你采用的是RDBMS，然后在数据库中存在实体，你都可以用它，简单地说，你可以用JDBC，就可以用它。不要把它想得那么恐怖，它只是JDBC的轻量级封装。

使用聚合好像不太对

RoomADO当然是接口了,我在上面应该描述清楚地,图例上也表示出来了.

至于聚合,应该是Dependency,这个我想是需要修改的地方

我现在困惑的是设计是可行的,但不知道怎么是最合理的!

呵呵，首先我也想那个DAO怎么说也是接口，但是接口怎么可能有属性呢？
再向楼上所说，是dependence，呵呵，我又奇怪了，接口和类之间向来都只是弱引用（方法中引用对象，是虚线，属性中引用对象称为强引用，是实线），在UML中，一般弱引用都是不画出来的，不然结构图太复杂了，反而降低理解度。
   最后，呵呵，设计既然是可行的，那当然是合理的，只是说，也许它不是最优的罢了。一般说了，合理的不一定可行。
   你的业务描述得很简单，而且你的设计图也是非常简单，我想任何一个旁人都无法给你直接的回答，也找不出所谓的问题。
   不要怪我吹毛求疵，呵呵，暂时来说，就发现你的理解和你UML图不符。

我觉得你那个DAO不是一个DAO
http://java.sun.com/blueprints/patterns/DAO.html
DAO的目的是要把业务方法和数据存储方法分离。DAO里应该只有insert,select,update,delete,find之类的方法。
我觉得你那个checkin和checkout应该是业务方法，这两个英文词的意思是订房、退房，可能还要不同的房间类型还要计算出不同的价格什么的吧。
所以这两个方法应该是在Room抽象类里的两个抽象方法，下面的每个具体的room要实现这两个方法。[/url]

补充一点，如果用hibernate，我个人喜欢把持久相关方法（insert，select等）直接写在实体类里。
我用hibernate的时间不长，希望hibernate高手们说说你们的“best practice”

我平时的做法和notyy所讲的一致,也就是说,DAO封装了相对原子性的数据操作,而check in 和check out之类的业务方法我会放在service或者另外一种说法是delegate里面去实现,可能一个delegate的方法会调用DAO的几个方法去实现,当然,几个方法最好都应该使用同一个数据库连接.

我觉得notty说的很实际,很感谢!

如此糟糕的OO设计。。。
checkin和checkout是业务逻辑方法，怎么放在DAO里呢？
DAO仅仅是个数据访问层，我的做法是它里边的每一个方法都是一个原子的数据库访问，不含任何逻辑。而checkin和checkout应该在一个业务逻辑层里。
楼主对于DAO模式误解大矣！DAO仅仅是一个数据访问层，它让你的应用不必关心底层的数据存储，所以它的职责就是数据访问方法的实现。