デザインパターンの現実世界への浸透度は?日常の仕事でそれらを使用しますか?同僚とどのように、どこに適用するかについて話し合いますか?それとも、よりアカデミックな概念のままですか?
彼らは実際にあなたの仕事に実際の価値を提供していますか? それとも、スマートに聞こえるように人々が話しているだけですか?
注: この質問では、Singletonのような「単純な」設計パターンは無視してください。Model View Controllerなどを利用できるようにコードを設計することについて話している.
デザインパターンの現実世界への浸透度は?日常の仕事でそれらを使用しますか?同僚とどのように、どこに適用するかについて話し合いますか?それとも、よりアカデミックな概念のままですか?
彼らは実際にあなたの仕事に実際の価値を提供していますか? それとも、スマートに聞こえるように人々が話しているだけですか?
注: この質問では、Singletonのような「単純な」設計パターンは無視してください。Model View Controllerなどを利用できるようにコードを設計することについて話している.
適切に作成された大規模なプログラムは、たとえ名前が付けられていなかったり、そのように認識されていなくても、デザイン パターンを使用します。それがデザインパターンであり、繰り返し自然に発生するデザインです。Facade
醜い API とやり取りしている場合は、それをクリーンアップするために を実装していることに気付くでしょう。分離する必要があるコンポーネント間のメッセージングがある場合は、Observer
. 交換可能なアルゴリズムがいくつかある場合は、最終的にStrategy
.
設計パターンを認識し、より迅速にクリーンなソリューションに収束する可能性が高くなるため、設計パターンを知っておくことは価値があります。ただし、それらをまったく知らなくても、最終的にはそれらを作成することになります (まともなプログラマーであれば)。
そしてもちろん、最新の言語を使用している場合、それらは標準ライブラリに組み込まれているため、おそらくいくつかの目的でそれらを使用することを余儀なくされるでしょう.
私の意見では、 「デザイン パターンを使用しますか?」という質問だけでは、答えは普遍的に YES であるため、少し問題があります。
説明させてください、私たちプログラマーとデザイナーは皆、デザインパターンを使用しています... 私たちは常にそれを認識しているわけではありません. 決まり文句に聞こえるかもしれませんが、パターンに行くのではなく、パターンが思い浮かびます。既存のパターンのように見えるものを設計し、そのような名前を付けて、誰もが話していることを理解し、設計上の決定の背後にある論理的根拠がより強力になるようにします。
私は個人的にコミュニケーションツールとしてパターンを使用しています。それでおしまい。それらは設計ソリューションではなく、ベスト プラクティスでもなく、ツールボックスのツールでもありません。
誤解しないでほしいのですが、あなたが初心者であれば、パターンに関する本を読めば、別の欠陥のある設計ではなく、そのパターンを「使用して」ソリューションを解決する最善の方法が示されます。あなたはおそらく演習から学ぶでしょう。ただし、これは、すべての状況を解決するために対応するパターンが必要であるという意味ではないことを認識しておく必要があります。すべての状況には、あちこちに癖があり、代替案を考え、完璧な答えがない難しい決断を下さなければなりません。それがデザインです。
ただし、アンチパターンはまったく別のクラスにあります。実際には、アンチパターンを積極的に回避したいと考えています。そのため、アンチパターンという名前は非常に物議を醸しています。
「デザインパターンを使用しますか?」という最初の質問に戻ると、はい!
「私は積極的にデザインパターンに傾倒していますか?」、No.
はい。デザイン パターンは、適切に使用すると素晴らしいものになります。おっしゃったように、私は現在、すべての Web プロジェクトで Model-View-Controller (MVC) を使用しています。これは、Web スペースでは非常に一般的なパターンであり、サーバー側のコードをよりクリーンで整然としたものにします。
それ以外にも、役立つ可能性のある他のパターンを次に示します。
MVVM (Model-View-ViewModel): MVC と同様のパターン。WPF および Silverlight アプリケーションに使用されます。
構成: オブジェクトの階層を使用する必要がある場合に最適です。
シングルトン: 本当に単一のインスタンスを必要とするアイテムを格納するために、グローバルを使用するよりもエレガントです。おっしゃる通り、シンプルなパターンですが用途はあります。
設計パターンは、言語機能の欠如や言語の欠陥を強調することもできることに注意してください。たとえば、イテレータは新しい言語の一部として組み込まれています。
一般に、デザイン パターンは非常に便利ですが、どこでも使用するべきではありません。それらがあなたのニーズにぴったり合っているところだけです。
そうしようと思います。それらは確かに、コードの保守性と可読性に役立ちます。ただし、システムを存在しないパターンに強制することによって、通常は (私が見た限りでは) それらを悪用する人がいます。
該当する場合は、パターンを使用しようとします。開発者がそのためだけにコードにデザイン パターンを実装するのを見るのは、ちょっと悲しいことだと思います。ただし、適切なタスクに関しては、デザイン パターンは非常に便利で強力な場合があります。
「現実世界」で使われるデザインパターンは、単純なものだけではありません。良い例 Stackoverflow はモデル ビュー コントローラー パターンを使用します。私は雇用主のプロジェクトでクラス ファクトリを何度も使用しており、クラス ファクトリを使用して既に書かれたプロジェクトも数多く見てきました。
すべてのデザイン パターンが使用されているとは言いませんが、多くのデザイン パターンが使用されています。
はい、そうです。通常、何かをデザインし始めたときに、誰かがそれが既存のパターンに似ていることに気付いたときに発生します。次に、それを見て、それが目標の達成にどのように役立つかを確認します。
文書化されていないが、多くの設計から生まれたパターンも使用します。
注意してください、私たちはそれらをあまり使用しません。
はい、Factory、Chain of Responsibility、Command、Proxy、Visitor、Observer などは、私が毎日使用しているコードベースで使用されています。MVCに関する限り、このサイトはそれを非常にうまく使用しているようで、開発者は最新のポッドキャストで十分なことを言うことができませんでした.
はい。
私は現在の仕事でそれらを使用しています:COBOLとPL/Iを使用したメインフレームコーディング。
これまで、アダプター、ビジター、ファサード、モジュール、オブザーバー、およびコンポジットとイテレーターに非常に近いものを見てきました。言語の性質上、使用されるのは主に構造パターンです。また、それらを使用する人々がそう意識的にそうすることを常に確信しているわけではありません:D
はい、デザイン パターンまたは抽象的なパターンは私の人生の一部です。したがって、私は彼らに囲まれています。しかし、ご存知のように、知識が少ないことは危険なことです。したがって、GoF の本を読むことを強くお勧めします。
デザイン パターンに関する主な問題の 1 つは、ほとんどの開発者がそのアイデアを理解していないか、信じていないことです。そしてほとんどの場合、彼らは変数、ループ、またはスイッチについて議論します。しかし、パターン言語を話さないと、ソフトウェアはうまく機能せず、メンテナンスの悪夢に陥ることになると私は強く信じています。
ご存知のように、アンチパターンも危険なものであり、設計パターンに関する専門知識がほとんどない場合に発生します。また、アンチパターンのリファクタリングははるかに困難です。この問題に関する推奨本として、「AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis」をお読みください。
はい、私は多くのよく知られたデザイン パターンを使用していますが、後で「名前付き」デザイン パターンを使用していることが判明したソフトウェアを構築することもあります。最もエレガントで再利用可能なデザインは「パターン」と呼ぶことができます。ダンスの動きによく似ています。私たちは皆、ワルツと 2 ステップを知っていますが、ほとんどの人がやっているにもかかわらず、誰もが「バンプ アンド スクート」の名前を持っているわけではありません。
MVC は非常によく知られているため、デザイン パターンをかなり多く使用しています。Gang of Four パターンについてお尋ねの場合は、私が使用するいくつかのパターンがあります。なぜなら、他のメンテナーは設計と、コードで何を目指しているかを知っているからです。しかし、私たちが何をしているのかはっきりしないものもいくつかあります。
それらは重要ですか、そうです。それは、ソフトウェア設計について、迅速で効率的かつ一般的に受け入れられている方法で話す方法を提供するからです。より良いカスタム ソリューションを作成できますか?
元の GoF パターンは製品コードから引き出されたため、実際に使用されているものをカタログ化しました。それらは純粋に、またはほとんど学術的なものではありません。
MVC パターンは、モデル ロジックを分離するのに非常に役立ちます。モデル ロジックは、あまり問題なく再利用したり作業したりできます。また、クラスを分離し、単体テストを容易にするのにも役立ちます。私は最近それについて書きました(はい、ここで恥知らずなプラグイン...)
また、最近、基本クラスのファクトリ パターンを使用して、 LINQを使用して、その場で必要な適切な DataContext クラスを生成して返しました。
ブリッジは、2 つの異なるテクノロジを結合しようとするときに使用されます (たとえば、Mac 上のCocoa と Rubyなど)。
ただし、パターンを実装するときはいつでも、それは事前に知っていたからです。必要に応じて元のパターンをわずかに変更する必要があることがわかったので、通常、いくつかの追加の考慮が必要になります。
建築宇宙飛行士にならないように気をつけて!
はい、デザイン パターンは主に現実の世界で使用されており、私が一緒に仕事をしている多くの人々によって日常的に使用されています。
私の意見では、デザイン パターンが提供する最大の価値は、ソフトウェア デザインを他のプログラマーに伝えるための、普遍的で高水準の言語を提供することです。
たとえば、新しいクラスを「入力条件の組み合わせに基づいて他のいくつかのクラスの 1 つを作成するユーティリティ」と説明する代わりに、単に「抽象ファクトリ」であり、誰もがあなたが話していることをすぐに理解できると言うことができます。
私は絶対にデザインパターンを使用しています。この時点で、私はMVCをデザインパターンとして当然のことと考えています。それらを使用する私の主な理由は、私が特定の問題に遭遇した最初の人ではない可能性があることを知っているのに十分謙虚であるということです。どのパターンを使用するかを知っているコードを開始することはめったにありません。私は常にコードを監視して、コードが自然に既存のパターンに発展するかどうかを確認します。
また、 MartinFowler のエンタープライズアプリケーションアーキテクチャのパターンも非常に気に入っています。問題やタスクが発生した場合は、関連するセクション(ほとんどは参考書)に戻って、パターンの概要をいくつか読みます。一般的な問題と既存の解決策についてよりよく理解すると、自分のコードが他の人の経験を介してたどる可能性のある長期的な道筋が見え始めます。私ははるかに良い決定をすることになります。
デザインパターンは、私の「未来のための」アイデアすべてにおいて間違いなく大きな役割を果たしています。