Javaのデザインパターンはアルゴリズム？

Question

Javaでデザインパターンというものを学ぼうと思っているのですが、概要があまりうまくつかめていません。

私の認識では、よくある問題につき、それをプログラムのアルゴリズムで解消するというものがデザインパターンだと思っていました。

ですがデザインパターンの本を見たところ、iteraterだったら、そのiterater用のプラグインを読み込んで、それを使っているように思えました。

考え方というよりは、解決策があるので、それを使ってしまおうということなんでしょうか？

Answer 1

Javaでデザインパターン、しかもiterarerがでてくるということでGoFのデザインパターンという前提で回答します。書いてみたらデザインパターン万歳な文章になりました。聞いてないことまでこたえてごめんなさい。

アルゴリズムとデザインパターンは近いです。しかし、大きな部分で違います。

アルゴリズムは、データ構造を含んだ”解法”のことですが。
（GoFの）デザインパターンは、オブジェクト指向においてのクラス設計のパターンことで、乱暴にいうならデータ構造のことです。

つまり、アルゴリズムは問題に対する”解法”のことで、デザインパターンは問題に対する”データ構造”を主においています。

なぜ、データ構造に名前を付ける必要があったのかということになります。これは私見ですが、オブジェクト指向によって、飛躍的にデータ構造の表現が豊かになったことがあると思います。どのようにクラスを設計するとわかりやすく拡張しやすいコードが書けるのか、ということが出発点だと思っています。

そこで、iteraterのパターンですが、GoFのデザインパターンが出たのが１９９５年で20年前です。Javaのバージョン１（１９９６年）もない時代でした。当時の言語仕様では、繰り返しを行うfor-each構文を持つ言語は多くありませんでした。（Javaでは２００４年から）

そのため、iteraterを自分で組む必要があったのです。これによってか、各言語でfor-each構文が実装されていきました。結果、デザインパターンの中でもiteraterは不要のものとなっていったのです。

このようにデザインパターンは今ではあまり役に立たなくなったものもありますが、それだけオブジェクト指向でコーディングに大事なものを詰め込んだ定石の一覧となってます。そして、いくつかは現在でも良く利用されているものです。また、クラスの設計を学ぶに当たりすごく良い教科書となると思います。

少なくとも、私はGoFのデザインパターンでオジェクト指向を身に着けました。

Answer 2

私自身がデザインパターンやアルゴリズムについて
深く理解しているとは言い難いのですが

ある問題があった時に解決する手順が
アルゴリズム

ありがちな要求に対し
それをオブジェクト指向で実現する上での
ありがちな解決法をまとめたものが
(狭義の)デザインパターン

だと考えてます

デザインパターンではありがちな要求に対して
●必要なクラスやそれらの関係をどう設計するか?
親クラスにするのか子にするのか、
あるいは同じ親クラスを持つ兄弟クラスにするのか
もしくは単に使用するのかなど
●クラスにどんな変数やメソッドを持たせるか ?
●作ったクラスをどう使うか?
どんな場合にどういう順序で
インスタンス化したり変更したり
メソッドを実行させたりするか
などがまとめられています

よく言われるのがデザインパターンは
実際にクラスを設計したりコードを書いたりする上で
そのままでは使えない場合が多いということです

要求を解決する時に組み合わせたり
部分的な考え方を参考にしたり
場合によっては人と設計やコードの意図を
共有したりするためにあるもんだと思われます

Answer 3

デザインパターンは、設計。
アルゴリズムは、実装です。
設計に基づいて実装します。
デザインパターンとアルゴリズムは、根本的に異なるものです。

デザインパターンを解説している記事には、サンプルコードが掲載されていることがあります。
これは、この設計に基づいて実装するとこうなります。というもので、そのコードはデザインパターンそのものを示している訳ではありません。

Answer 4

アルゴリズムよりも仕様や設計を作成する際に参考にする、問題解決チャートやテンプレートやフレームワークに似ています。

他社に迷惑を掛けたので謝意を示すとして
「迷惑掛けてごめんね♪」ってチャットを入れるだけでも謝意を伝える行動と言えなくもないです(?)が、実際は踏襲しておくべき手順や考慮するべき内容があり、そうしたほうが目的達成に大きく貢献します。

デザインパターンもある種のロジックを構築する際に、考慮に入れた方がよい項目、大抵の場合うまく行く機能の構成と処理順序、設計方法などをまとめた物です。
但し「○○製品の不具合に対するお詫びメール雛形」のように具体的で小さなスコープではなくて、「お詫びメールの書き方」のような大まかな枠でのものなので、ケースによっては適用できない場合も出てきます。(デートをすっぽかしたときに、「○○社の××と申します。いつもお世話になっております。このたびは～」と相手にメールするのは合わないわけで)
逆にプラグインや既成のライブラリ等を使うのは用途を限定している場合で、
「氏名="",社名="",部署="",本文＝””,シグネチャ=」にデータを与えればテンプレートに沿って例文を作成してくれます。のように汎用性を落として変わりに狭いスコープでの作業効率を上げたりします。