关于面向对象设计的疑问

    在面向对象设计中有两条重要原则：一，代码高度重用，避免冗余代码。这样的好处是显而易见的，代码的高度重用带来的好处很多。它可以使维护变的简单，如果程序中存在冗余代码，这段代码发生错误需要修改时，我们需要修改所有冗余的代码片，而实际中我们往往漏掉某些片段导致程序中留下BUG。二，设计短小通用的方法。我理解为一个方法只做一件事，这样做的目的就是为了让方法变得更通用，修改起来也变的容易，降低程序的耦合度。
但是，在我们程序设计的时候却往往会发现表面上这两条是相矛盾的，比如对一张表设计查询方法时，需要对不同字段进行查询，而这样的方法大部分代码看起来是一样的，只是SQL有所不同。我们或许会考虑（实际上我们已经这样做了）把所有查询放到一个方法里，而通过查询类型标志来调用不同的SQL以期到达目的。这样做达到了代码重用的效果，如果说这些不同的查询经抽象后确实就是对表的查询，这完全符合面向对象设计的思想。不过，从另一角度来思考，我们设计的方法可能功能过于强大，参数过多，代码结构也比较复杂这违背了第二条原则。

在我把以上文字写完后我已经有了答案，说明我在写之前可能还思考不够。
在我的设计中，觉得应该如下：
如果采用webwork+spring实现的话（因为我就用这种框架:)） 可以将DAO里面的方法设计为最短小的方法，而在service里面放置判断逻辑，action当然只是简单的调用service了。
就是说我将DAO里面的方法设计得短小精干通用。而降低或根本不用考虑service里面方法的可重用性（因为几乎不可能也不需要重用）。
不知道我的设计是否合理？？

自我介绍下哈。我是刚从大学里毕业的学生，没多少经验，才疏学浅，望大家指教。

简单业务的情况下，你的设计是合理的，毕竟贫血模型只是听着难听而已，能解决问题就是好办法

毕竟现在绝大多数系统都是CRUD搞定的。用不着为了复杂而复杂

面向对象设计这块，我的意见是，代码冗余就冗余吧，除非他威胁到了你的工作
还有一个，在你理解那些原则前，不要被原则匡住，那个和OO一样只是历史的产物。顺便问一句，你从哪里看见的这些原则，另外定原则的人是谁？？？

你这句话我也有同感，面向对象只是一部分，根本不是编程的全部

最近就是感觉OO思想有点力不从心了。

建议freemanxm84看看我的文章如何在struts+spring+hibernate的框架下构建低耦合高内聚的软件中我的那个下载包（Spring-Hibernate.rar），可以很好地解决你的问题。我通过将查询条件放在对象Condition中传给DAO，DAO收到并解析Condition中的条件，就可以执行各种查询，还可以实现翻页。

这两条原则在在很多地方看到过，不过最近一次看到是在《重构与模式》里面，而且我在对以前的代码重构的时候也发现这两条原则给了我很大帮助。应该还是很有道理的，不过我我想在设计中也不应该被原则限制，在没有理解的时候可以借鉴别人的成果，理解了之后再超越原则应该是比较好的方法吧，：）

fangang兄的文章我已经看过了，受益非浅。我们的项目也准备在框架内加入hibernate，不过最近产品正在推广，要真正给项目动大手术可能要等很久了，：）

这说明你知道什么叫原则 原则是人定的,既然叫原则自然有有价值的地方,但是被套住就......
赫赫

引用：在我们程序设计的时候却往往会发现表面上这两条是相矛盾的，比如对一张表设计查询方法时，需要对不同字段进行查询，而这样的方法大部分代码看起来是一样的，只是SQL有所不同。我们或许会考虑（实际上我们已经这样做了）把所有查询放到一个方法里，而通过查询类型标志来调用不同的SQL以期到达目的。这样做达到了代码重用的效果，如果说这些不同的查询经抽象后确实就是对表的查询，这完全符合面向对象设计的思想。不过，从另一角度来思考，我们设计的方法可能功能过于强大，参数过多，代码结构也比较复杂这违背了第二条原则。

对以上查询的情况，我建议是设计一个方法把表的所有字段都查询出来，不需要区分
面向对象的设计原则一般情况下还是有很大的好处的！

可能我没把问题表述清楚。我的意思是以不同字段作为查询条件来查询，而这样的查询只是SQL有区别而已。