asatoの技術的な日常日記

「成長に最大の責任をもつ者は、本人であって組織ではない。自らと組織を成長させるためには何に集中すべきかを、自らに問わなければならない」  非営利組織の経営 - ピーター・ドラッカー

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

デザイン:対象と操作

ソフトウェアは、もちろん成果物。成果物を出力するには、なんらかのプロセスが必要。

基本的には、ソースコードをコンパイルして得られるのがソフトウェアだと思う(スクリプトの話はなしで)。

プログラマーは、コードを編集する。要求仕様を満たすように編集する。

さて、ソースコードを抽象化して考えてみよう。ここでの抽象化とは、コメントや空白などを除くことを意味する。抽象化した対象にたいして、プログラマは編集操作を行う。Java プログラムの一部を具体例として考えてみよう。

抽象化した対象をどう表現するか。ここでは、Eclipse なんかでであるようにGUIで表現できるとする。もしくはもっと簡単に、変数名と値を表示するだけとする。

operator_class.png


これで対象が決まったので、次は対象に対する操作を考えてみる。一番単純なのは、クラス名を変更するといった操作。

operator_class2.png


ここで言いたいのは、対象が決まれば、可能な操作が決まるということ。もちろん、可能な操作は勝手には決まらない場合もある。

ソースコードに対する編集操作と、ソースコードを抽象化した表現対象に対する操作は異なる。ソースコードに対する操作には、たとえば、「コメントを追加する」や「空白を追加する」「タブを追加する」「改行する」などの操作が考えられる。しかし、そのような操作は、抽象化した対象に対しては意味を持たなくなる。


次に、操作を抽象化することについて考えてみよう。代表的なのはリファクタリング。たとえば、「スーパークラスの抽出」リファクタリングを考えてみよう。

operator_refactor.png


ここで言いたいのは、抽象化された対象に対する操作のみを使って、より抽象度の高い操作を表しているということ。つまり、「クラスを作成する」などの操作を行ってはいるけどソースコードレベルの操作、たとえば「改行する」などは操作として含まれていないという点。


さて、ここからが今回の話のコアとなる部分。過去の記事で何度か設計という行為は、意思決定の観点から考えられると言ってきた。考えられるとは、つまり、意思決定の観点から抽象化して考えられるとしてきた。

意思決定とは、選択肢からの選択を意味する。つまり、ある操作を表す。そして、操作があるということは操作対象が存在する。

具体例で考えてみよう。状態遷移を実現する必要がある場合、どんな決定を行うだろうか? 選択肢としては、「ifによる分岐」「Stateパターン」「遷移テーブル」などがあると思う [アジャイルソフトウェア開発の奥義]。

ここでは、Stateパターンを選択したとする。

operator_state.png


Stateパターンの基本構造は、こんな感じ。
operator_state2.png



次にStateパターンが適用された構造に対する操作を考えてみよう。二つの観点から考えてみる。

(1)Stateパターンかどうかに関係なくできる操作。たとえば、Stateパターンが適用されていると知らなかったとする。すると、どんな操作が可能か。

(2)Stateパターンが適用されているからできる操作。


まず一つ目だけど、どんな操作でもできる。Stateパターンでなくなるような操作ですら可能。



次に二つ目だけど、たとえば、「ConcreteState」を追加・削除するなんてのは適切な操作の一つ。他にも、request/handleメソッドのペアを追加・削除するなんてのも可能な操作。一方で、request メソッドのみを削除するなんてのは不適切な操作。


まとめ:

対象が決まれば、可能な操作が決まる。

スポンサーサイト

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://asatohan.blog77.fc2.com/tb.php/89-a101c925
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。