关于面向对象设计的疑问
在面向对象设计中有两条重要原则：一，代码高度重用，避免冗余代码。这样的好处是显而易见的，代码的高度重用带来的好处很多。它可以使维护变的简单，如果程序中存在冗余代码，这段代码发生错误需要修改时，我们需要修改所有冗余的代码片，而实际中我们往往漏掉某些片段导致程序中留下BUG。二，设计短小通用的方法。我理解为一个方法只做一件事，这样做的目的就是为了让方法变得更通用，修改起来也变的容易，降低程序的耦合度。
但是，在我们程序设计的时候却往往会发现表面上这两条是相矛盾的，比如对一张表设计查询方法时，需要对不同字段进行查询，而这样的方法大部分代码看起来是一样的，只是SQL有所不同。我们或许会考虑（实际上我们已经这样做了）把所有查询放到一个方法里，而通过查询类型标志来调用不同的SQL以期到达目的。这样做达到了代码重用的效果，如果说这些不同的查询经抽象后确实就是对表的查询，这完全符合面向对象设计的思想。不过，从另一角度来思考，我们设计的方法可能功能过于强大，参数过多，代码结构也比较复杂这违背了第二条原则。
在我把以上文字写完后我已经有了答案，说明我在写之前可能还思考不够。
在我的设计中，觉得应该如下：
如果采用webwork+spring实现的话（因为我就用这种框架:)） 可以将DAO里面的方法设计为最短小的方法，而在service里面放置判断逻辑，action当然只是简单的调用service了。
就是说我将DAO里面的方法设计得短小精干通用。而降低或根本不用考虑service里面方法的可重用性（因为几乎不可能也不需要重用）。
不知道我的设计是否合理？？
自我介绍下哈。我是刚从大学里毕业的学生，没多少经验，才疏学浅，望大家指教。
还有一个，在你理解那些原则前，不要被原则匡住，那个和OO一样只是历史的产物。顺便问一句，你从哪里看见的这些原则，另外定原则的人是谁？？？
还有一个，在你理解那些原则前，不要被原则匡住，那个和OO一样只是历史的产物。顺便问一句，你从哪里看见的这些原则，另外定原则的人是谁？？？
你这句话我也有同感，面向对象只是一部分，根本不是编程的全部
最近就是感觉OO思想有点力不从心了。
还有一个，在你理解那些原则前，不要被原则匡住，那个和OO一样只是历史的产物。顺便问一句，你从哪里看见的这些原则，另外定原则的人是谁？？？
你这句话我也有同感，面向对象只是一部分，根本不是编程的全部
最近就是感觉OO思想有点力不从心了。
好PP的MM
还有一个，在你理解那些原则前，不要被原则匡住，那个和OO一样只是历史的产物。顺便问一句，你从哪里看见的这些原则，另外定原则的人是谁？？？
这两条原则在在很多地方看到过，不过最近一次看到是在《重构与模式》里面，而且我在对以前的代码重构的时候也发现这两条原则给了我很大帮助。应该还是很有道理的，不过我我想在设计中也不应该被原则限制，在没有理解的时候可以借鉴别人的成果，理解了之后再超越原则应该是比较好的方法吧，：）
还有一个，在你理解那些原则前，不要被原则匡住，那个和OO一样只是历史的产物。顺便问一句，你从哪里看见的这些原则，另外定原则的人是谁？？？
这两条原则在在很多地方看到过，不过最近一次看到是在《重构与模式》里面，而且我在对以前的代码重构的时候也发现这两条原则给了我很大帮助。应该还是很有道理的，不过我我想在设计中也不应该被原则限制，在没有理解的时候可以借鉴别人的成果，理解了之后再超越原则应该是比较好的方法吧，：）
这说明你知道什么叫原则
原则是人定的,既然叫原则自然有有价值的地方,但是被套住就......
赫赫 9 楼 wzw9258 2007-02-02 引用：在我们程序设计的时候却往往会发现表面上这两条是相矛盾的，比如对一张表设计查询方法时，需要对不同字段进行查询，而这样的方法大部分代码看起来是一样的，只是SQL有所不同。我们或许会考虑（实际上我们已经这样做了）把所有查询放到一个方法里，而通过查询类型标志来调用不同的SQL以期到达目的。这样做达到了代码重用的效果，如果说这些不同的查询经抽象后确实就是对表的查询，这完全符合面向对象设计的思想。不过，从另一角度来思考，我们设计的方法可能功能过于强大，参数过多，代码结构也比较复杂这违背了第二条原则。
对以上查询的情况，我建议是设计一个方法把表的所有字段都查询出来，不需要区分
面向对象的设计原则一般情况下还是有很大的好处的！ 10 楼 freemanxm84 2007-02-02 wzw9258 写道引用：在我们程序设计的时候却往往会发现表面上这两条是相矛盾的，比如对一张表设计查询方法时，需要对不同字段进行查询，而这样的方法大部分代码看起来是一样的，只是SQL有所不同。我们或许会考虑（实际上我们已经这样做了）把所有查询放到一个方法里，而通过查询类型标志来调用不同的SQL以期到达目的。这样做达到了代码重用的效果，如果说这些不同的查询经抽象后确实就是对表的查询，这完全符合面向对象设计的思想。不过，从另一角度来思考，我们设计的方法可能功能过于强大，参数过多，代码结构也比较复杂这违背了第二条原则。
对以上查询的情况，我建议是设计一个方法把表的所有字段都查询出来，不需要区分
面向对象的设计原则一般情况下还是有很大的好处的！
可能我没把问题表述清楚。我的意思是以不同字段作为查询条件来查询，而这样的查询只是SQL有区别而已。 11 楼 bencode 2007-02-04 引用楼主说:
在面向对象设计中有两条重要原则：
1.代码高度重用，避免冗余代码
2.设计短小通用的方法。
这不是面向对象设计的原则..
面向对象设计的基本原则, 像 SRP OCP LSP DIP ISP 等等 才算吧, 而设计模式就是这些基本原则的体现
引用楼主说:
但是，在我们程序设计的时候却往往会发现表面上这两条是相矛盾的，比如对一张表设计查询方法时，需要对不同字段进行查询，而这样的方法大部分代码看起来是一样的，只是SQL有所不同
嘿, 用过spring 对 jdbc 的包装吗? 你会轻松很多, 正像你所说的,只有SQL不同,那么你几乎只要写 SQL语句.
引用楼主说:
可以将DAO里面的方法设计为最短小的方法，而在service里面放置判断逻辑，action当然只是简单的调用service了。
是否什么WEB项目,都要采用 DAO 和 Service 这种方式吗?
我在项目中就很少用 很多个DAO , 我只用了一个 PersistenceService.. 对对象进行统一的序列化管理．．
12 楼 hermitte 2007-02-04 bencode 写道引用楼主说:
在面向对象设计中有两条重要原则：
1.代码高度重用，避免冗余代码
2.设计短小通用的方法。
这不是面向对象设计的原则..面向对象设计的基本原则, 像 SRP OCP LSP DIP ISP 等等 才算吧, 而设计模式就是这些基本原则的体现
对，面向对象的原则是信息隐藏之类的，而不是复用。
复用是面向对象的目的，而不是面向对象的内容。我们用面向对象思想只是用来更好的复用。
13 楼 lgx522 2007-02-05 OOP说到底是为了业务逻辑的重用。为此，我们不断地抽象，不断地解耦。代码提炼到一定程度后，便可轻松适应多种View及数据存储的变化需求。好归好，必然要付出长久的劳动。
如果体系架构确定的话（如Web+DB），那就不必如此麻烦了，采用简单直接的方式才是最好的（如LAMP）。 14 楼 billy1770 2007-03-18 lgx522 写道OOP说到底是为了业务逻辑的重用。为此，我们不断地抽象，不断地解耦。代码提炼到一定程度后，便可轻松适应多种View及数据存储的变化需求。好归好，必然要付出长久的劳动。
如果体系架构确定的话（如Web+DB），那就不必如此麻烦了，采用简单直接的方式才是最好的（如LAMP）。说的和我同感！ 15 楼 lelong 2007-03-18 hermitte 写道
对，面向对象的原则是信息隐藏之类的，而不是复用。
复用是面向对象的目的，而不是面向对象的内容。我们用面向对象思想只是用来更好的复用。
还有，更简单而明确地设计系统。 16 楼 geutopia 2007-03-19 在我看来，ｗｅｂ应用程序，用面向对象就不太合适。面试对象比较适合于，大而负责，且需求变化不大的应用，个人应用程序就比较适合。而ｗｅｂ应用，需求变化非常之快，用面向对象，会导致逻辑复杂，维护困难，而特别稳定和复杂的部分，如数据库连接应用，已经有了很好的开源库，拿来用即可。
在我看来，必须遵守的一条规则就是分层，简直是不变的真理。 17 楼 yiding_he 2007-03-19 向楼主推荐《重构》这本书。 18 楼 lane_cn 2007-03-19 freemanxm84 写道在面向对象设计中有两条重要原则：一，代码高度重用，避免冗余代码。二，设计短小通用的方法。
这两条不是原则，这是运用oo设计能够达到的一个效果，并且不是最终效果，只是一个附带效果。
我有一篇文章谈了最基本的oo设计方式，希望对你有帮助：http://www.cnblogs.com/lane_cn/archive/2007/01/25/629731.html 19 楼 xuni 2007-03-19 建议看一下 敏捷软件开发：原则、模式与实践 这本书,虽然不能说这就是准则,不过看过几遍后我的收益是很大的.... 20 楼 icefire 2007-03-19 个人觉得OO真的不错！
我也是个学生，一开始设计一个系统的时候，
就是用Web那种流程在设计，也首先考虑到了数据库的设计，
但是后来发现这样太被动了，业务逻辑变得越来越复杂，
更可怕的是，有的逻辑由于一些设计上的失误，竟然无法重用！
