技術メモ

エラー追跡の材料

階層化：Exception

try
　　try
　　　　try
　　　　　　try
　　　　　　　　try
　　　　　　　　catch
　　　　　　　　▲1：エラー１
　　　　　　catch
　　　　　　▲2：エラー１
　　　　catch
　　　　▲3：エラー１
　　catch
　　▲4：エラー１
catch
▲5：エラー１

▲5
▲4
▲3
▲2
▲1

ログ出力の考え方
Exceptionの考え方
アーキテクチャの考え方
管理の考え方
DIの考え方

 

※Gallioが有効

1.NUnitの取得
　　以下のURLよりNUnitを取得する
　　http://sourceforge.net/projects/nunit
2.NUnitのライブラリ追加
　　Project選択-｢参照の追加｣｢nunit.framework.dll｣を選択
3.テストコード雛形

　　using System
/
　　using NUnit.Framework
/

　　namespace 名前空間
　　{
　　　　[TestFixture]
　　　　public class MaxDataSizeRecorderTest
　　　　{
　　　　　　[Test]
　　　　　　public void Constructor()
　　　　　　{
　　　　　　}
　　　　}
　　}

4.実行規則
　　属性[TestFixture]：テスト対象クラス
　　属性[Test]：テスト対象メソッド
　　※互換性の為に、｢Test･･･｣で始まるメソッドも
　　　テスト対象になる

5.テストメソッド
　　Assertion･･･テスト用のメソッド

6.例外をチェックする
　　属性[ExpectedException(typeof(例外名))]
　　でチェックを行える

 

　　◇関連～継承の記述方法
　　　　○Interface
　　　　Λ
　　　　￤
　　　　Subclass

　　　　<Interface>
　　　　Λ
　　　　￤
　　　　SubClass

　　　　SuperClass
　　　　Λ
　　　　｜
　　　　SubClass

　　◇クラスの記述方法

　　クラス名
　　───────────────
　　可視性記号 属性(フィールド名)
　　───────────────
　　可視性記号 操作(メソッド)：型

　　可視性記号
　　+ ：public
　　- ：private
　　# ：protected
　　無：ﾊﾟｯｹｰｼﾞｱｸｾｽ
 

1.カプセル化
2.継承
　　既に定義されたクラスの機能を引継ぐ
　　[使用例]
　　クラス間の共通部分を抜き出して、スーパークラス化し、
　　継承する事で機能を集中管理する事ができるようになる
3.多態性[ポリモフィズム]
　　異なるクラス間に共通的な要素を持たせることで
　　オブジェクトの使い手に統一した使用方法を提供する
　　※抽象クラス、インターフェースどちらかを使用
　　[使用例]
　　印刷メソッドがある場合、クラスが増えるたびに
　　印刷メソッドが増えていくと不便
　　クラスに印刷メソッドとのインターフェースを実装させる
　　事で１つの印刷メソッドでそのインターフェースを実装
　　しているクラスなら利用できるようにする

抽象クラスvsインターフェース
　　テンプレートパターンのように･･･
　　共通的な実装とサブクラス間で異なる実装が存在する場合
　　抽象クラスを利用する
　　上記以外で、クラス間で共通の振る舞いを定義したい場合
　　インタフェースを使う

 

◆定数の配置場所
　　プロジェクト内で利用されるリソースは以下の1.～6.の配置場所が考えられる
　　①～③を考えて配置場所/扱い方を考える事
　　①更新頻度
　　②集中度
　　③アクセス度

　　1.ソース内にハードコーディング　　　↑集中[最低] 頻度[低] ｱｸｾｽ度[高]
　　2.ソース内に定数として配置[Local]　 ｜集中[低]　 頻度[低] ｱｸｾｽ度[高]
　　3.ソース内に定数として配置[Grobal]　｜集中[中]　 頻度[低] ｱｸｾｽ度[高]
　　4.リソースとして配置　　　　　　　　｜集中[高]　 頻度[中] ｱｸｾｽ度[高]
　　5.外部ストレージに配置[File]　　　　｜集中[高]　 頻度[高] ｱｸｾｽ度[中]
　　6.外部ストレージに配置[DB]　　　　　↓集中[高]　 頻度[高] ｱｸｾｽ度[低]

　　例）
　　　　内部コード系
　　　　　　更新頻度：低
　　　　　　集中度　：高以外でスコープに合わせた場所とする
　　　　　　ｱｸｾｽ度　：高

　　　　機能ID、メッセージIDの扱い
　　　　　　ある特定のルールで記述され且つ、それ以外の利用で記述される可能性が低いものはシンボル性が高い為、同一名の定数として扱うならば
　　　　　　定数にする必要性はない。なぜなら、同一名にしてしまうと仮にメッセージIDが変わった時に、変数名も変えなければならなくなる
　　　　　　　　例)メッセージID："EX121200"のものを
　　　　　　　　　 public const string MSG_EX121200 = "EX121200";として定数宣言する
　　　　　　一覧性、修正の容易さ、可読性の観点から集中管理がしたいのならば
　　　　　　シンボル性を低くして意味的な定数名を付ける事もありではある
　　　　　　　　例)public const string MSG_INVALID_ERR = "EX121200";
　　　　　　しかし、メッセージIDが膨大に膨れ上がった場合、一つ一つに意味のある定数名を付けていくことができるのかという問題と
　　　　　　そもそも分かりやすい定数名なんてものが意味があるのか？という問題がある
　　　　　　(日本語の定数名で記述できるのならばまだしも、大抵は短文省略英語で記述される。これは可読性に対して英数記号と大して変わらない
　　　　　　 のではないのか？)

　　　　　　メッセージIDの定数化に対する反論
　　　　　　①一覧性
　　　　　　　メッセージIDに正規表現で抜き出せる屹然としたルールが存在するならば、ツールを利用すれば抜き出せるので不要
　　　　　　②修正性
　　　　　　　①と同様に、正規表現で抜き出せさえすれば、置換も一括で行える
　　　　　　　※置換は行えるかもしれないが、本当に正しく置換されたかどうかを検証する必要があるか？