|
IDE所做的，是“设计阶段”的活。
手工写代码，建立在前者的基础上，做“运行阶段”的活，可以进行更灵活更复杂的控制和调整。 设计阶段的成果，用XML这样的标记语言存储比较好，最终作为代码执行起来。 ruby的closuer，使得它很接近标记语言，如果ui库设计的优良（比如前面提到的遵循CoC和Builder风格），IDE生成的东西和手写出来的代码应该接近一致。那么，它们的区别，更像是linux操作中，用shell还是GUI。 -- 差距减小。 我个人更喜欢GUI/IDE，因为属性、样式、事件列表可以直观看到，设置完关注的条目，还能直接看到效果。这就是IDE的威力吧。 不过，如果用IDE设计一个窗口时要设置一些东西，在做其它窗口时还要进行同样(或相似)的操作，就如同重复代码，是坏味道。代码通常用封装来消除重复，IDE操作呢？ 1. 宏。如同代码生成器一样，生成起来简单 改起来难。 2. 组件封装。Flex对这方面支持的不错（.NET或许也不错吧，没研究过），可以组合其它组件，调整或定制属性、样式和事件，可以用MXML（IDE辅助）轻松完成，本质是类继承。新封装的组件能在IDE中使用。 把业务系统划分成一个个相对独立的界面部件，维护起来就爽了。VB一类的“老”式工具，对它支持不强。理想情况，我们在开发一个个“业务部件”，而不是界面。我们要表达的，只是这个部件应该提供的内容，而不是样式、技术控件之类的东西。 我觉得组件封装对人的要求比较高，要在把握业务的前提下，合理划分出组件、接口和交互关系。 识别重复操作的范围（偶然重复，局部重复，模块重复，全局重复），做出整体规划，都不是简单事。 如果以理想方式开发，由于尽可能的消除了IDE之上的重复操作，“设计阶段”的活减轻了，还有的转移成：用IDE+code开发“业务基础组件”。那么，对于逻辑简单的UI，整个开发工作量就比较小。逻辑复杂的UI，工作量转移到“运行阶段”也不足为奇。 -- 比重减小。 flex和.net都提供了data binding，相当于把一些通用UI控制逻辑也封装到了组件里，这种能力和模式，是把“本质不是运行阶段”的工作从“运行阶段”代码中提取出去。 组件的本质，殊途同归，仍然是代码级的类继承和抽象。让人充分利用IDE的同时，也需要人去理解代码和组件的映射关系。IDE的长处，是设定数据；代码的长处，是设定算法。DSL的好处，是降低两者的隔阂。（关于目前ruby DSL应用中，处理数据和算法上的问题，欢迎大家新开贴讨论） “运行阶段”的重复，也同样需要处理。 组件的AOP，不知道有什么思路或现有方案？ |
|
|
