从一篇良好帖子说起

       昨天坐在长途汽车上，实在无聊之极，用手机上了下JE，无意之间发现这篇帖子：主题：关于Java开发不明白的一些问题 http://www.iteye.com/topic/947017 ，这篇帖子让我想了很多，也认真地看了很多人的回复。
      在本文开始前，我先表明下观点，很强烈地支持楼主。但这表示说认同楼主所有的观点。
      解耦，确实是个好东西，不管从前期的开发设计还是后期的扩展维护。但正如楼主所说，很多时候它的确只不过是一个显摆工具， 但更多的时候我会欣然接受解耦，并尽力解耦设计。原因也很简单：一是它确实好（这个好还真的不好举例）、二是为了显摆、三是为了￥。 
      本来我一直不愿意去比较struts1与struts2，但面对此帖子，我对楼主提到的"与Web容器完全解耦"谈谈感受，在struts1中，它把web域作为方法参数进行耦合设计，而struts2确并没有要求一定要使用web域，但事实上，作为C层框架，很多时候的确都离不开web域，由于在struts2中有了值栈技术，有时确实不会直接去使用Request这样的web域。而且有的时候action只是一个逻辑性的跳转，所以就更不会直接使用。总结：在web开发中，控制层并不是一定会直接使用web域，使用与不使用的比例也难以估定，所以与web容器解耦是有一定道理得。其实我当初也很迷茫“为啥明明是web的C层框架，却想着与web解耦”，struts2这样做至少有三个理由：一、值栈技术支持 二、很多时候的确不会直接使用WEB域 三、获取Request这样的web域很简单，且获取的WEB域既可以是sevlet耦合的也可以是非耦合的。 

     楼主提到 2)更容易测试,Web工程里面的逻辑有几个是脱离了Web环境来测试的?  略略看下struts2关于junit测试文档，发现它的确是易于测试的。
     接口的设计：在think in java中认为恰当的原则是“优先选择类而不是接口，从类开始，如果非常有必要面向接口设计，那么进行重构”。我比较认同这种观点，但略有改动，我不觉得一定得从类开始，直到发现有必要面向接口设计时才进行重构，因为有些时候我们完全可以事先确定是否来使用接口或者直接使用类。但从类开始也很好，毕竟有了像eclipse这样的开发工具的辅助，重构也很简单。接口除了大家所说的规范设计外，我觉得它看起来更容易。比如维护一个项目时，如果先看下简洁的接口设计便会对项目有宏观性有一定的把握，至到我们需要它的细节时，我们再去看它的实现。
      关于IOC、DI这类的东西，也没太深的感受，反正跟着主流走，随叫人家是牛人，其实现实就是这样，很多时候你必须适应大众。之前我在广东的时候，很多人都喜欢说“我叼你”，当时我不晓得啥子意思，我就问一个30岁左右的四川老乡，他这样回答我的“管球它这么多干啥子，跟球到他们说就是”（有点粗，但基本是原话）。生活也是这样，有的时候我们需要思考，有的时候也只好“随波逐流”，“随波逐流”的原因也很简单：一是“流”本就是前人或高人在引导 二是要生活 三是我们很难对“流”有影响。 
      注解，这个问题我最想谈谈。楼主提到  “本来很反感XML的配置文件,仿佛和我一样的人大有人在,所有现在Annoation开始盛行 不过现在看来我倒是有点觉得XML没有那么反感了 ” 注解的好，特别是在使用JPA时，我深深体会到注解的好处，然而对于控制层如果要让我放弃xml而选择注解或者使用所谓的“零配置”，正如楼主所言，我也的确反感。就目前而言，我一个肤浅的观念是“持久层用注解，控制层用xml配置文件”。
    

     我想起了当初在学校草率地开始一个练手项目后的无赖，我想起了当初不能理解为什么非要在<servlet>与<servlet-mapping>都使用<servlet-name>，而不直接写在一起。想起了第一次用eclipse这个工具的激动。想起了为了一个乱码纠结几天而不能解决。想起了某年过年的艰苦奋战。回忆这些，我只是想说谁都会有一个过程，一个对同事不断认知的过程。有思想的人也会积极地进行自我否定。

 

     正如大家所说，很多时候设计都是一个“度”的问题，没有绝对的“对与错”，关键的关键是把握这个“度”。在此感谢楼主向那些没有思想的人敲响了警钟，也向那些快没有思想的人敲响了警钟。    

    也正如大家所说，我们这样一大批人是没有什么真正意义上大项目经验，所以理解也可称之为肤浅，我也和一大批人一样期待一个真正的大项目，这样N年后再来暗笑我这篇肤浅的说词。

    

    最后的最后，再次向楼主致敬。