デザインパターン-使用しますか?


44

ITの学生である私は、最近、教師の1人からデザインパターンに関する概要を説明されました。私はそれらが何のためにあるのかを理解しましたが、いくつかの側面はまだ私を悩ませ続けています。

大多数のプログラマーによって本当に使用されていますか?

経験といえば、プログラミング中にいくつかの問題があり、しばらくは解決できませんでしたが、Googleと数時間の研究で問題を解決しました。Webのどこかで問題を解決する方法を見つけた場合、これは設計パターンですか?私はそれを使用していますか?

また、開発を開始するとき、あなた(プログラマー)はパターンを探していることに気づきます(ところで、私はどこを見るべきでしょうか?)。もしそうなら、これは確かに私が受け入れ始めなければならない習慣です。

更新:プログラマーがそれらを使用するかどうかを尋ねると、問題を解決するために「ああ、私はそのパターンを使用するべきだ」と思うかどうかを尋ねていると思います。


7
まったく同じ質問ではありませんが、私の答えは同じです。Programmers.stackexchange.com/questions/70877/…–
pdr

4
その過大評価され、誇張された「設計パターン」のほとんどは、OOPプログラミングにのみ関連しています。そして、できるだけ長くOOPから離れる多くの理由があります。
SKロジック

5
Big Ball of Mudを使用するよりも頻繁に使用しています。冗談だ。
sashoalm

唯一の答えは、「適切な場合」という条件文でイエスです
リグ

回答:


114

私が初心者プログラマーだったとき、デザインパターンが大好きでした。デザインパターンを使用しただけではありません。私は彼らに与えました。いつでもどこでも。私は無慈悲でした。あぁ!オブザーバーパターン!どうぞ!リスナーを使用してください!プロキシ!AbstractFactory!なぜ5つの抽象レイヤーを使用するのか?私は多くの経験豊富なプログラマーと話をしましたが、GoF Bookを読んでいるほぼ全員がこの段階を通過していることがわかりました。

初心者プログラマーは設計パターンを使用しません。彼らはデザインパターンを乱用します。

最近では、単一責任原則のような原則を念頭に置き、最初にテストを書くことで、パターンがより実用的な方法で出現するのに役立つことがわかりました。パターンを認識すると、それらをさらに簡単に進めることができます。私はそれらを認識していますが、もはやコードでそれらを強制しようとはしていません。訪問者パターンが出現する場合、おそらく重複をリファクタリングしたためであり、ツリーのレンダリングとその値の加算の類似性を事前に考えたためではありません。

経験豊富なプログラマーは、デザインパターンを使用しません。設計パターンはそれらを使用します。


2
@schlingel-OPサーと呼ばれるのはなぜですか?
-Oded

10
@Oded私は、これらの状況下で「サー」と呼ばれる権利を留保し、楽しんでいます。
ルニボー

3
はい、はい。違反はありません!
-Oded

1
ソビエトロシアでは.. :)
ソランティス

5
良い答えですが、最後の行では深みを出そうとしましたが、それは無意味です。「経験豊富なプログラマーは設計パターンを選択せず​​、実現させます」はどうでしょう。
ギャレットホール

43

認識してもしなくても、ほとんどのプログラマーパターンを使用します。

ただし、日々の作業では、パターンを念頭に置いてプログラミングを開始することはありません。パターンがコード内に出現したことを認識し、名前を付けます。

いくつかの共通パターンはいくつかの言語に組み込まれています-たとえば、キーワードを使用してC#に組み込まれた反復子パターンforeach

目の前の問題の一般的な解決策として使用するパターンを既に知っている場合があります(リポジトリパターンなど -メモリ内コレクションとしてデータを表現することを既に知っている場合)。


13
パターンは、プログラマーが設計と実装のアイデアを伝えるのに役立つ言語であり、システムを実装するために一緒にスロット化できるプログラミングレゴブロックのセットではありません。
マークブース

27
@DeadMGそれはなぜですか?
クリスハーパー

11
@DeadMGは:私は疑いの余地なく愚かなアイデアに目がくらんでされている必要があります-私はあなたはそれが;-)愚かだと思う理由を見ることができない
TREB

2
@ root45-あなたは友人を見る、foreachコンストラクトはプログラミングをあまりにも簡単にします。コレクションの繰り返しのような複雑なタスクが簡単な場合、他の人より優れていると感じるにはどうすればよいでしょうか?私は、私のすべてのCRUDアプリのアセンブリでまだコードを書いています。明らかに@DeadMGの感情は純粋に実用的な天才の1つです。
ChaosPandion

8
@DeadMG-LINQは、.NET 1.0 / 1.1があった頃ではありませんでした。yieldその時も存在しませんでした。キーワードを削除して古いコードを壊す方が良い選択肢だと思いますか?
-Oded

22

pdrがリンクされた回答に示されているように、デザインパターンは、とにかく人々がやっていることに付けられた名前であり人々がそれらのことについて議論しやすくすることを目的としています。

一般に、開始時に学習する価値があります。なぜなら、人々が働くことがわかったソリューションについての洞察が得られるため、長年の経験と試行錯誤の上に築くことができるからです。

パターンに含まれる問題の動機付けの議論は、そもそも問題を攻撃するための良い方法についての洞察を与えるかもしれませんが、パターンの知識がよく知られた既存のソリューションがあることを認識できない限り、あなたはまだただ解決することに集中する必要があります最初に問題

1つまたは複数の既存のパターンを使用することが判明した場合、他の人がコードを理解しやすくなる既製の名前を使用できます。


私が言いたいことの重要な要約のために+1:問題に焦点を合わせ、そして問題がパターンが解決するもののように見える場合にのみ、パターンを適用します。
ジョシュアドレイク

1
デザインパターンがとにかく人がやっていたことに与えられた名前であるという本当の事実を述べる+1 。
miraculixx

12

一般的に言えば、いいえ。私のコードからパターンが出現することもありますが、一般的に、私はそれらを探しませんし、「ああ、ブリッジパターンは私の問題を解決するでしょう!」とは絶対に言いません。

つまりね。ほとんどのパターンは、人々が良いデザインであるかどうかを考慮することなく、悪用され、悪用されます。パターンはアトムではありません。コードはパターンのX順列で構成されていません。すべてのパターンが実際に良いアイデアであるわけではないことや、一部の言語にはパターンよりもはるかに優れた言語レベルのソリューションがあることは言うまでもありません。


+1:パターンが時々誤用されることに同意します。プログラマーがパターンを知っていてクールだと思ったからといって、プログラマーがパターンを使用したコードを見ることもありますが、それによりコードが不必要に複雑になり読みにくくなりました。ブルドーザーでナットを割るようなものです。言語レベルのソリューションに関して、言語レベルのソリューションは、言語によって直接サポートされる単なるパターンではありませんか?それとも違いは何ですか?
ジョルジオ

1
@Giorgio:別の方法で組み立てられ、いくつかのパターンは、言語が特定のことをきれいに表現する方法を欠いているという事実を回避するために使用されます。
デニース

8

はい、私がこれまで出会ったほとんどのプログラマーは、そこにある最も一般的なパターン、泥の大玉を使用しています。彼らは通常、よく設計されたアーキテクチャで始まりますが、特に「至る所で「設計パターンを使用しなければならない」と容赦なくリファクタリングしなければならないと考える場合は、通常ここで終わります。


2
リンクは私の一日を作った
-dukeofgaming

1
痛い。そのWebページにはテキストの書式設定が必要です。
ネイラー

7

それらを使用しますか?

はい、経験豊富なプログラマーは間違いなくそうです。現時点では、ほとんどのデザインパターン(単純なシングルトンのものを除く)の使用を避けることができます。しかし、プログラムを作成し、より複雑なシステムを構築すればするほど、デザインパターンを使用する必要性を感じるようになります。それでも回避すると、システムを拡張し、新しい要件に従ってシステムを変更する必要があるときに痛みを感じるようになります。

Webのどこかで問題を解決する方法を見つけた場合、これは設計パターンですか?

必ずしも。設計パターンとは、特定の目標を達成する(または特定の問題を回避する)ためにクラス、その動作、および相互作用を設計する特定の方法を指します。あなたが遭遇したかもしれないことは、実際には設計上の問題ではなく、特定のAPIをプログラムするための特定の手順のシーケンスかもしれません。たとえば、ソケット接続を確立する特定のシーケンスがあります。間違ってやると、ソケットは通信しません。この一連のステップは、パターンを構成しません。

あなた(プログラマー)はパターンを探していることに気付きますか

はい。設計パターンは「予防は治療よりも優れている」公理を具現化します。事前に特定の設計上の問題を事前に特定できる場合、後で変更に対応するために大規模な再設計を防ぐことができます。そのため、設計パターンを事前に把握し、アプリケーションを構築するときにそれらを使用する必要がある場所を探すことは有益です。

ところでどこに見えるの?

あなたは学生なので、おそらくデザインパターンを刺激する典型的な問題を見たことがないでしょう。Head First Design Patternsをご覧になることを強くお勧めします。最初に設計上の問題を提示し、次に特定のパターンがそれをどのように解決/回避できるかを示します。


5

私が学校にいたとき、デザインパターンは教えられませんでした。そして、私のプログラミングキャリアのほとんどで、レガシーな非オブジェクト指向のコードを使用してきました。近年、彼らはそのような良いアイデアのように聞こえるので、私はそれらを学ぼうとしました。しかし、本を取り上げたり、そのテーマに関するチュートリアルを読んだりするたびに、私の目が眩しくなり、実際にそれらについて何も学んでいないことを告白しなければなりません。

人前でそれを認めただけでは信じられない。私はおそらく私が長年にわたって確立したかもしれないオタクの信用を失ったと思います。


3

流行を探してはいけない

特定の問題に対する標準的なプログラミングソリューションは、デザインパターンと見なすことができます。デザインパターンの人気度や、他のプログラマがそれらを使用するかどうかは関係ありません。

まだ発明/指定されていないデザインパターンを既に使用している可能性があります。

それらを使用しようとしないで、彼らの言葉で考えてみてください

設計パターンの問題は、プログラマーが問題をそれらに当てはめたい場合があることです。

設計パターンの設計規則には解決すべき典型的な問題があることを忘れないでください。設計パターンを組み合わせて他の大きな問題に取り組むこともできます。これは、サービス指向アーキテクチャの典型的なものです。SOAパターンの一部を参照してください

野生で探してください

適用された設計パターンを見つけるオープンソースプロジェクトがたくさんあります。頭に浮かぶ1つの例はJoomlaです。シングルトンオブザーバーが見つかります。GUIライブラリはありますDecoratorパターンをコマンドパターンが多分実装、およびフライ級

データパターンなどの他のパタ​​ーンがあります。たとえば、Doctrineプロジェクトのみが使用しているもの、アクティブレコードパターン(1.x)、エンティティマネージャーパターン(2.x)、作業単位リポジトリクエリオブジェクトメタデータマッピングデータマッピング、および戦略パターンのような他のより一般的なもの、およびデコレータパターン

選択すべき興味深いソリューションがたくさんあります。マーティンファウラーのエンタープライズアーキテクチャのパターンを参照してください。データモデルパターンもあります

ちょうど時が来たらそれらを学ぶ

それらを学び、それらを知り、それらに夢中になり、プログラミングの問題xを解決する方法がわかるとき、その時までにあなたはより良いプログラマーになるでしょう。

建築家になる

問題を解決するためにパターンの観点で考えることができると、効果的にあなたをソフトウェアアーキテクトに変えると思いますソフトウェアアーキテクトになりたくない場合でも、デフォルトでは、ソリューションの技術的品質が向上し、設計の点でよりクリーンでスケーラビリティが向上します。


1

私はC ++で約7年間プログラミングし、約2年前にパターンを学びました。ほとんどのパターンにはおそらくいくつかのアプリケーションがありますが、私の使用法では、他のパターンよりも優れているものがあります。あなたはそれらを使用している理由を考える必要があります。

イテレータパターンは、実際にコードをより混乱させ、不要な複雑さを追加しました。STLベクトル型のtypedefを使用して、同じ保守性を得ることができます。そして、反復されるクラスに加えた変更は、反復子クラスにも加える必要があります。

ただし、ファクトリメソッドは、提供するポリモーフィズムに基づいて非常に便利です。誰が言ったかは忘れてしまいますが、「再利用性とは、古いコードが新しいコードを使用できることを意味します」という文言は、ファクトリパターンでは間違いなく当てはまります。

テンプレートメソッドパターンを「デザインパターン」であることさえ知らずに何年も使用しています。

Observerパターンは、場合によっては役立つこともあれば、役に立たないこともあります。Observerパターンのオーバーヘッドの複雑さが価値があるかどうかを判断するために、複雑さを予測する必要がある場合があります。約10のサブスクライバーを使用するプログラムがあり、さらに多くのサブスクライバーがある可能性があるため、オブザーバー/サブスクライバーパターンが役立ちました。ただし、別のプログラムには2つのGUIディスプレイがあります。私はこのプログラムにオブザーバーパターンを実装しましたが、単純に複雑さを増し、ディスプレイを追加することを期待していないため、ほとんど不要です。

常にパターンを使用すると言う人は、プログラムが無限に複雑になることを想定していると思いますが、すべてと同様に、複雑さに関して損益分岐点があります。


1

Lunivoreに追加します。これを最初の本から引用したい

        ## **Three steps to great software** ##     
  • ソフトウェアが顧客が望むことを確実に行う
  • 優れたオブジェクト指向の原則を適用する
  • 保守可能で再利用可能な設計を目指して

これは、システムが想定どおりに動作した後の第3段階です。パターンを適用して、今後数年間ソフトウェアを準備できるようにします。


0

大多数のプログラマーによって本当に使用されていますか?

そうだと思います。ADO.Netには、パターンを特化する領域によって異なる場合がありますが、簡単な例を示すDataAdapterクラスがあります。

経験といえば、プログラミング中にいくつかの問題があり、しばらくは解決できませんでしたが、グーグルと数時間の研究で問題を解決しました。Webのどこかで問題を解決する方法を見つけた場合、これは設計パターンですか?私はそれを使用していますか?

いいえ、それは私の頭の中のデザインパターンではありません。設計パターンには、パターンのレシピを定義するクラスとメソッドの配置がいくつかあります。

私はあなたがそこで行ったことを一般的な慣行として考えたいと思います。ただし、コピーアンドペーストのコーディングには注意してください。

また、開発を開始するとき、あなた(プログラマー)はパターンを探していることに気づきました(どこで見たらいいのでしょうか?)。もしそうなら、これは確かに私が受け入れ始めなければならない習慣です。

同じコードが何度も繰り返し表示されるとき、コードをパターンにリファクタリングする方法を見つけるか、パターンに関連する同様の問題の解決策を覚えている場合は、それを取り出して使用します。 Head First Design Patternsにはいくつかのパターンがありますが、リファクタリングはコーディングプラクティスの提案であり、さまざまなパターンを見つける可能性があります。別の可能な出発点が必要な場合は、Microsoftのパターンと実践をご覧ください


0

パターンの学習は、単に何かを学ぶことではありません。プログラミング言語で何ができるかを学びます。私自身は、パターン(この場合は複合パターン)の仕組みを学ぶことで、オブジェクト指向プログラミングについて多くのことを学びました。

Odedが述べたように、ほとんどのプログラマーはそれを認識せずに使用することがあります。パターンの美しさは、定義済みのパターンを使用して特定の問題を解決できるため、建築的なことを考える必要がなくなることです。


0

既存のプロジェクトで作業を開始すると、パターンを学習します。あなたが学ぶべきパターンは非常に多くあり、あなたが取り組んでいるプロジェクトに依存するため、それらすべてを習得するのは時間の価値がありません。1つに出くわすときはいつでも、それについて学び、それがどのように使用されるかを確認してください。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.