程式語言的特性本質（二）－類別與原型的物件管理學

類別基礎（Class-based）與原型基礎（Prototype-based）為物件導向的不同風格。前者在設計時先強調物件的種類畫分，之後根據畫分的類別，建立具相同行為與結構的實例（Instance）；後者先著重物件個體的行為描述，日後隨著程式演進再來擔心分類等問題。

類別規範了實例的行為與結構
在描述問題中重複出現的物件行為時，類別基礎是將觀察的物件行為予以分類，在類別中定義每個實例擁有的行為與結構，但實例允許各自的狀態。

在類別基礎的作法下，要規範類別的使用者較為容易。由於使用者建立的實例都是基於類別規範，實例間唯一允許的差異性只有狀態。在這樣的模型中，程式的穩定性較高，因為實例不會有其他行為或結構的可能性；程式的安全性也較高，除非修改類別定義，否則不用擔心使用者對某物件作了修改，從而影響另一使用者或甚至整個應用程式，也因此類別基礎的作法，適用於對可預測性要求較高的工程環境。

由於類別的限制，實例除了狀態外不允許有其他差異性，類別一旦定義與發布，想更新類別的行為與結構就不是件容易的事，畢竟這意謂著引用舊有類別的使用者，應用程式將受影響而需要修改。類別基礎的支持者往往注重程式開發前的分析，在實際撰寫程式前，得花費許多心力來探查需求。

原型基礎下的物件是自主學習個體

在描述問題中重複行為時，原型基礎的作法是先實作物件行為，必要時再針對一組行為實作過程重複的物件予以分類，目的在管理「指導物件能力的過程」，經由同一訓練過程的物件仍可透過其他管道，擁有個別的能力。

類別基礎下的物件有類別與實例兩種，實例的能力總是由類別規範，不允許物件擁有額外習得的技能，狀態是物件唯一可擁有的差異性；原型基礎下只有一種原始物件，物件的能力都是透過學習而來，具體來說就是對物件新增特性或行為，每個物件的能力與狀態都是獨一無二。

舉例來說，JavaScript是支援原型基礎的語言，如果需要一個物件擁有某些特性或行為，就必須對原始物件加以指導：

var b = {}; b.radius = 3;
b.volumn = function() { return 3.14 * Math.pow(this.radius , 3) * 4 / 3; };

由於指導物件能力的流程出現重複，因此可以適當地將重複流程予以封裝。例如若有b1、b2等物件同樣要透過以上流程進行指導，則可以如下，避免撰寫重複：

function Ball(b, r) {
b.radius = r; b.volumn = function() { …略 }; return b;
}
var b1 = Ball({}, 3); var b2 = Ball({}, 6);

經由共同流程的指導，已擁有一定能力的物件仍可以進一步個別指導。例如：

fb1.color = 'red'; b2.weight = 20;

原型基礎下的物件都是獨立個體，沒有類別來規範行為與結構，雖然像JavaScript這樣的語言，可使用類似類別基礎的語法來建構物件，然而實際上仍是指導物件能力的過程：

function Ball(r) { // 看似定義類別，其實是指導原始物件的流程
this.radius = r; // this會參考至傳入的原始物件
this.volumn = function() { …略 };
}
var b = new Ball(3); // 看似建構類別實例，其實是傳入原始物件

由於先描述物件的行為，原型基礎的作法極具彈性，可先就觀察到的行為進行實作，需求發生變化時也易於隨時增減物件行為，即使事先對物件的學習流程予以封裝並發布，後續使用者在不滿意原有實作的情況下，也可以根據需求重新指導物件的行為或結構。例如：

b.volumn = function() { return 3.1415 * Math.pow(this.radius , 3) * 4 / 3; };

然而這也是類別基礎的支持者不安之處：沒有內建機制可對物件行為與結構加以規範。在原型基礎下，使用者隨時可以修改物件，降低了程式的穩定性，既然可以對任何物件進行修改，通常也表示可以對程式核心物件進行修改，如此一來，引用核心物件的整體系統行為也會受到影響，進而引發安全性的問題。

原型模仿類別是一種慣例約束方式

類別基礎與原型基礎對物件能力規範的作法有著極大差異，習慣類別基礎的開發者面對原型基礎語言，往往急於尋求類別基礎語言中規範物件的類似方式，而未認清原型基礎的出發點在於支持物件個體化，因此對原型基礎語言產生誤解與誤用。例如直接將上述JavaScript範例中，Ball函式定義與new關鍵字的用法，看作是類別基礎語言中等效的類別定義與new建構語法；另一種常見誤用，就是在未瞭解原型基礎中物件學習能力本質的情況下，就嘗試以某種方式實作出類別基礎下繼承的概念，或沒有去理解程式實際需求，就直接引用套用某種模仿類別基礎的框架。

類似以上的錯誤認知，非但無法發揮原本使用類別基礎語言的經驗，也無法發揮原型基礎語言的真正彈性。原型基礎去掉了類別的約束，目的在換取物件學習能力上的彈性，然而對某些經驗不足的開發者而言，過大的彈性反而是一種危險，因而需要某些機制來約束。模仿類別封裝與繼承概念，其實是一種慣例約束方式，原型基礎要模仿類別基礎的方式很多元，該採用哪種模仿方式，正意謂著必須思考程式中需要哪一種慣例約束。這也正是原型基礎帶給來的彈性之一：可以根據需求採用不同慣例約束，而非語法層面上直接限制物件能力。

另一個約束物件個體性的方向是採用包裹器。舉例來說，JavaScript的Prototype程式庫採用對核心程式庫增加或修改行為的方式，並以模擬類別基礎的方式來約束開發者的使用模型，好處是類別基礎的開發者在運用時較為熟悉，壞處是更動核心程式庫並非最佳實務作法。jQuery採用包裹器的方式，使用包裹器收集要操作的物件，開發者對包裹器操作，包裏器則對收集的物件改變狀態，好處是不更動核心程式庫，符合最佳實務，然而開發者必須額外學習包裹器的使用架構。

注重工程管理或尊重個體差異的決擇
類別基礎與原型基礎對物件的能力管理方式不同，類別基礎偏重工程性，使用類別規範所有物件行為，在重維護的場合較具優勢，但語法彈性相較上自然顯得不足。原型基礎偏重物件個體性，可以輕易賦予物件不同的特性，有利於快速堆砌功能，但容易造成維護上的混亂，在應用於工程性偏重的場合，往往得採取某種慣例來約束物件行為，像是上述採用某種方式模擬類別或使用包裹器，避免開發者直接修改物件的行為與結構。