デザインパターンを使用していますか？

https://stackoverflow.com/questions/11586

08-06-2019
|

質問

現実世界におけるデザインパターンの浸透度はどの程度でしょうか?あなたはそれらを日常の仕事で使用していますか?同僚とそれらをどこにどのように適用するかを話し合っていますか?それとも、どちらかというと学術的な概念のままですか?

それらは実際にあなたの仕事に実際の価値をもたらしますか?それとも、それらは人々が賢く思わせるために話しているだけなのでしょうか？

注記：この質問の目的では、次のような「単純な」設計パターンは無視してください。 シングルトン. 。を活用できるようにコードを設計することについて話しているのです。 モデルビューコントローラー, 、など。

解決

適切に作成された大規模なプログラムは、たとえ名前が付けられていなかったり、そのように認識されていなくても、デザインパターンを使用します。それがデザインパターン、つまり繰り返し行われるデザインです。当然起こる。醜い API を操作している場合は、おそらく次のようなものを実装していることに気づくでしょう。 Facade それをきれいにするために。コンポーネント間のメッセージングを分離する必要がある場合は、次のように使用することになるかもしれません。 Observer. 。交換可能なアルゴリズムがいくつかある場合は、最終的に次のものを使用することになるかもしれません。 Strategy.

設計パターンを認識し、より迅速に適切なソリューションに収束する可能性が高くなるため、設計パターンを知っておく価値があります。ただし、まったく知らなくても、最終的には作成することになります (まともなプログラマであれば)。

そしてもちろん、最新の言語を使用している場合は、標準ライブラリに組み込まれているため、おそらくいくつかの目的でそれらを使用することを余儀なくされるでしょう。

他のヒント

私の意見では、次のような質問があります。"あなたは使用デザインパターンは?」という質問だけでは、答えは普遍的に YES であるため、少し欠陥があります。

説明しましょう、私たちプログラマーもデザイナーもデザインパターンを使用します...私たちはいつもそれに気づいていないだけです。ありきたりな言い方に聞こえるかもしれませんが、パターンに従うのではなく、パターンがやってくるのです。あなたが何かをデザインすると、それは既存のパターンのように見えるかもしれませんが、そのように名前を付けると、誰もがあなたが話していることを理解し、それが議論されたことを知っているので、あなたのデザイン決定の背後にある理論的根拠がより強力になります。 吐き気がする 前に。

私は個人的にコミュニケーションツールとしてパターンを使用しています。それでおしまい。これらは設計ソリューションではなく、ベストプラクティスでも、ツールボックス内のツールでもありません。

誤解しないでください。あなたが初心者であれば、パターンに関する本を読めば、別の欠陥のあるデザインではなく、そのパターンを「使用して」解決策を最もよく解決する方法が示されます。おそらく演習から学ぶでしょう。ただし、これは、すべての状況を解決するために対応するパターンが必要であるという意味ではないことに注意する必要があります。あらゆる状況には随所に癖があり、代替案を考え、完璧な答えがない難しい決断を下さなければなりません。 それは デザイン。

ただし、アンチパターンはまったく異なるクラスにあります。実はあなたは 欲しい に 積極的に アンチパターンを避けます。アンチパターンという名前が物議を醸しているのはこのためです。

元の質問に戻るには:
「デザインパターンを使うの？」、はい！
「私は積極的にデザインパターンに傾いていますか?」、いいえ。

はい。デザインパターンは、適切に使用すると素晴らしいものになります。おっしゃるとおり、私は現在、すべての Web プロジェクトで Model-View-Controller (MVC) を使用しています。これは Web スペースで非常に一般的なパターンであり、サーバー側のコードがよりクリーンでよく整理されます。

さらに、役立つ可能性のある他のパターンをいくつか示します。

MVVM (モデル-ビュー-ビューモデル):MVC と同様のパターン。WPF および Silverlight アプリケーションに使用されます。
構成：オブジェクトの階層を使用する必要がある場合に最適です。
シングルトン:本当に単一のインスタンスを必要とする項目を格納する場合、グローバルを使用するよりもエレガントです。先ほども述べたように、単純なパターンですが、用途はあります。

デザインパターンによって、言語機能の欠如や言語の欠陥が浮き彫りになる可能性があることは注目に値します。たとえば、イテレータは新しい言語の一部として組み込まれるようになりました。

一般に、デザインパターンは非常に便利ですが、どこにでも使用するべきではありません。ちょうどあなたのニーズに適した場所にあります。

はい、そうしようと思います。これらは、コードの保守性と読みやすさに確かに役立ちます。ただし、通常 (私が見た限りでは) 存在しないパターンにシステムを強制することで、システムを悪用する人がいます。

パターンが適用できる場合は、それを使用するようにしています。開発者が目的のためだけにデザインパターンをコードに実装しているのを見るのは、ちょっと悲しいことだと思います。ただし、適切なタスクを行う場合、デザインパターンは非常に便利で強力です。

単純なデザインを超えて、「現実世界」で使用されるデザインパターンは数多くあります。良い例として、Stackoverflow ではモデルビューコントローラーパターンが使用されています。私は雇用主のプロジェクトでクラスファクトリを何度も使用しており、すでに作成された多くのプロジェクトでもクラスファクトリを使用しているのを見てきました。

すべてのデザインパターンが使用されているとは言いませんが、多くのデザインパターンが使用されています。

そうです、それは通常、私たちが何かをデザインし始めたときに、誰かがそれが既存のパターンに似ていることに気づいたときに起こります。次に、それを見て、目標の達成にどのように役立つかを検討します。

また、文書化されていないものの、多くのデザインから浮かび上がってくるパターンも使用します。

言っておきますが、私たちはそれらをあまり使いません。

はい、ファクトリ、責任連鎖、コマンド、プロキシ、ビジター、オブザーバーなどが、私が毎日作業するコードベースで使用されています。MVC に関する限り、このサイトはそれを非常にうまく活用しているようで、開発者は MVC で十分に良いことを言うことができませんでした。最新のポッドキャスト.

はい、よく知られているデザインパターンを多く使用していますが、後で「名前付き」デザインパターンを使用していることが判明するソフトウェアを構築することもあります。最もエレガントで再利用可能なデザインは「パターン」と呼ぶことができます。それはダンスの動きによく似ています。ワルツやツーステップは誰もが知っていますが、「バンプ・アンド・スクート」はほとんどの人がやっていても、誰もがその名前を知っているわけではありません。

MVC は非常によく知られているため、デザインパターンをよく使用します。ここで、Gang of Four パターンについての質問であれば、他のメンテナーがデザインとコードで何を目指しているかを知っているため、私が使用しているパターンがいくつかあります。ただし、私たちが何をしているのかかなり不明瞭な部分がいくつかあるため、それらを使用すると、パターンを使用する利点を最大限に活用できなくなります。

それらは重要ですか、はい、それはソフトウェア設計について素早く効率的で一般的に受け入れられている方法を提供するからです。より良いカスタムソリューションを作成できますか?

オリジナルの GoF パターンは製品コードから抽出されたものであるため、実際にすでに使用されているものをカタログ化しました。それらは純粋に、あるいはほとんどが学術的なものではありません。

MVC パターンはモデルロジックを分離するのに非常に便利で、それほど問題なく再利用したり作業したりできると思います。また、クラスの分離にも役立ち、単体テストが容易になります。それについて書きました最近 (はい、恥知らずなプラグです...)

また、私は最近、基本クラスのファクトリパターンを使用して、必要な適切な DataContext クラスをその場で生成して返しました。リンク.

ブリッジは、2 つの異なるテクノロジーを結合しようとするときに使用されます (たとえば、ココアとルビーたとえばMacの場合)

しかし、パターンを実装するときは常に、それは事前に知っていたからであることがわかります。ニーズに合わせて元のパターンを少し変更する必要があることがわかったので、通常はさらに考えます。

にならないように注意する必要があるだけです建築宇宙飛行士!

はい、デザインパターンは主に現実世界で使用されており、私が一緒に仕事をしている多くの人々によって日常的に使用されています。

私の考えでは、デザインパターンによってもたらされる最大の価値は、ソフトウェアのデザインを他のプログラマに伝えるための普遍的な高水準言語を提供することです。

たとえば、新しいクラスを「入力基準の組み合わせに基づいて他のいくつかのクラスの 1 つを作成するユーティリティ」と記述する代わりに、単に「 「抽象工場」 そして誰もがあなたが何を言っているのかすぐに理解します。

そう、デザインパターンや抽象的なパターンは私の人生の一部であり、どこを見てもそれらが見え始めます。したがって、私は彼らに囲まれています。しかし、ご存知のとおり、知識が少ないのは危険です。したがって、GoF の本を読むことを強くお勧めします。

デザインパターンに関する主な問題の 1 つは、ほとんどの開発者がアイデアを理解していないか、アイデアを信じていないことです。そしてほとんどの場合、彼らは変数、ループ、またはスイッチについて議論します。しかし、パターンランゲージを話せなければ、ソフトウェアはうまく機能せず、メンテナンスの悪夢に陥ることになると私は強く信じています。

ご存知のとおり、アンチパターンは危険なものでもあり、デザインパターンに関する専門知識がほとんどない場合に発生します。そして、アンチパターンのリファクタリングはさらに困難です。この問題に関する推奨書籍として、「AntiPatterns:危機に瀕したソフトウェア、アーキテクチャ、プロジェクトのリファクタリング」。

はい。

現在の仕事でもそれらを使用しています。COBOL および PL/I を使用したメインフレームコーディング。

これまでのところ、アダプター、ビジター、ファサード、モジュール、オブザーバー、およびコンポジットとイテレーターに非常に近いものを見てきました。言語の性質上、主に構造パターンが使用されます。また、それを使用する人が意識的にそうしているかどうかは必ずしもわかりません:D

デザインパターンは絶対に使います。現時点では、MVC をデザインパターンとして当然のこととして考えています。私がこれらを使用する主な理由は、特定の問題に遭遇するのは私が最初ではない可能性が高いことを知っている謙虚な気持ちのためです。どのパターンを使用するかを知ってコードを開始することはほとんどありません。私は常にコードを監視して、既存のパターンに自然に発展するかどうかを確認します。

私もとても気に入っていますマーティン・ファウラーのエンタープライズアプリケーションアーキテクチャのパターン. 。問題やタスクが現れたら、関連するセクション (ほとんどが参考書です) を開き、パターンの概要をいくつか読みます。一般的な問題と既存の解決策についてよりよく理解すると、他の人の経験を通じて、私のコードがたどるであろう長期的な道筋が見え始めます。最終的にはより良い決断を下せるようになります。

デザインパターンは、私の「未来に向けて」のアイデアすべてにおいて、間違いなく大きな役割を果たしています。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow