バックエンド管理には多くの追加、削除、変更、チェックが必要になります

一般的なデザインパターンは、プログラムの保守性を高めるために使用されており、特にロジックコードが統合されており、後のメンテナンスで元のコードがあまり変更されないように、変更されやすい部分を予防的に処理するように努めています。上記の理解に基づいて、プロジェクトでは多くの追加、削除、変更、検索が必要になるため、削除は簡単になる可能性があり、特別なデザイン パターンが使用される可能性は低いと考えられます。まずは増加から始めましょう:

1. 製品の追加: さまざまなパラメーターを追加してプロンプトを表示するだけです。たとえば、最初は製品名が 1 つしかない場合があります。しかし、その後、神のプロダクトマネージャーは、私たちが行ったプロジェクトはハラールとして十分ではないと言いました。私たちの世界の栽培ユーザーにはさらにニーズがあり、さらにいくつかの詰め物を追加する必要があるかもしれません。顧客が異なる仕様の製品を公開するときに価格を表示するための列を提供したり、顧客が異なる休日中に異なる割引価格を表示しやすくするための列を追加したりするオプションなどです。結局のところ、後でそのようなナンセンスに悩まされたくない場合は、関連する問題に対処するための適切な設計パターンが必要です。ここで提供できるモードの 1 つは中間モードです (モジュール間の結合を可能な限り回避できます。新しい列を追加するには、カプセル化されたモジュールを中間関数に渡すだけでよく、その内部は気にしません)対処方法は、統一されたインターフェイスを提供することだけです)、将来どれだけ多くのパラメーターが追加されても、関連するロジック モジュールを完成させるだけで済みます。

2. まだ製品を追加中: 上記の機能を一定期間使用した後、あなたの製品マネージャーは黄金の万能薬を完成させ、その力を誇示しようとしているかもしれませんが、今回はたまたまあなたがその魔法の罠にかかっただけです。需要は、「さまざまな製品タイプに応じて、対応するパラメータ入力および選択機能を提供すること」です。たとえば、電子製品には詳細なパラメータを入力する必要があるかもしれませんが、ゲーム クーポンには必要ありません。現時点で使用でき、最も一般的に使用されているのは、テンプレート メソッド パターンとも呼ばれる「オブジェクト指向」です。これは、単純に継承と書き換えです。 父親が一人、息子たちが大勢いて、曖昧さはなく、乗るべき人は乗るだろう。このモードは比較的シンプルです。問題は、コードが複雑であるため、少し面倒になる可能性があることです。

3. 製品の変更: 実際、ほとんどの状況は新しい製品の追加と同様であり、特定の特別なニーズを考慮する必要がある場合があります。たとえば、ユーザーは現在製品情報を変更していますが、送信後すぐに変更が反映されることを望まず、将来的には関連情報のリリースをいつでも手動で制御できるようにしたいと考えています。現時点では、情報の公開状態と情報の保存状態を切り替えるための追加のボタンがページに用意されています。これは、2 つの異なる状態でのデータの処理方法を区別するために使用されます。将来的にはリリースが予定されている場合もあります。 。現時点では、さまざまな戦略または状態での動作メソッドを処理するために、戦略パターンまたは状態パターンを使用する必要がある場合があります。

4. 製品を確認する: 最も簡単なのは、ポイント 1 と同様に、さまざまなフィルター (地域、タイプ、価格など) を追加することです。あるいは、既読のデータコンテンツに対して検索を実行する必要があります。たとえば、「不老不死を養いたい」というキーワードに一致する商品が表示され、それ以外は削除されます。異なる列の情報を 1 つずつ照合する必要がある場合があるため、責任連鎖モデルを使用できます。

一般的に、いくつかの一般的な設計パターンをリストしましたが、実際の開発プロセスではさらに多くの問題が発生します。たとえば、次のような問題があります。新しい製品の機能を更新する必要があり、要件はユーザーが追加する前に毎回新しい製品の場合は、ユーザーが以前に同様の製品テンプレートを入力したかどうかを確認するためのテストを実行する必要があります。入力している場合は、それを直接適用するように求められます。そうでない場合は、ユーザーに入力を求めるメッセージは表示されません。 ただし、このモジュールは以前は同僚の担当であり、現時点ではデコレータ パターンを使用して同僚のソース コードを読みたくないため、災害を克服しようとしていると感じているかもしれません。関連するコードを更新します。通常の機能を確保しながら、ソース コードを変更しないようにしてください。 。 。 。 。このような例はたくさんありますが、重要なのは物事を正しく行うことです。プロジェクトを開始する前に、それほど多くのことを考慮する必要があるかどうかについては、考え抜くことができない場合もあるので、必要ないと思います。より明白なものだけを選択してください。これまでたくさん書いてきたようですが、私はより明白な部分の一部にとどまっており、この種のプロジェクトについてはまだ書いていません。具体的にどのような問題が発生するかは推測するだけです。 したがって、パターンの問題に巻き込まれすぎないように、気づいたときにコードをリファクタリングする方が良いかもしれません。