Javaのデザインパターンはアルゴリズム？
受付中
回答 4
投稿
- 評価
- クリップ 1
- VIEW 2,056
退会済みユーザー
私の認識では、よくある問題につき、それをプログラムのアルゴリズムで解消するというものがデザインパターンだと思っていました。
ですがデザインパターンの本を見たところ、iteraterだったら、そのiterater用のプラグインを読み込んで、それを使っているように思えました。
考え方というよりは、解決策があるので、それを使ってしまおうということなんでしょうか？
-
気になる質問をクリップする
クリップした質問は、後からいつでもマイページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
クリップを取り消します
-
良い質問の評価を上げる
以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します
-
評価を下げられる数の上限に達しました
評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる
teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 過去に投稿した質問と同じ内容の質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します
この機能は開放されていません
評価を下げる条件を満たしてません
質問の評価を下げる機能の利用条件
この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
-
メールアドレスの認証
メールアドレスの認証
-
質問評価に関するヘルプページの閲覧
質問評価に関するヘルプページの閲覧
+1
アルゴリズムとデザインパターンは近いです。しかし、大きな部分で違います。
アルゴリズムは、データ構造を含んだ”解法”のことですが。
（GoFの）デザインパターンは、オブジェクト指向においてのクラス設計のパターンことで、乱暴にいうならデータ構造のことです。
つまり、アルゴリズムは問題に対する”解法”のことで、デザインパターンは問題に対する”データ構造”を主においています。
なぜ、データ構造に名前を付ける必要があったのかということになります。これは私見ですが、オブジェクト指向によって、飛躍的にデータ構造の表現が豊かになったことがあると思います。どのようにクラスを設計するとわかりやすく拡張しやすいコードが書けるのか、ということが出発点だと思っています。
そこで、iteraterのパターンですが、GoFのデザインパターンが出たのが１９９５年で20年前です。Javaのバージョン１（１９９６年）もない時代でした。当時の言語仕様では、繰り返しを行うfor-each構文を持つ言語は多くありませんでした。（Javaでは２００４年から）
そのため、iteraterを自分で組む必要があったのです。これによってか、各言語でfor-each構文が実装されていきました。結果、デザインパターンの中でもiteraterは不要のものとなっていったのです。
このようにデザインパターンは今ではあまり役に立たなくなったものもありますが、それだけオブジェクト指向でコーディングに大事なものを詰め込んだ定石の一覧となってます。そして、いくつかは現在でも良く利用されているものです。また、クラスの設計を学ぶに当たりすごく良い教科書となると思います。
少なくとも、私はGoFのデザインパターンでオジェクト指向を身に着けました。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
0
他社に迷惑を掛けたので謝意を示すとして
「迷惑掛けてごめんね♪」ってチャットを入れるだけでも謝意を伝える行動と言えなくもないです(?)が、実際は踏襲しておくべき手順や考慮するべき内容があり、そうしたほうが目的達成に大きく貢献します。
デザインパターンもある種のロジックを構築する際に、考慮に入れた方がよい項目、大抵の場合うまく行く機能の構成と処理順序、設計方法などをまとめた物です。
但し「○○製品の不具合に対するお詫びメール雛形」のように具体的で小さなスコープではなくて、「お詫びメールの書き方」のような大まかな枠でのものなので、ケースによっては適用できない場合も出てきます。(デートをすっぽかしたときに、「○○社の××と申します。いつもお世話になっております。このたびは～」と相手にメールするのは合わないわけで)
逆にプラグインや既成のライブラリ等を使うのは用途を限定している場合で、
「氏名="",社名="",部署="",本文＝””,シグネチャ=」にデータを与えればテンプレートに沿って例文を作成してくれます。のように汎用性を落として変わりに狭いスコープでの作業効率を上げたりします。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
0
アルゴリズムは、実装です。
設計に基づいて実装します。
デザインパターンとアルゴリズムは、根本的に異なるものです。
デザインパターンを解説している記事には、サンプルコードが掲載されていることがあります。
これは、この設計に基づいて実装するとこうなります。というもので、そのコードはデザインパターンそのものを示している訳ではありません。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
0
深く理解しているとは言い難いのですが
ある問題があった時に解決する手順が
アルゴリズム
ありがちな要求に対し
それをオブジェクト指向で実現する上での
ありがちな解決法をまとめたものが
(狭義の)デザインパターン
だと考えてます
デザインパターンではありがちな要求に対して
●必要なクラスやそれらの関係をどう設計するか?
親クラスにするのか子にするのか、
あるいは同じ親クラスを持つ兄弟クラスにするのか
もしくは単に使用するのかなど
●クラスにどんな変数やメソッドを持たせるか ?
●作ったクラスをどう使うか?
どんな場合にどういう順序で
インスタンス化したり変更したり
メソッドを実行させたりするか
などがまとめられています
よく言われるのがデザインパターンは
実際にクラスを設計したりコードを書いたりする上で
そのままでは使えない場合が多いということです
要求を解決する時に組み合わせたり
部分的な考え方を参考にしたり
場合によっては人と設計やコードの意図を
共有したりするためにあるもんだと思われます
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
15分調べてもわからないことは、teratailで質問しよう！
- ただいまの回答率 88.19%
- 質問をまとめることで、思考を整理して素早く解決
- テンプレート機能で、簡単に質問をまとめられる