这样代码重用？

从逻辑上看，这两者似乎有密切的关系，由getPlans实现getPlanByName是合理的，也是说的通的。最初的实现就应该是如此的。

但是当我们落实到数据库这个底层支撑性的基础设施的时候，恐怕很多人【包括我】都会同意把采用getPlans的getPlanByName重构成另一个SELECT语句{注意：这儿说的是另一个方向的重构}。原因我觉得很明显，【数据库】这个基础设施提供了这个功能，而且所有的数据库都是如此，它们在上面花了无数的心血和精力实现的机制，为什么不用？这不是对DRY的公然否认吗？看起来这是对你坚持的“避免依赖”的肯定啊，哈哈。

如果觉得两个SELECT有问题，好，数据库层面为我们提供了灵活性，我们可以采用一个SELECT【+变量】的方式实现，这样就没有重复代码的坏气味了吧！

当然，这个争论其实不涉及到用户界面，所以骨子里是你们公司里给各种设施【包括数据库，应用服务器等等】【心理上】提供的权重问题。

典型的为了重用而重用

对数据库方面代码的重用是不是要考虑性能方面.不要为了重用而重用

哎，不知道为什么要这么重构，感觉这样系统的负担更重了，本来可以一次查出来一条记录，这样重构后非要先查出N条再做筛选，感觉有点画蛇添足了！

其实不仅仅是效率问题。我跟这种重用叫做ad-hoc reuse，对比于systematic reuse。

看，现在是有：

Plan[] getPlan(String userid);
Plan getPlanByName(String userid, String planName);

那么假如明天又有一个

Plan[] getPlanByPlanName(String planName);

这时候我们就有两种重用方案咯，getPlanByName既可以调用getPlan，也可以调用getPlanByPlanName。

回头如果再有一个

Plan[] getAllPlans();

是否最好getPlan(userid)和getPlanByPlanName()都要重构，通过调用getAllPlans然后再过滤呢？

一般化来说，如果有这么三个不同的条件判断：

select * from some_table where x and y and z

如果系统另外还需要

where x;
where y;
where x and y;
where y and z;
...

等等不同的变种，这个重用到底是谁重用谁？说穿了，最简单的，自然就是把整张表load到vm里，然后大家重用这一个，各自用循环来filer。可是这样你除了自己做了一个弱智无比的java数据库，什么也没干。一起工作时大家是同事，我不好意思刻薄，不过现在我终于忍不住要说，这就是脑袋进水了呀。

ajoo同志胸中闷气终于抒发了出来。。。

不过你这个例子里，号称只是一个小数据集，又不涉及什么复杂逻辑，完全可以全部load到内存里。只是你pair的做法不伦不类，即要用数据库，又不好好用，确实是脑袋进水了。问题是你说公司其他人也多数赞同，难道你公司里其他人都脑袋进水？还是只是纯粹附和你的pair？

Agree with your comments deeply.

恩，我也觉得这个是不需要重构的。本来就是很简单明了的东西，你把他写到一块去，反而增加了逻辑判断。感觉和重构的本意相矛盾啊。

在一些数据量比较少的查询中可能在性能上不会有太大的体现,
不过在100W+条记录就可以体现出来了....
现在我们做的项目大都使用存储过程过减少数据库和java之间的数据交互.

而且另外一个原因,
把简单的方法复杂化,不符合XP

支持楼主