本記事では有名なオブジェクト指向設計原則であるGRASPを紹介します
各パターンの解釈（見解）については幅がありますので記事本文では触れず、純粋に紹介するに留めます
私自身の見解についてはコメントにて追記していこうと思っています
GRASPとは
General Responsibility Assignment Software Patterns（汎用的な責務割当のパターン）の略称で、Craig Larman氏が著書である実践UML（和訳はピアソン・エデュケーション）で紹介しています
Expert（情報エキスパート）パターン
Q. オブジェクト指向設計において、責務を割り当てるときの最も基本的な原則は何か
A. 責務の遂行に必要な情報を持っているクラス、すなわち情報エキスパートに責務を割り当てる
Creator（生成者）パターン
Q. あるクラスの新しいインスタンスを生成する責務は何が持つべきか
A. 以下のどれかの条件を満たすとき、クラスAのインスタンスを生成する責務をクラスBに割り当てる
・BがAオブジェクトを集約する
・BがAオブジェクトを含む
・BがAオブジェクトのインスタンスを記録する
・BがAオブジェクトを密接に使用する
・Aが生成されるときにAに渡される初期化データをBが持っている（従ってAの生成に関してBはエキスパートである）
Low Coupling（疎結合）パターン
Q. 依存性を弱め、再利用性を高めるにはどのようにすれば良いか
A. 結合性を疎に保つように責務を割り当てる
High Cohesion（高凝集性）パターン
Q. 複雑さを管理しやすくするにはどのようにすれば良いか
A. 凝集性を高く維持できるように責務を割り当てる
Controllerパターン
Q. システムイベントを処理する責務は何が持つべきか
A. 以下のどれかを表すクラスにシステムイベントメッセージを処理する責務を割り当てる
・「システム」全体を表すクラス（ファサードのコントローラ）
・ビジネスまたは組織全体を表すクラス（ファサードのコントローラ）
・タスクに関係する可能性のある、現実世界でアクティブである何か（たとえば人の役割など）を表すクラス（役割のコントローラ）
・通常”＜ユースケース名＞Handler”の名前を持つ、ユースケースのすべてのシステムイベントの人工的なハンドラを表すクラス（ユースケースのコントローラ）
結び
CreatorとControllerについては幅が広く抽象的なため、実例無しでは理解が難しいかもしれません
原著である実践UMLはAmazonなどでも買えると思いますので、興味を持たれましたら原著を読んでみることをお勧めします