[ZT] 使用UML时，必须从functional 思维转移到object思维，应如何练习呢？

    Functional思维( function thinking)又称为模块式(module) 思维。object思维又称为组件式(component)思维。这两种思维的转移是一种思维习惯的改变(paradigm shift)。

    任何习惯的改变大多需要一些时日的练习，新的习惯就逐渐取代旧习惯了。

    从传统的module思维到component思维，其习惯转换的练习，是开发N-tier系统的基础。首先从传统的模块结构谈起。例如许多人熟悉的树状结构：

 

     图2-1、 传统的程序模块之例

  

 大的功能模块切分为两个小的功能模块。由于大功能模块呼叫(function call)小的功能模块，于是建构成上图2-1的关系。改拿日常的生活经验来做比喻吧！如下图：

   图2-2、 日常生活中的模块概念

 

「做菜」的工作包括两个细项工作---- 「洗菜」和「煮菜」。今天我们必须练习:

   

   看到模块或function 

      -----> 就联想到 who performs it

 

如果做菜、洗菜和煮菜三项工作都是由「大嫂」所担任的，就意谓着：大嫂为这三项工作的执行者(performer)，或称为工作者(worker)。那么就可想象如下：

 

图2-3、尝试想象模块背后的工作者

   上图2-3里，工作者看似隐身在模块的后面。接下来，就必须凸显工作者了，模块反而藏身于后。此工作者或执行者就是组件(component)或对象(object)了。然后以箭头表示这些模块的呼叫情形。

     

         图2-4、突显出组件

 

    上图2-4已经凸显了组件，但是「呼叫」(Call)概念仍是太偏于功能思维了。于是您可进一步将「呼叫」改称为「讯息传递」(message passing)，表示组件传递讯息给组件，如下图：

   

  图2-5、突显组件之间的讯息沟通

 

    虽然要找出适当的performer，可能需要些经验，这个peformer也可能随着时空环境而改变，但是希望您不要担心。更重要而且根本的是：您是不是习惯于去找各function的performer。这才是关键所在。因为不习惯，所以经验不足，就不易迅速找出理想的function的performer。这才是关键所在。因为不习惯，所以经验不足，就不易迅速找出理想的performer，即使找到了，也可能不易判断适当或不适当。所以练习是很重要的。多练习之后就会驾轻就熟了。现在继续练习吧！如果您分析出两个performer如下：

 

  图2-6、有两个performers

 

就可以想象如下：

 

  图2-7、就有两个组件

    大嫂的责任是做菜和洗菜，但是不煮菜。于是，看着上图2-7然后想象着：「大嫂」对象在「做菜」的过程中，会送讯息给「二嫂」对象，请求「二嫂」帮忙「煮菜」。

    如果有一天，工作的分配情形改变成为：

 

   图2-8、责任的分派改变了

 

就练习想象如下：

 

   图2-9、二嫂担任较多的工作

 

    看着上图2-9然后想象着：大嫂在「做菜」的过程中，会先送讯息请二嫂「洗菜」，然后会送讯息给二嫂，请她「煮菜」。

    如果有一天，工作的分配情形改变成为：

 

  图2-10、责任的分派又改变了

 

就练习想象如下：

 

图2-11、有三个组件互相合作

 

   看着上图2-11然后想象着：大嫂在「做菜」的过程中，会先送讯息请二嫂「洗菜」，然后会先送讯息给三嫂，请她「煮菜」。

    熟悉了组件式思维之后，也该享受一下组件式的好处。就是：这些performer是可以分散在不同的地点(location 或site)。也就是说：

 

   组件可能分散在各地点，

       即分布式组件(distributed component)

 

    例如：

 

  图2-12、较复杂的责任分派情形

 

    如果这三个组件各座落于不同的计算机里，其所传递的讯息就必须经由WAN/LAN或Internet等网络传递。于是可想象如下：

 

图2-13、分布式组件

 

    如此，一个应用程序(AP)的程序代码就分散到不同的计算机里的不同组件里，而AP的执行时，就由三部计算机联手，共同完成AP应该提供的服务----「做菜」。这个AP由三个组件所组成，其中大嫂担任主控者，而二嫂及三嫂协助完成。这样的程序就叫做分布式应用程序(distributed application)。

    因为它是由数个组件所组成，所以称为组件式(component-based)应用程序。组件式程序

的优点就是易于分散，而模块式程序就比较不易于分散。

    最后，归纳以上的练习重点：

※ 把传统的function之间的互相呼叫(call)，联想成为：组件之间的互相传递讯息(message passing)。

※ 简单规则就是 -----

 

 

     看到「看到「 做菜() 呼叫 洗菜() 」

     ------> 就联想到：

      「大嫂perform做菜()时，时，

        会传递讯息----- “洗菜” 给二嫂，

        二嫂就去执行洗菜() () 」

 

参考资料

[Allen98] P. Allen & S. Frost,Component-Based Development for Enterprise Systems, SIGS, 1998. P. Allen & S. Frost,Component-Based Development for Enterprise Systems, SIGS, 1998.

摘自高焕堂先生的物件导向杂志