技术要点

• 关于IDE的选择

         很多时候有人们总是对IDE的选择颇有疑问，也有很多不同IDE的fans，对于是用IDEA还是Eclipse总是很多讨论，我小结一下它们的优劣：

         idea写出代码的质量远高于eclipse。主要是他有独特的PSI技术，一个准确而又智能的parser，能够提取出source的AST。这个parser比Java编译器的parser还要复杂很多，它是在编辑代码实时parse的，即使当前代码还不符合语法，它照样可以work，并且速度超快。然后PSI还支持索引，可以查询代码库的代码语法结构，比如某某class是继承与什么，或者被多少class继承，某某method被多少class override，等等。

其它的IDE就是因为没有这个，所以无法准确得到AST，于是接下来的autocomple，refactor，code inspection，anlysis，增量编译，等等功能都落后。IDEA凭借PSI，在这些方面都是独步天下。反观Eclipse,都是存的时候就自动编译。为什么要自动编译，实际上就是想依赖编译器去拿到这个AST，这样省得自己做AST的解释器，也就是没有PSI这样的东西。但是编译器去拿AST，那不就是类似于spoon了。但是，编译器是为了产生bytecode的，而源代码的很多信息，在bytecode里面是没有的，所以编译器就会忽略这些东西，自然你依赖它就拿不到那些信息了。

 

•   典型的MVC设计模式

       业务逻辑，数据，都是host在manager，每个manager都有具体的职能。这些manager全部都是public的，如果是OSGI的架构，那他们都是service，然后其它界面的form，都是去侦听manager的事件。一旦事件发生，他们就会相应刷新。对于每一个form，它是一个普通的Java class而已，有个show method，里面封装了显示逻辑。至于需要显示的数据，一种是它自己直接host在class，这种数据都是中间数据，是local使用。另外一种数据就是共享数据，这种数据是通过manager的事件来接收。如果它要产出数据，那也肯定是call manager，set 数据给manager，然后manager处理数据，再广播消息。若是跟其它的UI有联动，那就是其它的UI去侦听这些消息。其实这种模式，不是一个严格MVC，因为manager有M，当然也有一部分的C，因为它是一个事件源。但是manger没有掌握所有的C，还有些C是在form里面自己做了。所以，这个所谓的Manager，除了业务逻辑，更多时候承担的是mediator的角色，而不是用C去概括它。这个mediator就是一个消息源，和数据源。所有的form通过侦听和invoke它来驱动整个UI程序。这种模式最大的好处就是能让各个form都相互独立，互不干涉。很容易做出plugin的架构。若是OSGI的架构，那form都是bundle（不发布任何东西），manager是service bundle。如果再有个UI的manger，里面支持View管理，其实form都是些不同类型view，这样form就能通过UI manger显示在某个地方。于是整个系统就完全变成plugin结构，由UI manger启动，然后各自逻辑manger分别是service bundle，各个form也做成bundle。