巨無霸 對 組件模型
基於組件的應用程序結構域與傳統的巨無霸程序有著根本的不同。為了理解不同，我們來比較一下相同應用程序的各個實施方法。
巨無霸模型
現在，假設你是一個軟件公司的產品經理，負責為制造業研發軟件。這個軟件應用於車間層用於跟蹤多種產品，從飛機到瓶蓋。這個程序必須能夠跟蹤制造零件的執行工藝和工程圖紙。
軟件會儲存制造資源信息用於改進生產流程並且會與訂單商務系統接口。另外，你的系統還會與車間設備交互，啟動和停止設備並處理各種像瓶頸或拋錨一類是的事件。
用傳統的方法來編寫這個軟件是創建一個巨無霸程序。這個程序可能有上千行的代碼並且需要一個大型全職程序員團隊來維護。它可能是由一種語言開發，譬如C++。即使這個程序在某方面用其他語言編碼比較方便，你也不會願意這樣做，使用兩種以上語言總是會有問題。
巨無霸解決方案提供固定功能。換句話說，就是很難根據每個客戶的不同需求定制。如果客戶不喜歡該系統的某個部分，他們只能是提出需求並且期待在下個版本改變。每個不同的制造商都會需要個性化的實施。每個新客戶都需要一個新的開發周期。在這種情況下升級是困難的因為應用程序編譯成了一個大的可執行文件。這個巨無霸方案同時也阻止（或者嚴格限制）第三方擴展或增強。因為所有代碼都被編譯進了巨無霸，想向編譯好的代碼增加功能是非常困難的。
組件模型
現在考慮使用軟件組件實施同樣的制造系統。用一種基於自由標準組件的解決方案可提供所需要的功能。例如：部分代碼控制車間層的一些設備（譬如包裝機）成為獨立組件。核心應用程序使用界定清晰的固定行為通信。基於組件的方法有一些先進之處。首先整個應用程序的復雜度降低了。在任何模塊中，與其期望代碼復雜度以指數方式增加，不如以線性方式增加。開發者使用巨無霸模式，不僅要對他們自己的代碼擁有直接的知識，同樣對他們想要交互的代碼也要有。在巨無霸模式中，一部分代碼的小改變可能會對另一部分代碼產生重大的邊界影響。而當使用基於組件的模式時，每個模塊都是獨立的。這樣，每個程序員所要管理復雜度的僅是他或她正在開發的組件。由於每個組件都是獨立的，因此每個組件的內部之間相互不受影響。通過逐個擊破技術，應用程序的復雜對就被降低了。
因為每個組件都是獨立的，所以每個組件都可以使用看起來最合適語言開發。只要組件保持著二進制兼容性，就與語言無關。這就讓每個開發者可以選擇最好的工作工具。
基於組件的方式，為應用程序定制化或增加功能提供了一種方便的途徑。例如：如果用戶更換了一臺新型的打標機，就很容易更換打標組件來適應新機器。只要新組件對舊組件是“插頭兼容”的，新組建就能提供所需要的增加功能。此外，新的組件可以不必由應用程序的開發者提供支持。而是可以由出品這個新打標機的公司或者其他第三方提供。這樣，應用程序的功能可以使用不受開發者限制的方式修改或擴展。
巨無霸 對 組件模型