最近、デザインパターンを選択し、同時に1つのプロジェクトを実行のために作り直そうとしました。 このカクテルから、私は一般大衆と共有したいいくつかの考えが生まれました。
例外は私のためだとすぐに言わなければなりません！=エラー。 受信は例外的な状況であり、プログラム実行のメインブランチからの逸脱です。 この場合、実行にのみ関心があります。実行は、プログラムを中断せずに処理するか、プログラムの実行を中断する前に何らかのアクションを必要とします。 コードの特定の部分の実行中に、異なる例外を実行する必要があるが、この例外アクションによって厳密に定義されているいくつかの特別な例外が発生する場合に特に興味があります。
原則として、実行は例外的な状況に関する情報を含む一種のコンテナとして使用します。 コードの一部は例外をスローし、イベントに関する情報をその中に入れます。コードの別の部分は例外をキャッチして処理しようとします。 これは、例外を処理する一般的な方法です。 しかし、誰ができると言ったのでしょうか？
それを理解しましょう。
通常、実行は次のように使用されます。
class a { public function mytest() { try { code_which_throw_exception(); } catch(myExceptionType1 $e) { myException1Catcher(); } catch(myExceptionType2 $e) { myException1Catcher(); } ... } }
しかし、なぜ、私たちの例外は「サイレント」な受動オブジェクトなのでしょうか？ 彼にもう少し自由を与えましょう！ これはオブジェクトであるため、処理ロジックをカプセル化できます。
例外に
catchException()メソッドを追加して、ロジック
myException1Catcher()および
myException2Catcher()それぞれ非表示
myException2Catcher()ます。 このメソッドの場合、たとえば、呼び出しオブジェクトをパラメーターとして渡すことができます。
次に、コードは次のようになります。
class a { public function mytest() { try { code_witch_throw_exception(); } catch(myException $e) { $e->catchException($this); } } }
ご覧のとおり、呼び出し元クラスのコードはわずかに削減されています。 彼は良くなりましたか？ それは状況次第です。
この方法が役立つ場合
システムのある時点で、さまざまなタイプの十分に多数の例外が生成される場合、このメソッドは非常に便利です。
この手法をうまく適用できるもう1つの状況は、受信がコールチェーンを通過し、各段階で何らかのアクションを実行する場合です。 次に、catchブロックでメソッドを呼び出して例外を処理し、再度スローします。
この方法の利点は何ですか？
すべての例外は同じ方法で処理されるため、例外を処理するオブジェクトは正確な型を知る必要はありません。 適切に動作するには、インターフェイスレベルでの互換性で十分です。
受付係は、どの特定のオブジェクトが彼を捕まえたかを知る必要はありません：
$thisへのリンクを受け取った
$this 、彼は捕まえられたオブジェクトのメソッドのシーケンスを呼び出すことができ、したがって、インターフェースレベルでのみ互換性も必要とします。
さらに、例外ハンドラー内で、実行時に追加データを保存して、それとともに移動し、たとえば統計を保持したり、アクションのアルゴリズムを変更したりすることも可能になります。