ソフトウェア構築手法まとめ
期末試験勉強も兼ねて、ソフトウェア構築手法の類型という意のデザインパターンについてまとめたいと思います。
テスト勉強なのでざっくりとしか書きません。
デザインパターン
デザインパターンはたくさんありますが、一般的にデザインパターンといわれたら、「GoFの23パターン」を指します。
GoFとは、Gang of Fourの略称で、種別は以下の3つがあります。
生成に関するパターン
- singleton patternなど
構造に関するパターン
- Decorator patternなど
振る舞いに関するパターン
- Visitor patternなど
今回は、振る舞いに関するパターンについていくつか解説したいと思います。
振る舞いに関するパターン
State pattern
通常、オブジェクト指向では物体をクラスとしますよね。(enemyクラスとか、食べ物クラスとか)
State patternでは、物体ではなく、物体の状態をクラスとして考えます。
そうすると、「飲み物が減ったので追加で買ってくる」みたいな状態の変化を元にした処理を行うことができます。
これがState patternです。
Command pattern
とあるオブジェクトのメソッドにこれはこうだよって要求を送るとします。(要するに引数)
このとき、要求が大量にあると一つ一つ引数で渡すのは限界があるし、大量にあると気持ち悪いですよね。
なので、要求自体をクラスにしちゃえというのがCommand patternです。
Observer pattern
通常、他のオブジェクトの状態を監視したい時、常にオブジェクトの状態をチェックしなければなりません。
そうなると監視してるやつは大変ですよね。
そこで、オブジェクトが状態を変化させる際に「私の状態変化しました〜」と関連しているものに対して通知するのがObserver patternです。
通知を送ることによって、監視する必要がなくなり、更新があった時のみなんらかの処理をするということができるのでリソース節約とかできそうですね(感想)
Templatemethod pattern
まず、抽象クラスみたいないろいろなクラスの処理の枠組みをまとめたクラスを作成します。(要するにスーパークラス)
そこから、サブクラスを作成し、具体的な処理を決めていきます。
これが、Templatemethod patternです。
助長化を防げますね。
Visitor pattern
Aオブジェクトがあるとします。
Aオブジェクトに、Bオブジェクトが関連付けられています。
このとき、AオブジェクトとBオブジェクトがともに処理を行う場合、処理を全てBオブジェクトに記述してしまいます。
そうすると、新しくBに処理を追加したい時、Aオブジェクトは何もかえる必要がありません。
この、訪問先に全ての処理を任せる形を、Visitor patternといいます。
処理の追加が簡単ですね。やったぜ。
まとめ
たくさんパターンがあって、どれもなるほどなぁと納得のいく目的がありました。
先人の知恵ってすごいですね。
(大学の期末テスト用に作成した記事なのでかなり適当でごめんなさい)