パラメータ設計の問題

プログラマーはコードを書けないこともありますが、より良く、拡張しやすく、美しいコードをどのように書くかに常に苦労していることがわかりました。結局のところ、プログラマーは金のような言葉を大切にしています。 、入力の少ない行は行、簡潔な行は

経験を積んできたので、ますます心配する必要はなくなりましたが、今日はパラメータという古い問題に戻りました。メソッドのテーブルは 1 つずつ設計されています。それとも、キー名を使用して配列として表現する方が良いでしょうか?しかし、その後要件が変更され、BC が削除され、F が追加され、プロジェクト全体がコードの変更を探し続けましたが、何かを見逃してしまうのではないかという不安が残りました。そうすれば、古いコードで渡されるパラメータが減り、より多くのパラメータが渡されることになります。 JS では、パラメータ、特に一部の UI プラグインを初期化するときに指定されたオプションを渡すために、キーと値のペア (連想配列だと思われます) を使用することがますます一般的になっていることがわかりました。もちろん、パラメーターが多すぎるため、キーと値のペアを使用する場合は、どのパラメーター ビットがどれであるかを覚えるのが難しくなります。キーと属性を制御する必要があるだけです。オプションの制御用のキーだけである程度は十分ですが、この設計はオプションのパラメータ用であり、PHP では時々このような設計が見られますが、実際にはメソッド呼び出しの方が面倒なようで、
addUserIcon の直接的な表現ではありません。 (ユーザー ID, 金貨の数);
それは常に addUserIcon(array('uid' => ユーザー ID, 'qty' => 金貨の数)) のようなものです

それについて話しましょう、上記はただのことです簡単な例ですが、複雑です 配列の方が扱いやすいようで、あれとこれが矛盾してしまい、開発プロセスがコードの不整合の問題に巻き込まれます、こっちはこう、こっちはああもちろん、怒っているのはあなただけです。上司はあなただけを望んでいます。 Web開発はそれほど複雑である必要はないため)、ただし、phpが提供するデフォルトのパラメータは変更可能です
したがって、渡される実際の数値を確認することでプロセスの方向を決定できます

ただし、パラメータを変更することはお勧めできませんABCDE から ADEF への変換は、もともと ABCDE によって呼び出される部分があいまいになるためです

ただし、php はオーバーロードをサポートしていません (Web 開発はそれほど複雑である必要がないため)。回避策はデフォルトのパラメータです

ただし、パラメータを ABCDE から ADEF に変更することはお勧めできません
ABCDE によって最初に呼び出された部分は曖昧です

つまり、例えば、本来はユーザーの年齢、性別、地域、XX、YY... が必要ですが、ある日プロジェクトの要件が変更され、性別と地域は必須ではないと言われ、その後、署名...
メソッドが setUserInfo であると仮定します

データ収集の要素は関与しません
たとえば、ユーザー情報は｛ユーザーID、年齢、性別、地域など｝の集合であり、ユーザーIDは一意であることができます ユーザーを識別します
別の例は、｛年齢、性別、地域など｝です。 region} はフィルター セットであり、{age, Signature} は別のフィルター セット
したがって、必要なフィルター セット番号を渡すだけで、プログラムをユニバーサル
にし、維持することができます。 これらのコレクションのテクノロジーは次のとおりです: データ ディクショナリ