TaiwanTonguesApiRobot：從 JSON 檔案批量匯入

2025-08-22T05:44:14Z

從 JSON 檔案批量匯入

新頁面

'''GRASP'''是'''通用職責分配軟體模式'''（General Responsibility Assignment Software Patterns）的簡稱，是物件導向設計佮職責分配中的九个基本原則，上早是佇咧克雷・拉蒙一九九七年的 Applying UML and Patterns 冊內底有講著。

GRASP 著提起的模式佮原則包括有控制器（controller）、建立者（creator）、中介（indirection）、資訊專家（information expert）、低鋪合性（low coupling）、聚落高內聚性（high cohesion）、多型（polymorphism）、保護變化（protected variations）佮純虛構（pure Fabrication）。遮的模式攏是針對軟體開發上的一寡問題進行解決。發明遮的技巧毋是為著欲創造新的工作方式，是為佇物件導向設計上，舊的，經過測試的程式設計方式建立文件並且標準化。

克雷・蒙講著伊：「軟體開發上關鍵的設計工具毋是 UML 抑是其他的技術，是明瞭設計原則的心智。」。所以，GRASP 原則是心理層面的工具集，佇咧物件導向軟體設計學習的輔助工具。

==模式==

佇咧物件導向設計當中，設計模式是針對問題以及其解決方案一个有號名的描述方式，會當應用佇無仝款的情境中。理想的設計模式會使予程式開發者知影欲按怎共解決方案應用佇無仝的環境之下，而且進行取捨。佇一寡特定類型的問題內底，真濟模式會提供物件職責分配的指南。

===資訊專家===

問題：分配職責予物件的基本原則是啥物？
解決方案：揣著實現職責需要有的資訊，將職責分配給予有這个資訊的物件資訊專家（Information expert）是決定按怎分配職責（予方法、欄位等）的原則。

應用資訊專家的原則，常見指定職責的做法是針對特定的職責，確定愛實現此職責愛有啥物資訊，猶閣有資訊存在的物件。

這會將職責分配到有上濟佮職責有關資訊的物件相關模式抑是原則：低鋪合性、聚落高內聚性

===建立者===

物件的建立是物件導向系統中常看的活動之一。因此需要確認佗一个類別有職責建立物件。

問題：啥物款欲建立物件 A ?
解決方案：一般來講，類別 ` B ` 若符合以後一个（嘛有可能是濟个）條件，有權責欲建立物件 ` A `：

* ` B ` 的實例包括 ` A ` 的實例，抑是講合成聚合 ` A ` 的實例
* ` B ` 的實例會紀錄 ` A ` 的實例
* ` B ` 的實例密切的使用 ` A ` 的實例
* ` B ` 的實例有 ` A ` 的實例初初的資訊，佇咧建立物件的時陣會傳予 ` A ` 的實例相關模式抑是原則：低鋪合性、工場方法

===控制器===

控制器（controller）模式會共處理系統物件的職責指定予表現整個系統抑是用例場景的使用者介面類別。控制器物件是非使用者介面，負責接收抑是處理系統事件的物件。

問題：佗一个物件愛處理輸入系統事件？
解決方案：應該由用例控制器來處理用例所有的系統事件，嘛會當用佇一个以上的用例。比如講「建立使用者」抑是「刪除使用者」的用例，會當用仝一个類別，這號做 UserController，毋是用兩个人的用例控制器。

控制器定義為咧使用者介面了後，接收佮處理系統動作的頭一个物件。控制器需要用其他的物件來完成的工課予對應的物件。控制器協調抑是控制相關活動。佇資訊系統邏輯架構的物件導向系統當中，若應用程式應用層 / 服務層佮業務邏輯之間有明確的分隔，GRASP 控制器會當看做是應用層抑是服務層的一部份。

相關的模式抑是原則：命令模式、外觀模式、層、純虛構

===中介===

中介（indirection）模式支援低抹合性，佇二个物件之間共其職責指定著中介的物件，所以會當復用。其中一个例是佇咧模型—視圖控制模式當中，佇資料（模型）佮其實現（視圖）之間匯入控制器元件。這會當確保兩个元件之間的低抹合性。

問題：佇咧二个抑是幾若个物件之間，欲按怎分配職責才會當避免允准？欲按怎用物件解決，才有法度支援低固合度，而且維持較懸的復用潛力？

解決方案：共職責分配予兩个抑是多元件之間的中介物件抑是服務，元件之間袂直接提升

===低鋪合性===

鋪排性是評估一元件連結另外一元件，知影講另外一个元件，抑是依賴另外一元件的程度。鬆幫贊是為著以下的優點，指派職責的評估模式：

* 類別之間的相依性低
* 一个類別的修改對另外一个類別的影響較細
* 復用潛力較懸

===聚落高內聚性===

聚落高內聚性（high cohesion）是設法予物件適當的臭火焦、會當管理佮會當理解的評估模式。高內聚性定定會用來支援低抹粉合性。聚性高內是講特定元件的多個職責是互相峇峇有關係，懸度具焦的。將程式分解做類別和子系統是增加系統內聚性的一種方式。相對的乎，低內聚性是講特定元件有傷濟無相關的職責。低內聚性的元件定會歹理解、復用、維護佮改變。

===多型===

依照濟型（polymorphism）的原則，依型態變更行為的職責是咧出現變更的型態上。這會當用多型運算子實現。這類型態的使用者需要用多型運算子。

問題：按怎處理按型態的變化？按怎產生會當插的軟體元件？
解決方案：做一寡行為會因為型態（類別）咧變化，用多型運算子將這職責分派到型態出現變化的型態。（多型有真濟的定義，佇這搭遮的定義是「佇咧無仝款的物件予仝款的名」）

===保護變化===

保護變化（protected variations）模式保護元件，無受其他的元件（東西、系統、子系統）變化的影響，做法是共具焦無穩定部份的程式包裹佇介面內，利用多型來產生現此時介面的無仝實現。

問題：欲按怎設計物件、子系統佮系統，予元件的變化抑無穩定性袂對其他的元件有無好的影響？
解決方案：識別預期到的變互斥抑是無穩定性，指定職責佇咧其禮拜圍產生穩定的介面。

===純虛構===

純虛構（pure fabrication）是講無實現問題領域概念的類別，特別是為著實現衍生類別低抹合性、聚落高內聚性、高復用的潛力（若是用資訊專家解決的方案，無法度達到這个效果）。這類別領域驅動設計內會叫服務。

相關的模式抑是原則：

* 低鋪合性
* 聚落高內聚性

==相關條目==

* 營養不良的領域模型
* 設計模式 ( 電腦 )
*《設計模式：可復用物件導向軟體的基礎》
* SOLID ( 物件導向設計 )

==參考資料==

[[分類: 待校正]]

GRASP(物件導向設計) - 修訂紀錄

TaiwanTonguesApiRobot：​從 JSON 檔案批量匯入

TaiwanTonguesApiRobot：從 JSON 檔案批量匯入