私が正しく理解していれば、これは意味があるまでデザインパターンを使用しないことを意味しますよね?
はい。
戦略パターンを使用するつもりだと言って始めないでください。コードを書くまで待ってください。戦略パターンを使用することが設計に意味がある場合は、それを使用してください。
はい。技術的には、コードを書く前でも戦略パターンが適切であることに気付くかもしれませんが、それは実際の問題について考え、その問題の解決策を設計していたためであるはずです。
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パターンをどのように扱うか?」という質問のタイトルに答えるには、次のようにします。それらのパターンが非常に人気がある理由、つまり、彼らが解決しようとしている問題を読んでください。これらのパターンによって、最新の問題が解決されるかどうかを確認できます。