“过度设计”之真实例子

　　我刚到了一家新公司，公司给我的感觉很不错，不过当开始做第一个项目时便有过度设计的嫌疑，项目不大，基本就实现CURD的功能，用struts2+spring+ibatis+extjs。拿我开发的一个简单的功能来讲，就花了大概一周，如果采用简化的技术，实际上可能只需要一两天。

　　设计太多的分层，以及偶和性太高，添加或修改一个模块太困难了，而且还不知道会不会影响到其它模块。按照项目定义的规范做法，写一个Hello world，创建的代码文件个数必须达到8个！！！！

　　过度分层已经成为过度设计的一个典型。项目经理说，这是另一个项目的架构直接搬过来用的，我们做一下架构上的优化。

　　其实本来就没有什么优化，原来本就是简单的东西，为了显示技术，搞得特复杂。现在所谓的优化，实际上回归质朴而已。

　　记得OSI7层模型就有过度设计嫌疑，可以去看一下现在的教材，都没有用OSI作为例子，尤其没有专门讨论会话层。

　　如何防止过度设计，最好办法就是使用敏捷编程，他的思路就是刚刚好就行，如果有问题，再重构。另外我自己目前的实践方法就是多编程，少设计，好像也能避免。因为当你的任务主要是写代码的时候，你绝不会去写8个类来完成一个helloworld。

　　其实，我所说的就是开发原型，也是《敏捷开发方法》里提到过的方法。

评论

150 楼 dolwenjian 2010-09-30  

Durian 写道

徐风子 写道

设计：一定要写过代码的人做。

----------
顶你这话。

++

149 楼 t42dw 2010-09-30  

lz有没有想过，有一天你的业务逻辑变了你需要改动多少代码，有一天你不用spring MVC了你需要改动多少，有一天你所用的数据库变了或者不用ibatis你需要改动多少代码？

当然我说的这些可能以后都不会发生，但没办法我们不是神不知道以后会发生什么只能提前预防。

当然我们也可以不考虑这些可能不会发生的事，不过你有没有想过有一天真的需要变动那个开发变动版本兄弟对你的漫骂

控制，业务，数据操作分开还是很有道理的

148 楼 同学、木 2010-09-30  

xhdwell 写道

jasph77 写道

构架师 自然有架构师考虑。。
要不然人家怎么坐上这个位置，你还是一个普通的程序员。
架构师也是个人，他的架构必然也有不完美地方。

最讨厌那种，整天说这个不好、那个行，自己又没解决方案。

确实，以前javaeye上有篇文章说的就是别老骂别人的代码烂，说的很在理。在你没完全理解别人设计的思路之前千万不要妄下结论。别人这么设计是有他的道理的，只是有些原因你还不能理解。你在没有完全理解前就说他过度设计只能说你学的还不够。再过2年你就不会这么说了。

确却。。我刚刚毕业的时候 老觉得别人设计的这个不行那个不行，自已设计出来的才是最好的。现在我懂了。不懂别人价值的人，自已才是最没价值的。

147 楼 pengjj2 2010-09-30  

这个很正常，按楼主的说法，如果硬要把前端页面也算一层的话，也顶多四层而已。
参照mvc模型，你这个结构顶多多了一个服务层。
要有8个文件主要是多了service的接口，和dao的接口。
面向借口编程我想没有什么可以诟病的。

如果仅仅说服务端的话，这是一个很正常的三层设计模式。
action用来做控制转发是有必要的。有些复杂的逻辑如果你写在action里面，同样会导致可读性的问题。
action不仅仅是控制转发，有时候还会承担一些数据的处理工作。
service层仅仅用来做业务逻辑是很合理的。

js单独放文件时很有必要的，项目的后期维护，如果团队更换或人员更换，在html里的js会导致可读性很差。
当然也要保证你的js文件结构合理，功能分类比较合理。

封装ext,或者封装jquery我也认为没有道理，我觉得国内的编码人员很难达到人家的水平，也许封装只是导致更多问题的出现而已。

如果你们的项目如果是小型项目的话我想简化设计是可以的，如果你的项目要不断扩展和维护，你的简化会导致很多后期问题。

这个结构我可以很明确的告诉你，华为几千万美金的电信项目，结构分层和这个差不多，甚至多出一到二层。
项目分层而言，我觉得这个很正常，但是具体情况要看你们具体的项目情况，别一棍子把人打死了。

146 楼 lcllcl987 2010-09-30  

skycray 写道

IcedCoffee 写道

lpn520 写道

wangking717 写道

真想看看那个HELLOWORD分8个的代码，让我见识一下。

让你见识一下传说中的8个文件：

前端
helloWord.jsp                //页面文件，不用说了
helloWord.js                 //javascript文件

Struts的Action，就叫动作层吧
HelloWordAction.java         //Action类文件，客户端请求到这个类上

业务层
HelloWordService.java        //业务接口， 还用了一套传说中的“面向接口编程”
HelloWordServiceImp.java     //业务实现类，实现上面定义的接口

DAO层
HelloWordDao.java            //数据操作类，关于HelloWord业务的数据操作都在这里
HelloWord.java               //HelloWord表的ORM的对象
HelloWord.xml                //HelloWord表操作的SQL语句，ibatis的sqlmap

这个真的很正常...

+1.

这不是很正常吗？鄙人没看出有何不妥。
架构的好坏不能以文件的多寡来衡量。

145 楼 laolinshi 2010-09-30  

jasph77 写道

系统架构原则很简单：
1、sql语句只能出现在DAO里面 （到处sql太乱）
2、DAO尽量简单，不要有太多的逻辑判断 （为了能更好的复用性）
3、Action只做跳转、json xml生成，无业务逻辑判断 （Action里有事务，不好控制）
4、service尽量做到有完整的业务逻辑功能，并进行事务控制。 （业务逻辑上的通用性，如：增加用户，我可以form表单提交、也可以用websevice调用，通过ejb访问）

这不是过度设计吧，是正常的系统分成逻辑。

144 楼 laolinshi 2010-09-30  

skycray 写道

IcedCoffee 写道

lpn520 写道

wangking717 写道

真想看看那个HELLOWORD分8个的代码，让我见识一下。

让你见识一下传说中的8个文件：

前端
helloWord.jsp                //页面文件，不用说了
helloWord.js                 //javascript文件

Struts的Action，就叫动作层吧
HelloWordAction.java         //Action类文件，客户端请求到这个类上

业务层
HelloWordService.java        //业务接口， 还用了一套传说中的“面向接口编程”
HelloWordServiceImp.java     //业务实现类，实现上面定义的接口

DAO层
HelloWordDao.java            //数据操作类，关于HelloWord业务的数据操作都在这里
HelloWord.java               //HelloWord表的ORM的对象
HelloWord.xml                //HelloWord表操作的SQL语句，ibatis的sqlmap

这个真的很正常...

+1.

确实很正常啊，如果需要事务的话，事务一般都在service层。

143 楼 xhdwell 2010-09-30  

lgc653 写道

喜欢简单直接的约定和结构，讨厌所谓的设计模式和过多配置文件。再大的项目也是由小项目组成的，做好够用的契约和分层一样很好维护，也更容易理解。

设计模式本来就是让程序的层次逻辑更简单明了，这并不冲突。但别一拿到什么问题都往工厂模式，策略模式上去套。在用设计模式之前先要想清楚为什么要用，能解决什么问题。

142 楼 lpn520 2010-09-30  

幽梦新影 写道

分层的结果是简单问题复杂化，复杂问题简单化，写个Hello world你也不用分几层吧

分层是规范，代码要统一，必须这么写，方便以后维护和扩展（架构师原话）

141 楼 幽梦新影 2010-09-30  

分层的结果是简单问题复杂化，复杂问题简单化，写个Hello world你也不用分几层吧

140 楼 lpn520 2010-09-30  

IcedCoffee 写道

lz说自己做java也有4年了，那么这4年你没有遇到这样的架构吗？
这样的架构应该说随处可见啊...
可是为什么4年之后的今天，你突然会站出来说他过度设计？
很令人费解...

呵呵，从我做JAVA开始，我就自己设计，从来都是带别人做，没有别人带我做过，我也在虚心学习，我也想知道，市场主流开发是怎么样的

139 楼 lpn520 2010-09-30  

southgate 写道

张口闭口解耦
why解耦？
普通业务写在action里头有什么不好，清晰 简单
很长的业务 搞一个manager分离出去
重复地业务 搞一个common分离出去


把重用和解耦挂在嘴边的同学，你解耦过多少次

上周参加了一个接力短跑比赛，总共10个人参加，其中有8个人一步都没跑，接了棒子以后就传递给下一个人了。问他为什么这么干，他说他是专门跑山地的，不能跑平原。我说那你别参加啊，他说，我必须的参加，这样可以提高我们团队适应各种情况的能力。 

经典

哈哈，确实经典中的经典

138 楼 IcedCoffee 2010-09-30  

lz说自己做java也有4年了，那么这4年你没有遇到这样的架构吗？
这样的架构应该说随处可见啊...
可是为什么4年之后的今天，你突然会站出来说他过度设计？
很令人费解...

137 楼 mercyblitz 2010-09-30  

转一个Blog ：

http://guoshiguan.iteye.com/blog/775564

136 楼 spacejovi 2010-09-30  

lpn520 写道

jasph77 写道

构架师 自然有架构师考虑。。
要不然人家怎么坐上这个位置，你还是一个普通的程序员。
架构师也是个人，他的架构必然也有不完美地方。

最讨厌那种，整天说这个不好、那个行，自己又没解决方案。

给你看看我之前做的解决方案，同样“添加删除修改查询”，同样是Struts2+Spring+iBATIS+ExtJs

前端
helloWorld.jsp       //用过Ext的都知道，页面是不需要写HTML代码的，所以helloWorld.js直接可以省掉，直接把js写在jsp文件里，还有用EXT直接使用原生态的，封装一层只的很恶心

业务层
HelloWorldAction.java     //struts2的Action，本身就是动作的意思，为什么它不叫Controllor呢，因为控制类已经在它内部封装好了，你实现了Action接口，只要在类里写业务就可以了，再加上struts2每个请求可以对应到Action的一个个方法上，所以万恶的HelloWorldServer.java和HelloWorldServerImp.java可以去掉了

DAO层
再讨论一下DAO层，我们用了ibatis框架，他本身就是个DAO层的实现，你每个SQL调起来就像调用DAO里的每个方法一样，所以HelloWordDao.java就可以去掉了，像HelloWordDao.java里的每个方法就一条代码，有意思吗
所以只要下面两个文件就可以了
HelloWord.java          //HelloWord表的ORM的对象
HelloWord.xml           //HelloWord表操作的SQL语句，ibatis的sqlmap

看了lz这段话，觉得lz资历和经验看样子比较浅，还是虚心点好。

135 楼 lgc653 2010-09-30  

感觉现在什么SSH，SSI几乎成了开发的经典教义，你不这样做，或者不完全这样做就是背经离道。
个人感觉该解耦的时候接口，该分层的地方分层，都是根据实际情况灵活决定的。有必要动不动就加这么一大堆东西和配置文件进来吗，难道不能根据项目实际需要用点简单直接的办法来处理sql、事务啥的。

134 楼 mercyblitz 2010-09-30  

mercyblitz 写道

lpn520 写道

xhdwell 写道

lpn520 写道

wangking717 写道

真想看看那个HELLOWORD分8个的代码，让我见识一下。

让你见识一下传说中的8个文件：

前端
helloWord.jsp                //页面文件，不用说了
helloWord.js                 //javascript文件

Struts的Action，就叫动作层吧
HelloWordAction.java         //Action类文件，客户端请求到这个类上

业务层
HelloWordService.java        //业务接口， 还用了一套传说中的“面向接口编程”
HelloWordServiceImp.java     //业务实现类，实现上面定义的接口

DAO层
HelloWordDao.java            //数据操作类，关于HelloWord业务的数据操作都在这里
HelloWord.java               //HelloWord表的ORM的对象
HelloWord.xml                //HelloWord表操作的SQL语句，ibatis的sqlmap

看了这个结构觉得已经很简单了啊。是最正常的分层啊。兄弟，建议你多学点设计思想。就不会问这样的问题了。

我只能说这是一个广泛的分层，至少已经用了10年了吧，10年前可能没这么多框架，那是合理的，但现在这么多框架干嘛的，不就为了让你简化开发，那为么框架用起来了，而设计的思路却还是跟10年前一样呢

如果是为了单独的功能的话，确实没有必要。如果是抽象服用的话，那么这个就是你的误读了。但是，我觉得一般不会出现前者。

这么说吧，楼主的方向没有错，不应该过度设计。不过理解有偏差，抽象是要的，解耦合也是必要的。不过不应该拘泥于形式，不是说一定要上述的模式。架构都需要灵活性，何必拘泥于形式。这也是软件编程思想的误导和悲哀，因为那些东西是引导你设计，而不是为了铺路。设计模式如此，软件开发方法论也如此。

还有一点，看了这么多，谈到分层这个东西是最基础代码级别。这个是设计，和架构很有很大的距离。

133 楼 treblesoftware 2010-09-30  

不就分了3个层么。
这也叫设计过度？

132 楼 笑我痴狂 2010-09-30  

Durian 写道

这事儿遇到过，一个大博士做的设计，繁冗的厉害。
这个架构师的表达能力还很强，理论很深，所以，基本上把最简单的问题用当今最先进高深的技术实现了。不复杂不足以表达他的雄心壮志。

一语中的  就像刚学了新东西恨不得全部用上 新生的鸟儿羽翼未丰就想飞 不过在这样的公司好混日子 

131 楼 mercyblitz 2010-09-29  

lpn520 写道

xhdwell 写道

lpn520 写道

wangking717 写道

真想看看那个HELLOWORD分8个的代码，让我见识一下。

让你见识一下传说中的8个文件：

前端
helloWord.jsp                //页面文件，不用说了
helloWord.js                 //javascript文件

Struts的Action，就叫动作层吧
HelloWordAction.java         //Action类文件，客户端请求到这个类上

业务层
HelloWordService.java        //业务接口， 还用了一套传说中的“面向接口编程”
HelloWordServiceImp.java     //业务实现类，实现上面定义的接口

DAO层
HelloWordDao.java            //数据操作类，关于HelloWord业务的数据操作都在这里
HelloWord.java               //HelloWord表的ORM的对象
HelloWord.xml                //HelloWord表操作的SQL语句，ibatis的sqlmap

看了这个结构觉得已经很简单了啊。是最正常的分层啊。兄弟，建议你多学点设计思想。就不会问这样的问题了。

我只能说这是一个广泛的分层，至少已经用了10年了吧，10年前可能没这么多框架，那是合理的，但现在这么多框架干嘛的，不就为了让你简化开发，那为么框架用起来了，而设计的思路却还是跟10年前一样呢

如果是为了单独的功能的话，确实没有必要。如果是抽象服用的话，那么这个就是你的误读了。但是，我觉得一般不会出现前者。