5

MVC アーキテクチャで設計されたプログラムのいくつかの層を調べてみると、より深い層のメソッドが返す結果についてより多くの情報が必要であり、いつこの情報が必要になるかを予測できるとは限らないことがわかりました。そして、抽象化のために、そのメソッドがアプリケーション固有のログに何かを出力したり (そのメソッドは別のプログラムで使用される可能性があります)、または上記の他のレイヤーのように特定のアプリケーションに依存する動作をしたくない場合があります。

たとえば、特定のユーティリティ関数では、アクションを実行する前にいくつかの前提条件チェックが失敗する場合があります。それらのいずれかで false を返すと、呼び出し元は何が起こったのかわかりません。false を返し、何が起こったかをアプリケーション ログに記録すると、その関数がアプリケーション固有の動作にバインドされます。

質問: MyResult という小さなクラスを実装し、応答ステータス (ok/false)、メッセージ、最終的な整数コード、および呼び出し元が可能なオブジェクト プレースホルダー (配列またはオブジェクト) を返すようにすることは、良い/一般的な方法ですか?返されたオブジェクトにアクセスしますか? この MyResult クラスはシステム全体で使用され、すべてのメソッドとその呼び出し元の間で共通の「方言」になります。すべてのメソッドは、常に MyResult のインスタンスを返します。

4

3 に答える 3

2

それが例外です。Javaのようにやりすぎる必要はありませんが、エラーコードがひどいので存在します。

于 2011-06-12T15:27:51.400 に答える
2

例を挙げていただけますか？少しのようですが、静的に使用しているメソッドがあると誤解される可能性があります（実装されていない/呼び出されていない場合でも）。自分自身をペイントできるテーブル オブジェクトの基本的な例は、次のように呼び出されます$myTable->paint();。変数が機能したかどうか (true/false) を返すことができますが、他のもの (ロギングなど) は関数でtable()あり、呼び出し元のメソッドも戻り値も、​​私が知る限り、それとは何の関係もありません。心配している。

これをどのような状況で使用するのかを理解するのに苦労しているかもしれませんが、メッセージ (またはイベントなど) を必要とする何らかの目的でメッセージを送信したい場合は、それらを定義する必要がありますが、何も表示されませんメソッド呼び出しの結果を渡すデフォルトの returnObject を定義するメリット。

エラーの場合、2 つのオプションがあります。例外 (つまり、実際には発生することが予期されておらず、実行を停止する必要があること) とエラー: 予期されたが望ましくない動作です。前者はそのままにしておく必要があり、後者はややこしいかもしれませんが、オブジェクト自体に、何が起こったのかを明確にする状態が含まれている必要があります。

于 2011-06-12T15:31:54.270 に答える
1

フレームワークが必要な特定の機能を提供しない場合、自分で注意を払う以外の方法はありません。特に、フレームワークの目的を超えて実行されるものが必要な場合は、決してそれを実現しないでしょう。

ただし、多くのフレームワークは、それらを拡張できる場所を提供します。他のものより柔軟なものもあります。したがって、可能であれば、必要な機能を、フレームワークの領域内にとどまることができる一種のアドオン、プラグイン、またはヘルパーコードとして実装できるかどうかを検討します。

それが不可能な場合は、やりたいことを何でもすることは常に有効だと思います。自分に役立つフレームワークの部分を使用してください。

于 2011-06-12T15:25:42.983 に答える