GRASP

実用日本語表現辞典

grasp

別表記：グラスプ

「grasp」とは、握る・掴む・把握する・理解するなどの意味を持つ英語表現である。

「grasp」とは・「grasp」の意味

graspとは、「～を掴む」、「～を握りしめる」といった意味を持つ英語の動詞である。手に力を入れてぎゅっと掴む様子を想像すると良いだろう。また、「掴む」という意味から派生して「～について把握する」という意味として用いられることもある。名詞として用いられるケースもあり、その場合は「理解」「把握」「専有」「支配」といった意味となる。

「grasp」の発音・読み方

graspの発音は「グラスプ」あるいは「グラァスプ」となる。いずれの場合も「ラ」にアクセントを置く。「グラ」をしっかり読み、「スプ」は発声せずに息を抜くように発音するのがコツである。「スプ」まではっきり読んでしまうとネイティブの発音から大きく遠ざかってしまうため注意したい。

「grasp」の活用変化一覧

動詞としての「grasp」の活用変化は規則変化に該当する。即ち、現在分詞が「grasping」、三人称単数現在形が「grasps」、過去形と過去分詞が「grasped」となる。これは他動詞でも自動詞でも共通である。また、名詞の場合、複数形は「grasps」となる。動詞の三人称単数現在形と発音も共通しているため、文の構造や文法などからどちらで用いられているかを判断するとよいだろう。

「grasp」の語源・由来

graspの語源は古英語の「graepsan」である。これは「触れる」という意味を持つ単語であった。これが中期英語に入ると「graspen」(手探りで見つけ出す)となり、手探りで見つけ出した、即ちその手に「掴んだ」ことから現在の「grasp」という言葉になったと考えられる。なお、同様の語源を持つ言葉に、「grope」(手探りする)がある。

「grasp」の覚え方

graspには意味と発音を覚えるための語呂合わせがいくつか存在する。例えば、「グラッ！スープをしっかり握って地震でもこぼさないウェイター」という語呂合わせは、「グラッ！スープ」がgraspの発音、「しっかり握って」がgraspの意味となっており、文頭に来ていることから関連付けて覚えやすくできていると言えるだろう。また、絵本の「ぐりとぐら」の登場人物の一人である「ぐら」を使った覚え方としては、「ぐら、スプーンを握る」というものがある。「ぐら、スプ」が発音、「握る」が意味となっており、シンプルですぐに覚えられる語呂合わせとなっている。

「grasp」と「grab」の違い

graspの類語に「grab」が存在する。どちらも「握る」という大枠の意味で共通しているが、実はニュアンスが微妙に違う点に注意が必要となるだろう。具体的には、graspがしっかりと握っているというニュアンスを持つのに対して、grabは急に掴む、乱暴に掴みかかる、鷲掴みにするといったニュアンスとなっている。また、graspには「把握する」など意味で使われることもあるが、grabには「把握する」「理解する」といった意味は持たない点も特筆に値するだろう。

「grasp」の類語

先述したgrab以外にも、graspには様々な類語が存在する。例えば、握るという意味では「grip」が挙げられるだろう。ハンドルや手すり、ゴルフクラブなどの棒状のものを握る場合はgraspよりもgripが適している。また、より軽く握ることを表現したい場合は「hold」を用いる。コントロールを失わないようにとりあえず保持するニュアンスである。空中で動いているものを手で「掴み取る」ことを表現する場合には「catch」を使うとよいだろう。

「grasp」を含む様々な用語の解説

以下では、「grasp」を含む専門用語について、その意味などを解説する。

「GRASP」とは

頭字語として「GRASP」が用いられる場合は、「General Responsibility Assignment Software Pattern(Principle)」の略語となる。日本語に訳すと「汎用的な責任割当のパターン/原則」である。ソフトウェア開発においてオブジェクト指向設計を行う際の9つのパターンセットもしくは原則セットを指す。

「GRASP-HACCP」とは

GRASP-HACCPは、食品を製造する際の安全性確保の管理手法である「HACCP」を運用する際に、衛生管理情報をWeb上で一元管理・閲覧を行うことができる業務用クラウドシステムである。サラヤ株式会社が開発・販売しており、HACCPにおいて重要視される記録管理を省力化して業務効率を上げることができる点が最大の特徴となっている。

「grasp」の使い方・例文

graspは他動詞で使う場合、graspの後ろに「動作の対象」を目的語として配置する。例えば、「He grasps a curtain.」(彼はカーテンをぎゅっと握った)といったふうに、SVOの文型で用いるのが基本となる。また、誰かの身体や衣服の一部を掴んだ、という場合は「He grasps her by the shouder.」(彼は彼女の肩をしっかりと掴む)と言った形で、「掴まれた人+by the+掴まれた部位」と表現する。

（2023年2月22日更新）

OR事典

GRASP法

読み方：ぐらすぷほう
【英】：GRASP (greedy randomized adaptive search procedure)

多スタート局所探索法において， 局所探索法の初期解生成にランダム化欲張り法 （すなわち欲張り法にランダム性を加味したもの）を用いるもの． 欲張り法は通常各反復において局所的評価値の最も良い選択肢を採用するが， ランダム化欲張り法では局所的評価値の良いものいくつかの中から ランダムに選択を行う． 比較的精度の良い多様な解を局所探索の初期解として生成できるという利点がある．

ウィキペディア

GRASP

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/11/03 00:05 UTC 版)

GRASPとは、General Responsibility Assignment Software PatternあるいはPrinciple（汎用的責任性割り当てパターン/原則）の頭字語であり、オブジェクト指向設計に向けた九つの原則セットまたはパターンセットである。計算機科学者クレーグ・ラーマンの1997年著作「実践UMLパターン -Applying UML and Patterns-」で初めて紹介されている。

「ソフトウェア開発において決定的な設計ツールになるのは、設計の原則の中で磨き上げられたメンタルであって、UMLやその他のテクノロジーではない」がラーマンの主張であり、GRASPとはオブジェクト指向開発を助けるためのメンタルツール（mental tool）であると定義している[1]。

九つのパターン

情報エキスパート -Information Expert-

• 質問：オブジェクトに責務を割り当てる原則とは何か？
• 回答：その責務を全うするのに必要な情報を持つクラスに割り当てるべきである。

このパターンは、オブジェクトに責務を割り当てる際の一般的な原則である。情報エキスパートパターンは、情報のエキスパート、すなわち必要な情報を全て持っているクラスに責務を割り当てるべきとする。この原則は、ソフトウェアシステムにおいての責務と演算を集中させない(Big ball of mudとは対照的である)。責務と意思決定の分散が進むと情報の隠蔽化が促進され、他のクラスと情報エキスパートクラスの実装との結合の度合いが小さくなる。情報エキスパートパターンを適切に使いこなしたシステムは理解しやすく、維持・拡張が簡単で、また将来の開発で再利用できる可能性が高まる。マーティン・ファウラーは、Web の記事 「GetterEradicator」でラーマンの情報エキスパートを参照している。

高凝集 -High Cohesion-

• 質問：クラスはどのようなプロパティとメソッドで構成されるべきか？
• 回答：一つの責務を全うするのに必要最低限かつ、その責務に特化しているプロパティとメソッドのみで構成されるべきである。

このパターンは、オブジェクトが適切に責務を集中させており、管理・理解が可能な状態を保つための尺度である。高凝集性とは、ある要素の責務が強く関連しており、またその要素に集中していることを意味する。クラスやサブシステムにプログラムを分解するのは、システムの凝集性を高める活動の例だと言える。逆に凝集性が低いということは、関連のない責務を持ちすぎている場合である。凝集性が低い要素は理解が難しく、再利用・維持管理が困難で、変更も行いづらい。

疎結合 -Low Coupling-

• 質問：クラス間の関連性と依存性はどのように定義されるべきか？
• 回答：可能な限り小さくするべきである。関連性を少なくするとは各クラスの公開メンバを少なくすることである。依存性を少なくするとは公開クラスを少なくすることであり、その具体策としては特定のインターフェースに公開クラス情報を集中させることである。

クリエイター -Creator-

• 質問：誰がオブジェクトAを生成するべきか？
• 回答：Aのコンポジション先になる者、Aのアグリゲーション先になる者、Aの生成を記録していく者、Aを密接に使用する者、Aの生成に必要な情報を持つ者などである。

このパターンは、クラスの新しいインスタンスを作成することに責任を持つのは誰かという問題を解決する。オブジェクトの作成は、オブジェクト指向のシステムではあらゆるところで行われる活動であるから、生成者パターンは重要である。生成者パターンを有効に用いるシステムは、疎結合性が高くなり、理解のしやすさ、カプセル化が促進され、オブジェクトが今後再利用できる可能性が増加する。たとえば、二つのクラスＡ，Ｂがあったとき、B が A を包含する、A を合成・集約する、A を密接に使用する、A の初期化情報を持っているといった場合、クラス B がクラス A の作成に責任を持つべきであり、B は A の生成者として自然なオブジェクトと言える。Factoryパターンは、複雑なオブジェクト作成ロジックなど、特別な検討が必要な場合に、「生成者」の替わりになる方法である。この方法では、Factoryと呼ばれる「純粋な人工的」（後述）であるオブジェクトを作ってオブジェクトの作成を行わせることで目的を達する。

コントローラ -Controller-

• 質問：誰が入力システム・イベントを扱う責務を持つべきか？
• 回答：該当システムをカバーするコントローラが、該当システムで発生する全入力イベントを扱うべきである。

このパターンは、システム全体やユースケースシナリオを表現するユーザインタフェースでないクラスにシステムイベントを扱う責務を割り当てる。ユースケースのコントローラはユースケースの全てのシステムイベントを扱い、複数のユースケースで使用できる（例えば、「ユーザーの作成」「ユーザーの削除」というユースケースで、それぞれUserControllerオブジェクトを持たずに一つのオブジェクトを共有してよい）。コントローラは、UI層以上にあって、システムに対する操作を受け取り調整する（制御する）最初のオブジェクトとして定義される。コントローラは、他のオブジェクトに必要な作業の実施を委譲する。他のオブジェクトの活動を制御し、連携させる。一般的なレイヤ構造を持ったオブジェクト指向のシステムでは、GRASP コントローラはアプリケーションやサービス層の一部と考えられる (アプリケーション層/サービス層、ドメイン層を明確に区別している場合）。

間接化 -Indirection-

• 質問：どういったオブジェクトに責務を割り当てると、オブジェクトたちの密結合を回避できるのか？どのようにオブジェクトを切り離せば、リユーザブルな疎結合を実現できるのか？
• 回答：オブジェクト同士が直接つながらないように、コンポーネントまたはサービスを仲介する中間オブジェクトを用意して、それに責務を割り当てるべきである。

このパターンは、二つの要素の中間にオブジェクトを設け両者の仲介を行う責務を割り当てることで、二つの要素間の疎結合性（および再利用の可能性）を促進する。Model View Controllerにおいてコントローラがデータ（モデル）と表現（ビュー）の仲介を行うのはその一例と言える。

多態性 -Polymorphism-

• 質問：どのように型のすげ替え部分を扱うべきか？どのようにすげ替え可能なコンポーネントを作るべきか？
• 回答：型別の動作のすげ替えならば、同じ動作名義に対してオブジェクト別の異なる動作内容を結合できるポリモーフィックな型を用意するべきである。

このパターンは、型に基づいて振る舞いの変動部分を定義する責務を、変動が起きる型に割り当てる。これは、ポリモルフィックな操作を持たせることで実現できる。

保護的変容 -Protected Variations-

• 質問：構成の変化を前提にしたオブジェクトたちが、自身の変化による他者への影響波及を回避するには、どのようにオブジェクトを設計するべきか？
• 回答：オブジェクトの変化する構成の箇所を特定した上で、その箇所をカバーするための不変構成のインターフェースを用意するべきである。

このパターンは、周辺の要素（オブジェクト、システム、サブシステム）の変動から注目する要素を保護するために、不安定な部分をインタフェースを用いて収束させ、ポリモーフィズムを用いてインターフェイスを実装させる。

純粋造形 -Pure Fabrication-

• 質問：専門領域オブジェクトをサポートする、専門領域から離れた純粋な機能実体とはあり得るのか？
• 回答：オブジェクトに自由に分離結合できる、特定機能の凝集体を操作するためのインターフェースがそうである。

このパターンは、問題領域に登場する概念を表すクラスではなく、疎結合や、高凝集性、それらから得られる再利用可能性を実現するために作られるクラスである（情報エキスパートで実現できない場合)。この種類のクラスはドメイン駆動設計ではサービスと呼ばれる。

参考文献

• Larman, Craig (2005) [2004]. Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd ed.). Prentice Hall PTR. ISBN 0-13-148906-2 

関連項目

• デザインパターン (ソフトウェア)
• SOLID
• ドメインモデル貧血症(Anemic Domain Model) - 情報エキスパートの原理、すなわちデータを保持するクラスに責務を割り当てることで、ドメインモデルの貧血症を避けることができる。