- PR -

C# 引数やローカル変数の名前を取得する方法は？

«前のページへ 1|2|3
投稿者投稿内容
ugaya
会議室デビュー日: 2006/08/03
投稿数: 18
投稿日時: 2008-03-03 12:55
申し訳ありません。元文献を示しておくべきでした。
追記します。
私が学習したのは以下の文献です。


.NETエンタープライズWebアプリケーション 開発技術大全vol2〜vol5
(@itの記事に一部抜粋があります。)
http://www.atmarkit.co.jp/fdotnet/entwebapp/index/index.html

vol1は.netの概要なので実務にはあまり役にたたないと思います。

.netの(特にasp.net)の仕組みから、各機能の使い分け・設計例・設計ポリシー・ソリューションの開発現場での運用方法まで広くカバーされてる良本です。

あくまでも私の経験限りですが、.net系の開発現場ではよく見かけます。
一読をおすすめします。

たとえば入力値の検査の扱いについて例外処理の項では以下のように明記されています。

引用:

例えば入力データのフォーマットエラーなどは業務フローの分岐ルートとして想定する必要はない。入力データのフォーマットチェックはフロントエンドUI部で済ませているべきものである。


そしてこうも書いてあります。

引用:

CLRでは正常終了や業務エラーを表現するために例外を使ってはならない、というデザインルールがある。


(両引用ともvol3.250pです)

Pattern & Practiceに書かれていることやMSDNのガイドラインで示されている各個の設計パターンはあまりにも多くの場合を想定しすぎていて、実際の業務で応用できるまで精通するのはなかなか難しいという印象を受けています。
(Pattern & Practiceのほとんどが日本語されていないせいで私がわからないだけ?ww)

この本に書いてあることは業務アプリケーションに特化しています。書かれていることが業務アプリケーションの開発現場での銀の弾丸ではないとは思っていますが、一つの精査された設計例として非常に参考になるかと思います。

.NET2.0用に1.1からの変更部分と主要な部分を抜粋したものもあります。

Microsoft Visual Studio 2005によるWebアプリケーション構築技法
http://www.atmarkit.co.jp/fdotnet/bookpreview/vs2005webapp_index/vs2005webapp.html
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2008-03-03 22:16
引用:

ykSiRさんの書き込み (2008-03-02 09:39) より:
今回の"param1"はメッセージではありません。
例外の原因となったパラメータの名前です。
http://msdn2.microsoft.com/ja-jp/library/dsyf5bb2(VS.80).aspx

ですね。パラメータ名を示す必要がありますね。済みません。ご指摘ありがとうございます。


引用:

ひろしさんの書き込み (2008-03-02 20:37) より:
「検査メソッドを用意して...」という言葉の意味は、
「検査ロジックをメソッドに含めるのではなくて、検査メソッドとしてメソッド
から分離した上で、メソッドを呼び出す前に、呼び出し側で検査メソッドによる
検査を済ませ、メソッドには常時検査済みの引数が与えられるようにしなさい。」
という理解で正しいでしょうか？

　私は、次のようなコードを書くようにしています。これは、賛否両論あり、過去にも数回議論されていることです。
コード:
Class ExpampleClass {
    public bool ValidateParameter1(object param) {
        // parameter1 は、適切な名前にする
        // object も、適切な型にする
        // 適切かどうかを判別し、true/false を返す。
    }
    public void DoSomething(object param) {
        if (ValidateParameter1(param) == false) {
            throw new ArgumentException("ちゃんとチェックしてよ！");
        }
        // 処理
    }
}

　開発者には ValidateParameter1 を使って、あらかじめ検査してもらいます。その上で、防衛線を引きます。ValidateParameter1 が false を返したときにどのようにメッセージを見せるかは、開発者が決めます。DoSomething で表示されるであろう「ちゃんとチェックしてよ！」は、エンド ユーザには見せてはいけないメッセージです。このメッセージが出ることは、テスト フェーズでつぶさなければなりません。

　例えば、ユーザによる複数の入力によって何らかの処理をする場合、1つの入力値だけを検査してもエラーになるかわからない場合があります。そのような処理の場合は、例外以外の方法で、上位メソッドにエラーを伝えます。このとき、実際の処理からは例外として通知を受けることはします（例外を業務エラーに読み替える）。反対に、業務エラーを例外に読み替えることも、場合によってはあるかもしれません。

　今回、例に挙げられたようなケースでは、私なら、例外メッセージの内容を頓着しません。それは、開発者にのみわかればいいことです。
　もっとも、indigo-xさんのご指摘で、私の考えが浅かったことに気がつきましたが、他所の開発者に提供するメッセージであれば、頓着します。この場合の「開発者」は、「お客様」でもあるので。
«前のページへ 1|2|3

スキルアップ／キャリアアップ（JOB@IT）