この記事の目的
この記事では、
GoFのデザインパターンを実装してみて感じたことのメモを残すこと
を目的としています。
・・・いずれ、プロジェクトでライブラリアンとして活動するときに参考にしたいです。
本題
★夏休み課題
- Lazy クラスの使い方
- Unity
- HelloWorld
- UI作成
- 画面遷移
- あといろいろ
★なぜ、今GoFなのか？
はずかしい理由なので、晒しておきます。
始まりは、Repositoryパターンについて調査しようとしたことです。
思考１）パターン・・・つまり、デザインパターンだな・・・ ←勘違い(´▽｀)
思考２）デザインパターンということは、GoF！ ←GoF以外知らない(´・ω・`)
思考３）せっかくだから、Repositoryパターン以外のGoFも調べてみよう！ ←本筋からそれてる(/ω＼)
ということで、GoFのデザインパターンを調べ始めて、Repositoryパターンがそれではないことを知りました。
しかし、せっかくなのでGoFのパターンについて、実装しながら学んでみようと思った次第であります(´▽｀)
★参考情報と実装？したコードについて
.NET Design Patterns in C# and VB.NET - Gang of Four (GOF) - doFactory.com
KinakoLabo/Patterns at master · kinakomotitti/KinakoLabo · GitHub
★GoFデザインパターン自分なりの一言まとめ
| パターン名 | 感想 |
|---|---|
| No01_AbstractFactory_Pattern.cs | ★抽象クラスの実装：その１ |
| No02_Builder_Pattern.cs | ★抽象クラスの実装：その２ |
| No03_FactoryMethod_Pattern.cs | ★抽象メソッドのオーバーライドの挙動 |
| No04_Prototype_Pattern.cs | ◆Clone処理をできるようにすること |
| No05_Singleton_Pattern.cs | ☣実行中のアプリケーションの中でインスタンスを１つにする |
| No06_Adapter_Pattern.cs | ★抽象メソッドの処理をオーバーライドし、その処理の中で元処理を呼び出す |
| No07_Bridge_Pattern.cs | ●モデルクラスにデータの操作を集約する |
| No08_Composite_Pattern.cs | ✇木構造を表現する |
| No09_Decorator_Pattern.cs | ☆継承なしで、インスタンスに対し、機能を拡張する |
| No10_Facade_Pattern.cs | ●複雑な処理（ここでは条件分離）の手順を隠蔽する |
| No11_Flyweight_Pattern.cs | ▼共通クラスのプロパティのライフサイクルとその使い方 |
| No12_Proxy_Pattern.cs | ☆Proxy対象のクラスの利用を代行する |
| No13_ChainOfResponsibility_Pattern.cs | ✇再帰呼び出しによる繰り返し処理に適したクラス構造 |
| No14_Command_Pattern.cs | ♠コマンドの処理を集約・引数でコマンドの種別を切り替える |
| No15_Interpreter_Pattern.cs | ★継承先のメソッドの呼び出し |
| No16_Iterator_Pattern.cs | ♪コレクションへの順次アクセスのインターフェースを持つクラスの設計 |
| No17_Mediator_Pattern.cs | ●複雑な処理は、処理の担当者に振り分ける（集約する） |
| No18_Memento_Pattern.cs | 本質がわかっていない( ﾟДﾟ) |
| No19_Observer_Pattern.cs | ☘プロパティの値が変更されたときに処理を実行する |
| No20_State_Pattern.cs | ☯インスタンスの状態を管理する別のクラスを保持する |
| No21_Strategy_Pattern.cs | ♠主処理カートリッジを入れ替えていろいろな処理を実行することができる |
| No22_TemplateMethod_Pattern.cs | ★Baseクラスを使って見ましょう的な感じ |
| No23_Visitor_Pattern.cs | ☸POCOとビジネスプロセスの分離の表現 |
★ピックアップ：Strategyパターン
ユーザーから入力された文字列のチェックを行う処理は、どのようなアプリにおいても実装されるものだと思います。その入力チェック処理について、Strategyパターンを使って可読性・保守性ともに高い実装ができるのではないかと思ったので作ってみました。サンプルコードは以下の通りです。
結構使い勝手が良いと思います。チェッククラスさえ実装されていれば・・・
【ポイント】
・最小の単位のチェック処理を有するクラス＆メソッドを用意する
・仕様に合わせてチェックしたいクラスをList形式のインスタンスに格納する
・Foreachでリストを回して、一つ一つチェックを行う
なお、３つ目のポイントでは、Facadeパターンの考え方を参考にした実装を行っています。
★ピックアップ：Proxyパターン
サンプルコードのように、Mathクラスのメソッド実行前後に処理を付け加えたりするときに便利なパターン。
Mathクラスの利用を代行して処理するというロジックになっている。
「代行して利用する」ということは、（この例ではMathクラスを）継承する必要がない。
「対象のクラスを継承せずに挙動を変更する」という観点では、Decoratorパターンに通じるものがあると感じる。
public double Add(double x, double y) { //なにかしら処理 var returnValue= _math.Add(x, y); //なにかしら処理 return returnValue; }
Decoratorパターン(サンプルから一部抜粋)
public override void Display()
{
//base.Display()では、libraryItem（Video型のインスタンス）.Displayが実行される。
base.Display();
foreach (string borrower in borrowers)
{
Console.WriteLine(" borrower: " + borrower);
}
}
所感
パターン名を覚えるというより、各パターンの中で使われているオブジェクト指向の本質を理解するのが良いと感じました。それぞれのパターンについてまた十分な理解ができていないので、その観点でもっと研究していきます(*´-`)
