在研究 Zend Framework Preview 的文件時，發現了一個很有趣的 PHP 寫法：

$select->from('round_table', '*')
       ->where('noble_title = ?', 'Sir')
       ->order('first_name')
       ->limit(10, 20);

看出來沒？除了 from 函式以外，每一個函式都直接接續著上一個函式。怎麼辦到的呢？

ASP 上的單元測試

沒錯，你沒看錯， ASP 也有單元測試。

什麼是單元測試呢？我想使用 Java 或 .NET 來開發程式的朋友們一定很熟悉。我這裡僅簡單說明一下它的原理，至於深入的介紹，請大家自行去找 XP (eXtreme Programming ，中文常譯為「極致編程」) 相關書籍吧。

註：建議你去看看點空間裡有篇文章叫「測試的概念」，寫得滿簡單易懂的。

在 ASP 上面要進行單元測試，首先就要有單元測試框架 (Unit Testing Framework) 。在網路上我找到了以下兩種框架：

• ASPUnit
• ASPunit (這是日本人開發的。)

它們的名字差在 U 的大小寫。

日本人開發的 ASPunit 架構比較複雜，而 ASPUnit 的比較簡單易懂，而且也容易使用，所以本篇將圍繞在 ASPUnit 這個測試框架上。

之前提到 JavaScript 撰寫物件時的寫法：

var 物件類別名稱 = function([參數]) {
  this.屬性1 = null;
  this.屬性2 = new Array();
  this.方法1 = function([參數]) {
    // 方法1程式碼
    this.屬性1 = 'DEF';
}
this.方法2 = function([參數]) {
    // 方法2程式碼
    this.屬性2 = new Array(4, 5, 6);
  }
}

這種方法在有物件實體時才會有作用，如果要像 Java 或 PHP 一樣呼叫靜態方法的話，就要這樣寫：

有時候 PHP 在執行到某個錯誤時，只會丟出一行的訊息，告訴你程式發生錯誤。 例如以下的程式：

<?php
function test($var)
{
   $var->display();
}
$abc = 123;
test($abc);
?>

執行後會出現以下的錯誤：

Fatal error:  Call to a member function display() on a non-object in D:\WEB\wwwroot\index.php on line 4

我們可以知道在第 4 行的地方因為 test 函式對 $var 呼叫了物件操作函式，卻因為 $var 不是物件而導致錯誤 (Fatal Error) 。但是我們怎麼知道 $var 變數是從那裡來的呢？就上例而言，很明顯地往回推到第 8 行呼叫 test 函式的地方，我們給它的是 $abc 變數，而 $abc 變數存放則是一個數值，也因此造成 test 函式的錯誤。

當然在程式碼比較短時，我們可以很容易知道整個程式執行的流程動向；不過當我們的程式碼暴漲到上百行或是中間引入不同檔案時，要一下子歸納出它的動線就很不容易了。換句話說，如果第 6 行中我們有上百行的程式碼，那麼我們如何一下子就找到 test 函式的引用點呢？

一直以來我都以為 Me 這個關鍵字只能在 VB 上用，沒想到這兩天我用了 Me 當類別屬性時發生錯誤，這讓我得重新檢視它是不是個 VBScript 的預設關鍵字。

我找過 MSDN 的 Scripting ，裡面並沒有提到 Me 這個關鍵字，反而是在 VB 6.0 裡找到這個關鍵字的說明。真是神「 Me 」 呀！它在 VB 中的主要用途一為指向類別自己，二為指向 Form 物件。不過 ASP 中應該是沒有 Form 物件可參考 (這裡我保留這樣的想法，也許將來又發現自己錯了) ，所以對我來說這個關鍵字就是用在 Class 上的。

為了避免類別重覆宣告，我想盡辦法做了一些調整，但都不如已意。後來我回想起自己曾經找過一篇動態載入 ASP 程式的文章，那時因為它無法達到我的需求而放棄，但是現在它卻有新的用法。

Design Patterns 是我近來研究的課題之一，我在後來的 ASP 專案裡，為了解決一些問題而導入了部份的 Design Patterns 觀念。或許有人會認為 ASP (VBScript) 沒辦法使用正統的 Design Patterns ，不過我注重的是 Design Patterns 的觀念所帶來的解題方式，而不是 Design Patterns 的形。

以下我會說明一些我常用的技巧，這些都是從 Design Patterns 中得到的一些啟發。

接下來的技巧會比較複雜一點，不過如果能夠善用的話，就會是一項很好用的武器。我在較大型的專案裡用過這樣的方式，它提供了我在開發程式不一樣的角度。至少我不必再寫一些複雜的判斷式，減少錯誤的發生。當然錯誤還是會有，但這是個人思考邏輯的問題，和物件導向開發方式關係不大。

這是寫給公司同事的一系列 ASP (VBScript) 物件設計手法文章，我盡可能寫得比較簡單易懂。雖然 ASP 目前已經不再是市場主流，但還是我的手邊有很多專案沒有辦法導入比較先進的技術 (像 ASP.NET 或 JSP 等) 。所以瞭解如何用 ASP 的物件設計手法來解決問題，是這系列文章主要的目的。

在繼續下去之前，首先先釐清一個觀念，物件導向是一種思維，而非僅是語言的特性。當然，我也不想去仔細探討 ASP (VBScript) 是不是物件導向語言。我已經用這種方式寫了一些專案，執行成果也還不錯。對於那些有疑問的朋友，我還能夠拿出一點不算太難看的成果供他們參考。

經過了一些討論與思考，我決定把這系列文章更名為「ASP 物件設計手法」。

對於物件導向我不是高手，我也還在研究當中。我只是希望透過這樣的說明，讓我身邊的伙伴能夠清楚我的想法 (與寫法) 而已。

嗯，有空要好好研究一下。當然最大重點就是 PDO (預設啟用) 了！

參考網址：

• ChangeLog