GRASP的核心是自己幹自己能幹的事，自己只幹自己的 事，也就是職責的分配和實現高內聚。
用來解決面向對象設計的一些問題。
職責：定義爲類元的契約或義務。
類間的一種合約或義務，也可以理解成一個業務功能，包括行爲、數據、對象的創建等。
就對象的角色而言，職責與對象的義務和行爲相關。職責分行爲和認知。
認知職責：
瞭解私有封裝數據
瞭解關聯的對象
瞭解能夠派生或計算的事物
行爲職責：
完成對象初始化
執行一些控制行爲
1.創建者（Creator）
如何分配創建對象的職責呢？原則就是當下列條件滿足時（越多越好），由B創建A：
1.B頻繁的使用A
2.B包含或聚合了A
2.信息專家(Information Expert)
如何實現高內聚，也就是如何給類分配職責？我們要遵循的原則就是把職責分配給具有完成該職責信息的那個類。
3.高內聚
4 低耦合（High Cohesion、Low Coupling）
在面向對象的程序設計時，小到一個類，大到一個功能模塊，如果他們之間的相依性很高就會對整個軟件的開發造成諸般障礙。例如：當你修改一個類或者某一個模 塊的時候，相應的你要改動其他的與之相依賴的類和模塊，使得程序很難維護；代碼會變得很難理解，一個很單一的操作，就會涉及到很多程序之間相互調用；程序 更是難以複用，當你想複用一個類的時候，對應的與之想依賴的類或方法也會被陸陸續續的添加進來。
這就是我們爲什麼要遵循這一原則的原因，而高內聚和低耦合往往是伴隨在一起出現的。低耦合其實就是兩個類或模塊之間聯繫的緊密程度，高內聚就是類中方法和 方法之間的職責相關性。要想避免低內聚、高耦合，解決辦法就是既要降低因爲一個類的變化而對另一個類產生的影響，又要保持類或模塊是有重點的、可理解的、 可管理的並且支持低耦合的，也就是更加精確的給一個類或者模塊分配職責。
5.控制器（Controller）
在UI層外，應該由哪個類來處理系統操作呢？原則就是把系統事件的處理職責分配給控制器類，這個控制器類就相當於MVC中的C。這個控制器類通常是系統事件放生 的用例的控制類。
MVC
6.多態（Polymorphism）
根據類型的不同而發生變化的行爲的定義職責，應該分配給誰？
舉個簡單的例子，坐車去廣州，坐車算是一個行爲，但是這個行爲是可以變化的，比如坐飛機、坐汽車或者坐火車，那麼坐車這個行爲的定義應該分配給誰呢？
原則是通過多態操作把基於類型的可變行爲的定義職責分配給發生該行爲的類。放到JAVA當中來實現就是定義一個坐車的接口，然後具體的坐飛機、坐汽車或者坐火 車的行爲分別定義一個類來實現該功能，然後讓這三個具體的類去實現坐車接口。
依賴倒轉原則。
7.純虛構模式（Pure Fabrication）
非問題領域的職責應該分配給誰？
我們在設計類的時候，通常都儘量的保持和現實世界當中的對象一致，那麼我們從現實世界的對象抽象出來的類就叫做問題領域裏的類，那麼當我們保存這個對象的 時候要操作數據庫，操作數據庫就是一個非現實世界存在的業務對象，他就是非問題領域的職責。
這種職責分配的原則就是將非問題領域的職責分配給人工生成的類。比如問題領域的類通常是放到PO裏面的，他不應該包括CRUD等操作。那麼CRUD這些操作應該放 到一個人工生成的也就是我們在業務邏輯以外加的一個類。
8.間接性（Indirection）
爲了避免兩個或多個事物之間直接耦合，應該如何分配職責？
設計原則是將職責分配給中介對象。例如類A和類B是多對多的關聯關係，當A改變的時候，B需要做相應的改變，當B改變的時候，A需要做相應的改變，這是違反低耦 合原則的，解決方法就是在A和B之間加入一個C類，類C的屬性只有A和B，用C來記錄A和B之間的關係，當A想使用B或者B使用A的時候，他們都通過C來調用對方。
迪米特原則
9.防止變異（Protected Variation）
如何設計對象、系統和子系統，使其內部的變化或者不穩定因素不會對其他元素產生不良影響？
預計識別不穩定的因素，在其外部創建穩定的接口。例如：坐汽車去廣州當中的坐汽車就是一個不穩定的因素，以後也許會坐飛機或者火車，那麼我們就要把坐汽車 抽象出一個坐車的接口，當有一天想坐火車的時候直接加一個實現的類就可以了。
依賴倒轉原則，對接口編程