|
锁定老帖子 主题：关于Java开发不明白的一些问题
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-03-09
jimichan 写道 随你便吧，只能说这个行业不适合你
时间长了，这个行业真的就如你所愿变成一堆垃圾的游戏了 |
| 返回顶楼 | |
|
发表时间：2011-03-09
楼主是有思考的人，思考是有价值的。
凡事不经自己大脑思考的人，根本不应该干这个需要智力的活！ 人云亦云才是真的没啥技术含量！ 我想给楼主投良好帖，可惜没权限。 |
| 返回顶楼 | |
|
发表时间：2011-03-09
楼主，主要想表达的就是我们需要有思想，他的观点只是经过他的思考出来的产物。
现在中国的软件工程师，大多数都是为了技术而技术，包括我在内。 经过搂主的一番分析得出一个"结论";中国软件业需要强大，各位软件工程师就要思考。 |
| 返回顶楼 | |
|
发表时间：2011-03-09
楼主不大靠谱
|
| 返回顶楼 | |
|
发表时间：2011-03-09
暂且不论别的，先说解耦
我觉得，凡事得适度，过犹不及。耦合度太低，则零散的东西就越多，那必须有详细的文档和会去仔细阅读文档的人（这两样我觉得绝大多数项目里都达不到），否则就像楼主的意思，一大堆东西只有自己知道，解开耦做啥？ 不过像模块和模块之间的耦合还是要解的，否则分模块部署（比如我们项目就有那种阉割版本只部署半个系统的时候），判断依赖就麻烦的很了~ 个人认为，解耦的粒度不能太细，否则白白增加劳动力而已。 |
| 返回顶楼 | |
|
发表时间：2011-03-09
nianien 写道 peterwei 写道 nianien 写道 2.关于接口
接口无非一种规范,我可以实现,也以不实现,我可以实现你想要的,也可以实现你不想要的; 不过用来约束的一种玩意儿,可是某些人却认为接口优于一切,没有接口就意味着不规范 于是,凡是逻辑处理类,一律xXXXX和xXXXXImpl,神马都是接口 接口是挺好,但是真的需要到处都用么?你的逻辑永远都不会改变,你整个接口到底是为什么? 仅仅是为了规范么?但是没有接口就不规范么? 3.关于IOC 自从Spring将IOC发扬光大以后,便言必称IOC,因为有了IOC,连接口都可以不用了 现在的Java已经走火入魔了,当C++返璞归真趋于平淡的时候,Java不知何事开始流行起奇技淫巧来了 仿佛学Java如果你不懂IOC,如果你不懂DI,如果你不懂AOP,如果你不懂Annoation,如果你不懂AspectJ,如果你不懂cglib,你就out了 IOC离不开配置文件,现在或者可以说离不开注解 真的很方便么?效率的低下尚且不说,调试的麻烦姑且不论,但是代码的理解还有可读性么? 你不跳出框架来看,你永远搞不明白它的逻辑 本来简单的几行代码就可以搞定,现在却要不停地在代码和配置文件直接跳来跳去 或者从一堆堆Annoation中找出你所需要的那几行. 4.关于Annoation 本来很反感XML的配置文件,仿佛和我一样的人大有人在,所有现在Annoation开始盛行 不过现在看来我倒是有点觉得XML没有那么反感了 至少,XML能让我感觉到代码的清爽,可是那么多的Annoation,真是惨不忍睹啊? XML可以避免重新编译,而Annoation呢? 答案就是避免XML,直接写代码也能避免XML,需要Annoation干嘛呢? 又是为了俗不可耐的解耦?算了吧?即使解耦你就不需要写代码了? 改一段逻辑清晰的代码,比改一个个完全不明所以的注解容易多了 除非你去看注解的源码,或者相信注解的注释文档 面向接口，不面向实现编程，这算是OO基本原则吧。你可以不是一个接口论者，但很多人都是。到一个团队里，你就是一小部分人。你选择不合作，ok,你没有团队精神，你不合群。哈哈。 引用 自从Spring将IOC发扬光大以后,便言必称IOC,因为有了IOC,连接口都可以不用了
你怎么会得出"有了IOC，连接口都可不用了"的结论？ 在JavaWeb领域，至于IOC和DI及AOP，这几种东西，包括了很多OO的原则和设计模式的东西在里面，懂得原理的话，说明你有点水平，也许说明不了什么，但你至少懂。如果不懂原理，会用，说明你没out。 至于xml和annotation都是为了解藕，统一规范，提高开发效率，利于维护。没人肯定说哪个更好，个人团队喜欢问题。 飘过... ps:你可以继续你的呼喊，但我选择做大众，哈哈。 我承认接口的重要性,但不是唯接口论者,用接口可以,但是得明白为什么用? 写代码是需要思考的,我们不是码字工 我想说既然用了人家的框架，就等于是给人家做码字工。 什么都要照着人家框架的规范写... 所以中国什么时候能出来几个像spring，Hibernate这样风靡世界的框架， 或者说你是设计这些框架的人，才会真正将设计模式派上用场。 因为这些框架要考虑到尽量适用于各种项目，那么java的设计模式才会发挥威力。 平时做项目，乃至其他的都是浮云... |
| 返回顶楼 | |
|
发表时间：2011-03-09
spring控和spring无知同样可怕，
关键是了解它，分析它，然后该用的地方用Spring，不需要Spring的地方，何必去弄那一大堆配置和.jar包。 比如我居然看到有人开发RMI、JMS都使用Spring，这就是典型的Spring控，我不知道Spring在RMI和JMS应用中能起到多大的作用，但是我感到直接开发RMI ，没有感到需要别的什么框架来帮忙啊。 这就好像，你需要开车从石家庄去北京，本来直接走京石高速公路就可以了，但是你偏偏要用一辆斯太尔，拉着乱七八糟的一大堆破家具，烂沙发，绕弯到青藏高原，然后再拐到巴基斯坦，越过伊朗，开到阿尔皮斯山下，然后翻山越岭跑到俄罗斯，穿过西伯利亚大森林，越过贝加尔湖，跨过蒙古大草原，然后再进入内蒙古，然后再进入河北省，然后再排一天的车队进京，然后在五环上堵十年，然后在三环上堵一百年，然后等你到达崇文门，已经是一千年以后了。 何必呢？ |
| 返回顶楼 | |
|
发表时间：2011-03-09
解耦和IOC我觉得还是挺重要的。关键还是看项目，有的项目确实没有必要使用面向接口编程。但以前做的一个项目让我体会到了解耦合的重要性以及IOC的好处。
|
| 返回顶楼 | |
|
发表时间：2011-03-09
1.高内聚低耦合有个粒度的问题，关于解耦是方便拆装 以便再次组合使用，相信新的业务需求可以通过对原来业务模块拆下的部件再次组合而成
2.关于接口，是为了方便重构，如果一个功能有多个实现，那么使用接口动态调用就很有必要，特别是在一些设计模式中，如果一个接口通常只有一个实现在未来也不需要扩展，也可以不用接口 SpringSide就是这么干的 3.关于IOC 当年设计是解决EJB的问题，现在JSR中也把DI作为规范之一，使用框架不仅是方便开发，而且有些是在软件工程上方便管理，提高可管理性，可维护性，然大家可以只关心业务逻辑编码，不用为一些常见的恶心问题而烦恼，就像申明式事务一样，系统大了太能体会出他的好处（简单系统使用Servlet+JDBC就很好） 4.Annoation是从其他语言引入的，可以加快开发速度，至少Annoation有编译期的检查，XML就没有，这样就容易写错，使用Annoation顶多就是反射，XML多了解析的过程，要知道XML解析的效率确实不高，当然混合Annoation和XML就挺好的，无论是否喜欢基本上大部分的框架的新版本都把对Annoation的支持作为重要的特性，包括Junit4，MyBatis3，Servlet3.0，EJB3等 以上个人观点 |
| 返回顶楼 | |
|
发表时间：2011-03-09
superobin 写道 暂且不论别的，先说解耦
我觉得，凡事得适度，过犹不及。耦合度太低，则零散的东西就越多，那必须有详细的文档和会去仔细阅读文档的人（这两样我觉得绝大多数项目里都达不到），否则就像楼主的意思，一大堆东西只有自己知道，解开耦做啥？ 不过像模块和模块之间的耦合还是要解的，否则分模块部署（比如我们项目就有那种阉割版本只部署半个系统的时候），判断依赖就麻烦的很了~ 个人认为，解耦的粒度不能太细，否则白白增加劳动力而已。 解耦最怕的就是越解越藕、 你可能实现了某些地方的解耦，但是却要在类里面到处写annotation，明明是在按一下Ctrl + B 就能找到的方法定义，你得费九牛二虎之力才才能找到它对的实现类是哪个，还有可能找错了。 如果项目移交给当初没有参与开发的人员来维护，这简直就是噩梦，除非你的文档细致到每一个类，每一个接口的每一个方法都有详细描述。 难道你想去猜项目的当初开发者的思路么？就算你肯猜，也不一定能猜对啊。 |
| 返回顶楼 | |
