1

配列を処理するユーティリティ関数を作成しています。複雑さを避けるために、関数への省略形の配列挿入を許可する単純なハンドルとしましょう。

function array_insert($original_arr,$key,$val){
    $original_arr[$key]=$val;
    return $original_arr;
}

ユースケースは例えば

validate_input(array_insert($_GET,'extra-key','val'));

$_GETここで、配列ではない可能性がある問題が発生する可能性があるとしましょう。または、外部呼び出しから入力を取得しているとします。最初のパラメーターが配列であることを確認する責任はどこにありますか?

これが処理の複雑なスタックの開始を形成した場合、次のことができます。

if (is_array($our_data)){
    do_something($our_data);
    do_something_else(array_insert($our_data,'key','val'));
}

do_somethingただし、これには、呼び出しスコープにそれが起こらなかったことを知らせる効果はありません。したがって、次のことができます。

if (!is_array($our_data)){
    throw new Exception('not an array');
}

ここで、メソッドを使用するものはすべて、それをキャッチする準備をする必要があります。実際に結果を気にするかどうかによっては、メソッド内でキャッチする必要がある場合があります。

単純にユーティリティ関数から抜け出し、他の何かがチェックできる false を返すことができます:

function array_insert($original_arr,$key,$val){
    if (!is_array($our_data)){
        return []; // which is empty but expected, or return false.. or null...
    }
}

次に、最低レベルがあります。

function array_insert(Array $original_arr)

配列が渡されない場合、PHP レベルの例外がトリガーされます。

問題は次のとおりです。ユーティリティ関数の場合、ユースケースについてどの程度の責任を負いますか? TypeHint で言語例外を発生させますか? 黙って失敗しますか? わざわざチェックしてエンド ユーザーに理解させませんか?

アップデート

まず、人々はこれが主観的なものであることに気づいています。私も同意しますが、確立されたベスト プラクティスが存在する可能性があります。たとえば、認定スキームや PHP の世界の大企業によって推奨されているものなどです。

2 番目の質問 (最初の回答によって促される) は、この種の問題に対して確立された例外クラス/クラス名があるかどうかです。

4

1 に答える 1

1

コメントですでに述べたように、これは完全に主観的ですが、個人的には次のとおりです。

  • オブジェクトと配列には常に型ヒントを使用します。

  • InvalidArgumentExceptionプリミティブ型で動作する関数の場合、一部の値が無効であり、それが明らかでない場合にのみ、値に基づいてスローします。たとえば、数値の平方根を計算する関数は、負の値が渡されると例外をスローする可能性があります。

  • それ以外の場合はすべて、意味のある関数/パラメーター名を使用し、数値以外の文字列または配列を として定義された関数に渡すことが良い考えであると誰かが判断した doStuffWithNumbers($num1, $num2)場合、結果に悪いことが起こった場合、それは彼の責任であると想定します。

于 2014-10-08T11:54:55.760 に答える