2

次のようなクラスがあるとします。

class Foo{
    public function bar($p,$p2=null,$p3=null){
        //...
    }
}

場合によっては、1 番目と 3 番目のパラメーターだけを渡して呼び出す必要があります。問題は、3番目に到達するために、2番目のパラメータを渡して何かを渡す必要があることです。

オプションのパラメーターのプライベート プロパティとセッター メソッドを作成し、それらをメソッド シグネチャから削除できます。

これは良い習慣ですか？それとも代わりに使うほうがいいです__callか？func_get_args

SOで読んだソース：

とマニュアルで：

4

2 に答える 2

2

オプションのパラメーターのプライベート プロパティとセッター メソッドを作成し、それらをメソッド シグネチャから削除できます。

邪魔にならないようにすることが理由である場合、これを行うのは非常に悪い考えです。

パラメータとプロパティは、クラスの設計を構成する決定であるため、(他の設計上の決定と同様に) 全体像を見てから、一方を他方に交換する必要があります。1 つの特定のメソッドの 1 つの特定の呼び出しサイトがどのように読み取られるかが気に入らないため、この種の変更は行わないでください。

パラメータが代わりにプロパティであることが理にかなっているのかどうかはわかりません。この場合のオプションは何ですか？

オプション #1: リファクタリング

  • このメソッドに 2 つの省略可能なパラメーターを指定することは理にかなっていますか?
  • 通常、呼び出すときにどちらか (または両方) を省略しますか?

これらの質問に対する答えが「はい」の場合、メソッドが引数に応じて異なるモードで動作することを示している可能性があります。この場合、モーダル動作を、シグニチャを簡素化した個別のメソッドに分割することは理にかなっています。

オプション #2: プロパティのバンドル

  • このメソッドには、適切なデフォルトを持つ多くのパラメーターがありますか?
  • 通常、通常の通話では、これらのうちのいくつか (またはまったく提供しない) しか提供しませんか?

これらの質問に対する答えが「はい」の場合、メソッドに配列を最後の引数として受け入れさせ、それを「その他のオプション」のコンテナーとして使用させることができます。

このアプローチには (大きな!) 欠点があり、これらのオプションがメソッド シグネチャを介して通知されなくなりますが、90% の時間は触れないという賢明なデフォルトがあれば、それは理にかなっています。

オプション #3: 流暢なインターフェース

指定できるオプションがたくさんある場合、流暢なインターフェイスを作成することは理にかなっていますが、これは大きな変更であり、追加の引数がない限り (たとえば、構成可能性が必要な場合)、行うべきではありません。流暢なインターフェイスは、引数をプロパティに変換するより優れた設計バージョンと見なすことができます。

流暢なインターフェイスを記述するには、関数呼び出しに入る可能性のあるすべての引数をカプセル化する新しいクラスが必要です。クラスには、引数ごとに 1 つのメソッドと、これらの引数を使用して作業を行う 1 つ以上のメソッドがあります。流暢なインターフェイス呼び出しサイトは次のようになります

$foo->bar()->color('red')->type('widget')->execute();

ここで$foo->bar()は、カプセル化クラスのインスタンスを返します。これは、colorプロパティを設定し、これらのプロパティを読み取り、実際の作業を実行するtypeそのクラスのメソッドです。execute

于 2013-10-01T10:19:29.217 に答える
1

または を使用して、どの引数が 2 番目または 3 番目であるかをどのように定義できますfunct_get_argsかcall? タイプが異なる場合にのみ可能です。

私の意見では、オプションの可能性がある多くの引数を強力に操作したい場合は、バンドル オブジェクト (汎用または関数固有) のようなコンテナーを使用するか、より使いやすい連想配列を使用します。

于 2013-10-01T10:01:32.173 に答える