[Design Pattern] デザインパターンの紹介

こんにちは。明月です。

この投稿はデザインパターンの紹介に関する説明です。

デザインパターンとは英語でDesignですが、我々が考える画面デザインという意味ではなく、設計の意味です。つまり、設計パターンということです。

始めにこのデザインパターンを提案する人はGoFと呼ばれる四人のパソコン科学者です。私のけ願書で勉強したことではなく、翻訳書や解説書で勉強したのでGoFに関して詳しく説明ができません。

とにかく、その四人がプログラムコードを作成する方法でどうすれば効率的なコードパターンを設計できるか、実際の業務からプログラムに作成する時に綺麗に解析できるパターンを纏めておいたことです。

でも、今はこのデザインパターンは効率的な設計パターンとしても重要ですが、開発者(デベロッパー)の間の暗黙的なコードルールもあります。

例として私の経験を話します。

私が大学校を通う時、つまり役10年前にはデザインパターンを軽く勉強したことがあります。

その時にはオブジェクト指向プログラミング(OOP)を完全に理解できない状況で勉強しようと思ったので理解もよくできませんでした。また、先輩からもデザインパターンはプログラムを勉強することで邪魔だと聞いたことがあるので重要だと思っていませんでした。

その状況で卒業して実務経験で3~4年の時に実力が停滞期が来ました。その時に設計実力も伸びないし勉強しても、毎回の基礎研究に大変でした。

それで始まったことはOpen Source Projectに参加することでした。オープンソースプロジェクトに参加してショックをたくさん貰いました。その時にプログラム開発に関して自身もあったし勉強も十分だと思いましたが、オープンソースが全然理解できませんでした。

同然、理解ができないから参加も上手くできないし、時々に理解できる部分があって修正して要請(Request)してもいつも断り(Decline)でした。個人的にすごくスランプが来た時でした。

その状況でいつも断り(Decline)だけ貰って、勇気を出してなぜ断り(Decline)ですかと聞きました。返事はコーディング規約も合わないし、パターン式で解決しなければならないので、単純コーディングアルゴリズムで解決しようとするから他のバグが発生する可能があると答えを貰いました。

今、考えてもすごくショックですが、その後からプログラムプロジェクト工程や設計テクニック、標準規約などがなぜ重要かを分かることになりました。考えたら私にはもう一つの跳躍をすることができる機会になったような気もします。(今はプロジェクトでコーディング実力は10%で工程と設計がすごく重要だと思います。)

その後に様々なデザインパターンや規約に関して勉強するし工程に関しても考えたことになりました。いつからかプロジェクトでコーディングより設計テクニックがどのほど重要か分かることになりました。

デザインパターンに話したら様々な解析本では設計的な問題を解決する方法だと説明します。もちろん、間違い話ではありません。同然、当たり前の話です。でも、私の考えは様々なソースの解析をしやすくする(可読性)ための設計的な約束(規約)だと思います。

設計的な問題はデザインパターンによらなくても解決する方法は多いです。でも、自分だけの方法や設計で修正するとその設計の意味や理由に関して自分以外は分からなくなります。つまり、そのソースを他人がみると一日にデバッグしなければならないです。

最近はプロジェクトを設計する時に様々なオープンソースを使うし、オープンソースも仕様によって修正する時もあります。

オープンソースはデザインパターンに合わせて設計されているので、デザインパターンをよく知っているならデバッグなしでソースだけでプログラムを解析することができます。

以前、どの本で読んだかは忘れましたが、よく設計するし作ったプログラムはコメントやドキュメントが要りません。コード自体が仕様書ので、ドキュメントですが、またコメントを付ける理由があるかという文言を読みました。

私がプロジェクトをする時にいつも考えている文言です。よく作ったプログラムはコメントやドキュメントがいらないという意味はデザインパターンや規約とおりに作成したという意味です。

デザインパターンを理解することになるとオープンソースを読めることになります。いつか私がデザインパターンを少し理解した時にJavaのSpringフレームワークのソースを見たことがあります。その時にソースだけでプログラム仕様が読めました。

つまり、デバッグをしなくてもフレームワークがどのように動くかどのように使ったらよいかを分かることになったことです。なので、オープンソースフレームワーク本を見る必要がありませんでした。例えば、Spring Framework本です。

でも、Spring Frameworkはすごく大きいなのでよく整理しておいたドキュメントなしですべて解析することは大変ですね。

デザインパターンにはどのぐらいメソッド命名やクラス命名方法も決めています。例えば、GetInstance()ならSingletonパターン、FactoryBuilder()ならBuilderパターンとFactoryパターンということです。つまり、その関数やクラス名ならソース内部を見なくてもどのロジックかを推測ができます。

デザインパターンを勉強する時、関連な本をみるとクラスダイアグラムや複雑なソースなどで説明していることが多いですね。例えば、Oracleデータベースを使いましたが、mysqlに変更したい。その時にはどのパターンを利用すると効率です。。という説明がある本です。

でも、デザインパターンははっきり決めていることではなく、解析によって、仕様によって、状況によって、プログラム言語やアルゴリズムによっても変わることがあります。

なので、始めに勉強する時には難しかったんでした。その本が悪いということではなく、正しいですが、状況によりパターンが変わるので難しく感じますね。

デザインパターンを正確に理解するためにはオブジェクト指向プログラミングの基礎知識やアルゴリズムを理解しておかなければならないです。

私はできれば理解しやすいように説明してみます。

デザインパターン目次

1. 生成パターン

- インスタンスを生成する（new）の定義です。クラスのインスタンスを生成を制限したり、あるいは簡単に宣言するためのパターンです。実際のプログラムのパフォーマンスに影響を与えるパターンです。

1-1. Singletonパターン -

1-2. Builderパターン -

1-3. プロトタイプパターン -

1-4. Factory Methodパターン -

1-5. Abstract Factoryパターン -

2.構造パターン

- プログラムのコーディングをする時、どのような形式で作成して読みやすく、あるいはパフォーマンスを上がるような構造のパターンです。

2-1. アダプタパターン -

2-2. 合成パターン -

2-3. ブリッジパターン -

2-4. Decoratorパターン -

2-5. ファサードパターン -

2-6. Flyweightパターン -

2-7. プロキシパターン -

3.行為パターン

- プログラム全体のクラス間の形状、設計的なパターン、そしてインスタンスをどのようにが効率的に設計するかのパターンです。

3-1. 責任チェーンパターン -

3-2. コマンドパターン -

3-3. インタプリタパターン -

3-4. 反復子のパターン -

3-5. 調停のパターン -

3-6. メメントパターン -

3-7. Observerパターン -

3-8. 状態パターン -

3-9. 戦略パターン -

3-10. テンプレートメソッドパターン -

3-11. 訪問者のパターン -

ここまでデザインパターンの紹介に関する説明でした。

ご不明なところや間違いところがあればコメントしてください。