UI组件：整体的结构设计、UI的设计

UI组件是构成UI界面的基本元素，具有相同基础结构和行为模式的多种UI组件在一起形成了组件库。一部分组件之间有一定的关联：类的继承，组合。
UI组件设计的本质就是：
      1.   骨架设计：基础结构  +  行为模式
      2.   外观设计：UI

UI组件库中，骨架设计是相对不变的部分；而UI设计是丰富的，是多变的。

不变 + 多变 = 千变万化的UI

=====================================================================
网络应用的前端UI组件的设计

》客观环境
       在不同的地区，不同的组织内部，网络环境是千差万别的。这就造成了网络数据的传输质量有好有坏，速度有快有慢。对UI组件设计的要求与后者有关。网络速度慢，相同数据量的数据传输需要的时间就越长。从用户体验角度，不能让客户长时间等待。然而，网络速度是难以控制的因素，所以只能在减少传输的数据量上做文章。
      提供网络应用的成本很大一块是购买数据流量。流量越大费用越高。减少或消除不必要的数据流量，手段之一就是减小应用程序本身。
      上述的变相说法就是：UI数据要越少越好。
    

》目标：

       使用UI组件库，最终编译成果的体积要小到不能再小

》设计理念：从简设计
不意味着：
                  1.   不意味着结构松散
                  2.   不意味着功能缺失
                  3.   不意味着难于理解和使用

恰恰相反，它意味着：
                  1.   合理、透明、容易掌握的结构设计
                  2.   功能满足常规需求，而不是片面追求大而全

                  3.   有着基础功底的软件工程师能够很容易地掌握如何为组件库扩展个性化功能和去除不需要的冗余

还有一个重点，它意味着

                  4.   舍弃严谨的各种检查（比如对函数参数的类型检查，使用成员变量时候的null检查）。

                        为了防止不恰当使用可能造成的错误，必须对使用方法进行严格的限制，手段之一就是提供使用文档和示例代码，并对可能产生错误的做法加以文档提示。

从简设计的一个反面例子就是Flex中的UI组件库。
该组件库的设计理念之一就是功能上的大而全。使用者只能对其做加法（增加功能），而不能对其做减法（去除不需要的功能）。
（不能做减法的原因是Flex不是单纯的组件库，而是一套生态系统，对其做减法等同于推翻它的生态系统。几乎没有人能够完全掌握Flex生态系统的结构和细节，因此也就无法改造它。即便能够改造，它也是个“三峡工程”，非一人之力能为也）

使用Flex开发出的程序体积很大，不能满足上述的客观环境，因此风光一时之后，现在少人问津（当然，Adobe公司放弃Flex也是原因之一）。

》保障手段

1.    必要的使用说明文档（包括错误用法的提示说明）

2.    示例代码

》愿景
如果能够建立轻量级的actionscript UI组件库，以及围绕组件库的生态系统（开发工具），那么Flash平台在RIA领域将重新获得活力。
现存知名的actionscript UI组件库都不具备工业级别的骨架。或是过于简单，难当重任，比如minimalcomps；或是过于复杂，类似Flex，比如ASwing。