|
精华帖 (0) :: 良好帖 (23) :: 新手帖 (6) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-10-07
robbin，我觉得有一点很有意思。
当年你和jdon的板桥辩论的时候，可否想到今天也有人和你在这里辩论？ 你的辩论到现在也不能彻底影响jdon上板桥的支持者！ jdon的拥护者至今也会认为他们才代表真正的企业级开发，呵呵！ 不过，从现在来看，你表现的要比板桥高明一些，呵呵。 |
| 返回顶楼 | |
|
发表时间：2008-10-07
axeon 写道 在最开始我就已经说了，用比较文明的话说，这是学院派和实战派的意识形态上的争议。
新特性必须要有需求支撑的，而且是实际存在的有力需求，否则这个新特性是屠龙术，只存在于口舌之中的快感。 ioc/di是不是替代性的技术，解决了什么问题，付出代价是否值得，这个现在都有很大的争议，而不是单纯是spring的争议问题。如果仅仅是一种基于改良的技术方案，那么就要看还有没有其他的办法。解决一个问题要看成本，实现同样的需求，你会选择一个更复杂的办法么？而且这个办法可能还会带来其他的问题。 另外，有一点比较搞笑的是，有几个tx在站内短消息里面支持我，还有人加了我的qq，而他们在帖子里面表示的更偏向中立一些，这姑且算是中庸之道吧。 对于稍微有点规模的应用来说，IoC容器当然可以减轻很多程序员手工维护对象依赖的工作量，而且在系统的可维护性、可测试性方面有更多的可以看到的好处。这也是为什么在Java世界里面IoC容器这么流行的主要原因。开源框架并没有厂商的推动，如果不是实实在在的解决了很多问题，根本不可能流行开来。具体到Spring来说，的确太臃肿了一些，所以很多人开始抛弃Spring。比方说Google的Adwords就是用Guice来做IoC容器的。 当然你非要说IoC是没有价值，没有你的静态方法好用，那你就一直用静态方法也挺好，越是原始的方法，越容易被掌握，越不容易出问题。 至于说Java开发软件过于臃肿，过于烦琐，原罪并不在所谓的SSH开源框架上，还是在于Java本身的语法和API上，以及非常糟糕的Servlet/JSP规范制定上，当然现在主流的开源框架不够简洁也在推波助澜。但抛弃先进的框架，寻求原生的API和JSP编程，并不能够从根本上解决开发效率和可维护性问题。 |
| 返回顶楼 | |
|
发表时间：2008-10-07
方法总是有的，但是ssh本身和ssh所倡导的解决方案，诸如接口和分层，这个大大降低了开发效率和可维护性。ssh本身的效率问题，也是个大问题。
给我的感觉ssh并没有解决实际问题，这是我对ssh不感兴趣的最大原因。 一个ssh项目，无论从开发，还是后期维护，还是系统运维上来说，都相当不符合当前技术发展的要求。 对于ioc/di，我想现在仍然是有争议的技术。新概念、技术的提出者总是高调的，不同意见者相对低调一些，这也是新技术容易推行的原因，但是不能代表总是对的。 当然，robbin你说的也是有道理的。 |
| 返回顶楼 | |
|
发表时间：2008-10-07
Steve Yegge最近的一个帖子触动了开发社区的神经。Steve主张将代码数量保持在一个绝对的最小值，是软件开发中最重要的事情。依他的看法，即便仅仅出于缩减代码行数的理由，你或许也该牺牲一些设计模式和避免一些重构。如果问题域太大，做不到这一点——那么你可以换到另一种编程语言。
这个帖子的背景是Steve曾经用Java写了一个在线游戏，现在已经达到了500,000行代码，他无法再自己一个人维护这么大的代码库。因此不久前他把游戏撤了下来，现正用JavaScript重写。 不久之前InfoQ总结过对依赖注入的争论，Steve把DI也归入了代码肿胀的类别： 引用 像依赖注入这类流行的新Java设计模式，Ruby、Python、Perl和JavaScript程序员可能从未听过。即便听过，他们也很可能（正确地）断定自己不需要它。依赖注入是一种极其精妙的基础架构，它在某些方面令Java更加动态，而那些方面正是更高级语言的本质所在。而且，用不着猜，DI会让你的Java代码库变得更大。 用Java就要忍受它变大。活着就要生长。Java就像是俄罗斯方块游戏，没有哪一块能完全填满其他块造成的缺口，而不造成新的缺口，因此你只能无休止地叠下去。 http://www.infoq.com/cn/news/2007/12/does-lines-of-code-kill |
| 返回顶楼 | |
|
发表时间：2008-10-07
2008北京奥运都开完了，竟然还有人讨论IoC/DI/Interface
偶不禁怀疑是有人在写2003的穿越文 Java就是八股文，与其隔三岔五地讨论DI/Interface是否有必要，还不如去研究为什么Ruby/JavaScript/Python这些语言不需要接口，不需要DI |
| 返回顶楼 | |
|
发表时间：2008-10-07
这篇文章写的不错，有同感，有位兄台 在说 80% 的WEB应用不需要接口，完全可以忽略，只能说他做的工作是在忽悠人，或者自己对开发根本没有深刻体会！！太浮躁了！！！
|
| 返回顶楼 | |
|
发表时间：2008-10-07
Ruby on Rails之所以不需要依赖注入，主要的原因在于Rails框架已经自动的把你需要的所有的东西统统给你注入进来了。或者可以这样说，Rails框架本身就是一个无所不包的IoC容器。反过来说，如果你不遵循Rails框架的规范，非要自己搞一套，那么自己注入依赖就会是一件非常麻烦的事情。
|
| 返回顶楼 | |
|
发表时间：2008-10-07
竟然8页了，没时间全部看过，直接针对主贴说了：
这是一个不小的话题，如果不限定范围是很难讨论的，鉴于论坛里大多是做应用开发的，所以讨论的范围应该限定在——“应用开发需要那么多的接口吗？” 我的感觉是基本不需要，需要接口和不需要接口的场合估计连2/8开都不到 可能大家经常跟JDBC、J2EE打交道，所以产生了接口很多的错觉，其实那恰好不属于应用的范畴，他们用接口、抽象类是合理的，但不代表我们也需要（那么多） J2EE就好比房子的水电煤设施，我们开发的应用好比电视、洗衣机、冰箱 由于我经常搬家，所以感触颇深，如果房子的水电基础设施不是实现了同一个接口的话，那搬一次家就相当于失一次火啊！ |
| 返回顶楼 | |
|
发表时间：2008-10-07
不管是SSH还是别的IOC框架，这些框架大家只要按照一定个约束去Coding就可以了。
我是深受上百万行代码难以维护的害了，那些代码里面基本上充斥的都是静态方法，类之间的依赖大家都没有办法想象。 所以才会去用框架去解决这些问题，对于自己的产品来说，维护我现在放在第一位了。开发效率低不要紧（纯粹的JSP+JAVABean开发是很快，但是维护也难，关键是不容易建立一套约束的东东） 如果从维护角度考虑，我宁愿去分层，层与层直接会用接口实现。 |
| 返回顶楼 | |
|
发表时间：2008-10-07
其实我是来吵架的：
axeon 写道 除非是逻辑复杂的应用，否则都不需要搞一个接口什么的。
试问，现在80%的web应用中，有几个真的有非要接口不行的？ 如同spring的依赖注入，学术价值远高于实用价值。 java本身是不错的，就是因为这些劳什子不实用的玩意，被搞的一团糟。 抛出异常的爱 写道 啊,原来作web应用是没有逻辑的.....那写软件干什么?
寻找出路的苍蝇 写道 ls的ls，你做过web应用？你用过spring？
Ethan 写道 楼上的这位可能对Spring是个啥还没弄清楚就在这里胡邹了！所谓的逻辑何来复杂？何来简单？我看是你从根本上没有一个对于设计以及java编程的深刻认识，才会发表这样的言论。只要是严格按照设计的思路按照面向对象的概念来写东西，不用想一定是按照接口编程的思想来实现。 顺便再踩一脚，假如你所经历的应用都按照你的思路开发的话，两个字：垃圾！ liusong1111 写道 "复杂逻辑"和"没有逻辑"是不一样的，看来某些人自己就不讲逻辑。
axeon 写道 嘿嘿，各位息怒。
我搞java开发的时候，你们还不知道在哪里呢？ 业务逻辑的复杂是一回事儿，技术实现的复杂是另外一回事儿。 如果业务本来就足够复杂了，再加上复杂的技术实现，等于复杂*复杂，会做的更好？ 再说了，一个接口会包含多个实现么？我想大部分时候一个接口都只有一个实现类吧？ 复杂业务逻辑就必须搞个接口，证明自己？ 为什么你们听到我的话会跳起来？ 从心理上说，你们实在无法接受把复杂问题简单化处理，这样做技术太没面子了！都不好意思跟人打招呼，只是你们的思维惯势。 从技术上说，你们也就搞过java，技术的积淀浅薄。就连spring的这些好处，也都是别人吹给你听的！你们根本就不能真正明白spring为什么这么做，利弊都在哪里。你们跳不出java的圈子，所以根本就不能真正理解java。 知道么？ 心理素质差+技术水平次，就是你们做出如此反应的根本原因。 实在抱歉啊！ calmness 写道 呵呵，用资历来砸人可不是明智的做法。 robbin 写道 四、不要过多摆资历，从某种意义上来说，摆资历是露怯的表现。 选择性无视啊！ |
| 返回顶楼 | |
