パターンはビルディングブロックではないので、MVC / MVPパターンでアプリをビルドすべきではありませんか？
私は、デザインパターンについての this ページと、コードを記述するときにそれらをどのように処理するかを読みました。私の理解から、リンクのタイトルは次のように述べています：
パターンはビルディングブロックではありません。
私が正しく理解していれば、意味があるまでデザインパターンを使用しないことを意味しますよね？戦略パターンを使用するつもりだと言って始めないでください。コードを書くまで待ってください。戦略パターンを使用することが設計に意味がある場合は、それを使用してください。
[〜＃〜] mcv [〜＃〜] / [〜＃〜] mvp [〜＃〜] パターンをGUIアプリケーションを作成するときと同じように扱いますか？それぞれのリンクから、それは建築パターンであると述べています。
GUIアプリケーションを作成し、MCV/MVPパターンを使用していなくても、コードがクリーンで、読みやすく、保守可能である場合、MCV/MVPパターンを使用しなかったのは、コードのにおい/悪い設計であると想定します。 ？
私が正しく理解していれば、意味があるまでデザインパターンを使用しないことを意味しますよね？
はい。
戦略パターンを使用するつもりだと言って始めないでください。コードを書くまで待ってください。戦略パターンを使用することが設計に意味がある場合は、それを使用してください。
はい。技術的には、コードを書く前でも戦略パターンが適切であることに気付くかもしれませんが、それは実際の問題について考え、その問題の解決策を設計していたためであるはずです。
GUIアプリケーションを作成するとき、MCV/MVPパターンを同じように扱いますか？それぞれのリンクから、それは建築パターンであると述べています。
はい、MVC/MVP/etcはアーキテクチャパターンです。ある意味で、MVC/MVP/etcを使用する必要があるのは意味がある場合のみなので、違いはありません。あなたが解決しようとしている実際の問題にそれが妥当であるとき。違いがあるのは、たとえばStrategyパターンよりもはるかに高いレベルで適用されるため、通常、それが意味があるかどうかを判断し、それを一部として使用するかどうかを決定することです。多くのコードを記述する前に、設計作業を行います。
また、「MVC/MVP」は単一のパターンではなく、関連するパターンの非常に大規模なファミリーであり、「MVC」、「MVP」、「MVVM」、または残りの部分として正確に何がカウントされるかについてコンセンサスはありません。関連するアルファベットのスープ。
GUIアプリケーションを作成し、MCV/MVPパターンを使用していなくても、コードがクリーンで、読みやすく、保守可能である場合、MCV/MVPパターンを使用しなかったのは、コードのにおい/悪い設計であると想定します。 ？
MVC/MVP/etcがすべてのGUIアプリケーションに適しているわけではないため、まったくありません。たとえば、一部のGUIは単純すぎて完全にやり過ぎる可能性があります。また、一部のGUIは「モデル」に入れる永続的な状態を持たない場合もあります。そのようなパターンのファミリーが非常に人気があるのには理由がありますが、優れたGUIソフトウェアを作成する唯一の方法ではありません。
また、「コードのにおい」は通常、より大きな問題の症状である可能性がある特定のコードスニペットについての何かを意味します。すべてのコードが「クリーンで読み取り可能で保守可能」であり、例外がなければ、ほとんどの場合、コードの臭いはありません（ただし、実際の問題を示さないいくつかの「誤検知」コードの臭いは除きます）。 ）。
つまり、「MVC/MVPパターンをどのように扱うか？」という質問のタイトルに答えるには、次のように言います：whyについて読んでくださいこれらのパターンは非常に人気があります。解決して、将来、最新の問題がそれらのパターンによって解決されるかどうかを判断できるようにします。