Moonmile Solutions Blog

いつまでも危ない（？）PDFを晒しておくわけには行かないのでｗ、小ネタでブログを進めます。

時々(特にVBプログラマの方？)では、文字列へのキャストを ToString で行っている箇所を見掛けるのですが、これは危ういです、という話ですね。

例えば、データベースから読み込みをした時に VB だと、こういう風に書いているのです。

Dim da as new SqlDataAdapter("SELECT * ...", cn )
Dim dt as new DataTable
da.Fill(dt)
' 文字列を取り出す
dim name as String = ""
if dt.Rows.Count > 0 then
  name = dt.Rows(0)("name").ToString()
end if

こんな風に、ToString メソッドを使って object 型を文字列に変換しています。
ただし、本来はここはキャストを使うべきです。後述しますが、キャストと ToString メソッドの【意味】が異なるので、必ずしも同じ動作をするとは限らないのためです。

dim name as string = CType( dt.Rows(0)("name"), String )

C# の場合は、

string name = (string)dt.Rows[0]["name"];

# 詳細に言えば、dynamic cast を使うんでしょうが、ここでは普通のキャストで。

さて、ToString でも用途は足りるので、これでも良いような気がしますが、何故キャストを使わないといけないかというと、以下の理由があります。

dim name As String = obj.ToString()

とした時に、name には必ず期待する【文字列】が入るかというと、実は異なるのです。これは、ListBox を扱うと分かるのですが、ToString メソッドはオーバーライド可能なので、単純なキャストとは異なる値を入れることができるのです。

動作が分かるように極端な例を示すと、

Public Class AClass
    Public Shadows Function ToString() As String
        Return "ToString AClass"
    End Function

    Public Shared Narrowing Operator CType(ByVal b As AClass) As String
        Return "Cast AClass"
    End Operator
End Class

ToString をオーバーライドしたものと、キャストを再定義したものを用意します。
すると次のコードでは実行結果が違ってきます。

        Dim a As New AClass
        ' ToString の場合
        Debug.Print(a.ToString())
        ' Cast の場合
        Debug.Print(CType(a, String))

▼実行結果

ToString AClass
Cast AClass

こんな風に、ToString が定義されている時は、思ったとおりには動かないのです。まぁ、こういう時は、String 型へのキャスト自体も危ういところなのですが、ひとまず ToString とキャストは違う動作をする、ってことを覚えてコーディングして欲しいなぁ、と。

余談を言えば、キャストの場合は string 型にキャストできない場合は例外を発生させるけど、ToString 型は例外にはならない(多分ならない)ですよね。このあたり、意図して ToString メソッド(ToIntegerメソッドとかと同列の意味で)を使う分には ok ってことなのです。

コードを短くすると単体テストが楽になる、の検証編 | Moonmile Solutions Blog
http://www.moonmile.net/blog/archives/2167

の続きで、実は適切なコードの書き方をしないとテスト項目は減りません。

# マーチン・ファウラー氏の言う「流れるようにコーディングをする」ことと
# コード自体の品質とは別なのです。
# 当然、コーディングがしやすい、というのも品質を上げる要因のひとつ
# であることは変わりありませんが。

これを検証してみます。
まずは、以下の3つのパターンを見てください。

A.通常パターン

Window win = new Window(800,600);
win.SetMessage("hello world.");
win.Show(0,0);

B.プロパティで設定するパターン

Window win = new Window();
win.Width = 800;
win.Height = 600 ;
win.Message = "hello world.";
win.X = 0;
win.Y = 0;
win.Show();

C.メソッドチェーンのパターン

Window win = new Window(800,600).Message("hello world.").Show(0,0);

非常に極端に書いていますが、典型的なコーディングの3つのパターンです。

A の通常パターンは、コンストラクタでサイズを指定して、その後でメッセージを設定しています。
表示をするときには、Show メソッドの引数で指定する、という関数呼び出し風なパターンですね。

この関数呼び出し風のパターンは、一見わかりやすそうですが、ぱっと見たときに引数が何を意味するのか分からないという欠点があります。例えば、次のように XY 座標をコンストラクタで設定するコードを書いたときは、

Window win = new Window(0,0,800,600);
win.SetMessage("hello world.");
win.Show();

なのか、

Window win = new Window(800,600,0,0);
win.SetMessage("hello world.");
win.Show();

なのかは、わかりませんよね。経験上、X,Y,Width,Height)の順と知っていても、それはマニュアルなど読まないと本当は分からないわけで、引数の意味はコード上には出て来ないのが普通です。

# よく MSDN で引数が混在しているコンストラクタやメソッド(Drawメソッド系とか)がありますが、この現象に陥っています。

さて、B のようにプロパティで指定する方法が、VB2.0(.NETにあらず)ありました。VBA でもこんな書き方をするし、tcl/tk もこんな書き方です。この書き方の欠点は、縦に長くなる（行数が多くなる）ということですね。大抵の場合、1 行にひとつの処理を書くことが多いので、A のコードよりも長くなるのが欠点です。
ただし、VB の場合は「:」を使ったり、C# の場合は「;」で複数行をまとめることができるので、

Window win = new Window();
win.Width = 800; win.Height = 600 ;
win.Message = "hello world.";
win.X = 0; win.Y = 0;
win.Show();

このように書いて、行数を短くすることができるのですが、A と B のパターンは決定的に違うところがあります。
A の場合は、Width と Height を同時に指定することができるのですが、B は、ひとつずつしか指定できません。なので、画面を表示したままのときに、Width, Height の順番に設定すると、横幅が変わった後に、縦幅が変わる、という現象が起こるのですね（実際、VB2.0 の頃には、そのような現象が発生していました)。なので、Width と Height の順番が重要で、実は変な感じなのです。

次は、最近流行(?)のメソッドチェーンの C パターンを見ていくと、あたかも 1 行で書けるために A パターンよりもすっきりしているように見えます。
コンストラクタで画面サイズを指定して、メッセージを追加して、画面の左上に表示するということがわかります。

ただし、これもメソッドの作り方が悪い、先の B のように順序が関係してきます。

Window win = new Window().Width(800).Height(600).Message("hello world.").X(0).Y(0).Show();

何をやっているのか、分かるような分からないような微妙なコードになります。C# の場合は、改行を入れることで少し読み易くできます。

Window win = new Window()
 .Width(800)
 .Height(600)
 .Message("hello world.")
 .X(0)
 .Y(0)
 .Show();

あれ？これって、B のパターンと同じですよね。
また VB.NET の場合は、With を使うと、B のプロパティのパターンを C のメソッドチェーンのように書けます。

Dim win = new Window();
With win
 .Width = 800
 .Height = 600
 .Message = "hello world."
 .X = 0
 .Y = 0
 .Show()
End With

ということはですね。実は、B のパターンで書いても、C のパターンで書いても、同じ数のテストをこなさないといけないのです。自由度が変わらないですからね。

じゃあ、A の通常パターンで書いた時には一番テストの数が少ないかというと、そうでもありません。

Window win = new Window(800,600);
win.SetMessage("hello world.");
win.Show(0,0);

1. コンストラクタの Window の引数は Width,Height なのか？ Height,Width なのか？
2. Show メソッドの引数は、X,Y なのか？ Y,X なのか？

という自由度が増えています。
実は、Window(0,0,800,600) としたときには、自由度が倍増します。実際コーディングをいくと実感できると思いますが、

func( int x, int y );
func( int x, string s );

ような 2 つの関数があったときには、int, int よりも、int, string のほうが間違いが減ります。
というのも、int, int の場合は、引数の順序を間違える可能性がありますが、int, string の場合はコンパイル時にはじかれてしまいますよね。これは、string, int のように逆のメソッドを作ることもできることを意味します（勿論、int,string と string,int の 2 つのメソッドが共存する場合は、どちらがどちらの意味なのかという別の自由度が発生しますが）。

というわけで、結論を言えば、A も B も C もテスト項目は同じぐらいになります。ゆえに、複雑度が同じという推測が立ちます。
推測を証明するために、先のようにメソッドと変数の数を勘定すると、

A パターン: 10
B パターン: 11
C パターン: 9

という数になります(引数が2つある場合は、それぞれの引数と交換を含めて自由度は3で勘定します)。
メソッドチェーンを使った場合は、若干小さくなりますが、思ったほど楽にならない、というのが検証できると思います。
まぁ、それでもインテリセンスが利いている最近の統合開発環境では、ピリオドを打った後にメソッドやプロパティ名が自動で出てくるのはいいですよね。メソッドの多重化が過ぎて 10 以上のメソッドから選ばないといけない、というアンチパターンよりいいと思います。

↓これとか、しんどくて…

Graphics.DrawImage メソッド (System.Drawing)
http://msdn.microsoft.com/ja-jp/library/9f3f6hy1.aspx

いわゆる「○つの方法」という釣りタイトルですが、ワタクシ的には例外処理に関しては一択です。
例外処理については、方法論的にも色々あるのは分かっているのですが、「業務」という範囲で考えると、という選択です。

UIがある場合とない場合で、ちょっとだけ書き方が分かれます。

// UIのある場合
int func(...) {
 try {
  // 全ての処理
 } catch ( Exception ex ) {
  // エラーメッセージを表示
  MessageBox.Show( ... );
 }
}

// UIのない場合
int func(...) {
 try {
  // 全ての処理
 } catch ( Exception ex ) {
  // そのまま例外を返す
  throw ;
 }
}

こんな風に、関数/メソッド内の処理を【全て】try catch で囲ってしまいます。
乱暴ですよね…ですが、この方法って VB3.0 の頃からの鉄板な方法だったりします。

sub func(...) 
ON ERROR GOTO L_ERROR

 ' 内部のすべての処理

 exit sub
L_ERROR:
 ' エラーメッセージを表示
 MsgBox(...)
end sub

のように、VB の頃(.NETではない)は、ON ERROR GOTO を使っていました。
さて、この頃 C++ はどうだったかというと…実は C++ は余り流行ってはいなくて、いまだ C 言語が主流でした。なので C 言語の場合は、

void func( ... ) 
{
	int err ;
	
	err = subfunc( ... );
	if ( err != 0 ) {
		// エラー処理
	}
}

な風に、戻り値でエラーを判別するしかなかったのです。

この鉄板の例外処理でログイン処理を書いてみると、

class Principal {
  string _username ;
  
  public bool Logon( string username, string password ) {
    try {
      if ( username == "" ) 
        throw new Exception("ユーザー名が空白");
      if ( password == "" ) 
        throw new Exception("パスワードが空白");
      if ( username == "root" ) 
        throw new Exception("rootユーザーはログインできない");
        
      SqlConnection cn = new SqlConnection(...);
      SqlCommand cmd = new SqlCommand( cn, 
        @"SELECT count(*) from usres 
          where @username = username and @password = password" );
      cmd.Parameters.Add(new SqlParameter("@username", username ));
      cmd.Parameters.Add(new SqlParameter("@password2, password ));
      cn.Open();
      int cnt =(int)cmd.ExecuteScaler();
      cn.Close();
      if ( cnt == 0 ) 
        throw new Exception("ログインできない");
        
      // ユーザー名を保持して正常終了
      this._username = username ;
      return true;
    } catch ( Exception ex )
      throw ;
    }
  }
} 

なにやら妖しげなコードになりますが（苦笑）、業務コードの場合はこっちのほうがすんなり通るし頑健なのです。

実は、このコード例外の throw が大量に書いてあるので安全なコードとは程遠いような気もしますが、ライブラリとしての使い方ではなくて業務コードをこのスタイルにしていまうと、exception の catch が必須になるので、これはこれで安全なのです。

フェイルセーフなコードを書くには？ | Moonmile Solutions Blog
http://www.moonmile.net/blog/archives/2173

さて、この業務コードを利用する側も try catch を多用します。

/// ログインボタンのクリック
protected void Login_OnClick(...)
{
	try {
		Principal user = new Principal();
		string username = TextUserName.Text ;
		string password = TextPassword.Text ;
		// username, password のチェックは一切しない。
		user.Logon( username, password );
		// 成功時にフォームにユーザー権限を保持する
		this.User = user ;
	} catch {
		// 例外発生は、一律「ログインできない」とする。
		MessageBox.Show("ログインできませんでした");
	}
}

こういう書き方を一律すると「正常系」を一気に書くことができます。
この発想のベースは、VB3.0 の頃からある ON ERROR GOTO なんですけどね。

こんな風な例外処理を取る場合、いくつかの前提条件があります。

・データベースアクセスが基本、正常に行われること。
・処理の流れが基本、正常系で流れること。
・プログラムのバグは、基本皆無であること（実行時にデバッグログ等を取らない）。
・ユーザーへは基本、アプリケーションエラーを知らせないこと。

ということです。このプログラムの書き方は、プログラムの潜在バグを隠してしまうというデメリットがあるのです。ですが、ワタクシ的には「リリースしたプログラムは、ユーザーの目の前で落ちないことが最優先ではなかろうか？」と考える訳でで、突如として落ちないことを最優先にする（それが潜在バグを隠すものであったとしても）と、こういう例外処理の使い方もありかなぁと考えています。

ちなみに、そこそこの業務以外では、こういう書き方をしません。アリだとは思うのですが、業務コードを書くときに限ってという話です。手元のツールを作るときなんかは DEBUG 定義などを利用します。

後で、SQL Server 2008 とかの最新バージョンを調べますが、落とし穴になりかねないのでメモ。

create table test1 (
 id int,
 name varchar(10),
 num int 
);

として test1 テーブルを作成しておきます。
ここに次のようなデータを入れます。

delete from test1 ;
insert into test1 values(1,'masuda',10);
insert into test1 values(2,'tomoaki',20);
insert into test1 values(3,'100',30);

このデータを検索します。

select * from test1 
 where num = 10 ;

この結果は予想通り、１行目が取得できます。

1	masuda    	10

さて、num に文字列の’10’を指定したときはどうなるでしょうか？

select * from test1 
 where num = '10' ;

マッチングしないと思いきや、自動的に文字列型から数値型に変換されて、１行取得されます。
# Oracle の場合は変換エラーになったと思うのだけど、うろ覚えです。

1	masuda    	10

逆に文字列型(varchar)に対して数値で比較してみると、

select * from test1 
 where name = 100 ;

これはエラーになります。

サーバー : メッセージ 245、レベル 16、状態 1、行 1
構文エラー。varchar 値 'masuda    ' から int データ型に変換できませんでした。

１行目の name 列の値「masuda」が int 型に変換できないためにエラーになっていますね。
となると、name 列の値が全て数値型になるようにしたら、どうなるのでしょうか？

delete from test1 ;
insert into test1 values(1,'100',10);
insert into test1 values(2,'200',20);
insert into test1 values(3,'300',30);

というデータを入れた場合に、次の SQL を動かすと、

select * from test1 
 where name = 100 ;

実は、結果が取れるのですッ!!!

1	100	10

そんな訳で、SQL Server 2005 の SQL を書くときに、自動変換をあてにしたり、自動変換がされるような書き方をすると、はまる可能性があるよという話でした。
これは、.NET から扱うときに、SqlParamter オブジェクトの使い方が問題になってくるのですよね。これは別の記事に。

関数言語風なところ(LINQ)や、手続き型の関数の羅列を取り除いて、オブジェクト指向オンリーでプログラミングをする言語を妄想（笑）してみます。個人的には、純粋オブジェクト指向言語は Java がそれに近いのですが、もうちょっと何とかするいう形で。

まず、オブジェクト指向言語の重要な要素を挙げると、

1)カプセル化（隠蔽化）できる。
2)ポリフォリズム（多態化）できる。
3)継承関係がある。

なところです。

ここで、焦点を当てるのは「カプセル化」です。
もともと、オブジェクト指向の最初は、オブジェクト同士のやりとは「メッセージ」を使ってやり取りをしています。

objectA -> message -> objectB

のような繋がりになります。このメッセージ(message)は、objectA のメソッドなのか、objectB のメソッド(リスナー？）なのかは、定義されません（とか思っています）。

また、メソッド（関数）の呼び出しは、C言語やC++の表記上、複数の引数とひとつの戻り値、という決まりがありますが、実は戻り値は複数でも構わないのです（F# のタプルと同じですね）。

objectA.Method
{
  (retA, retB, ... ) = objectB.Method(paramA, paramB, ... )
}

な形です。

さて、手続き型の流れの場合は、if 文を使ってフロー制御をしますが、純粋オブジェクト指向の場合は if 文の扱いは、ちょっと慎重になります。

if ( a != null ) {
  if ( b != null ) {
    objB.Method( a, b );
  }
}

のように呼び出し前にチェックを入れますが、純粋オブジェクト指向では呼び出し時のチェックをしません。
これは、パラメータの整合性のチェックは、呼び出されたオブジェクト側の責務であり、呼び出し側では判断がつかないためです。もう少し詳しく言うと、隠蔽化を進めるとどのパラメータが正常値であるのかは、呼び出されたオブジェクトしか分かりません。

なので、責務を明確にするために、

// 呼び出し側では、パラメータチェックをしない
objB.Methd( a, b )

// objB の中でパラメータチェックをする
void objB.Method( string a, string b ) {
  if ( a == null ) return ;
  if ( b == null ) return ;
  // メソッド内の処理をする
}

この場合、objA から objB への問い合わせが非常に多く発生するため、パフォーマンス的には良くない（と想像される）のですが、オブジェクト指向の視点から言えば、これが正しいのです。なお、オブジェクト指向でのメソッド呼び出しのコストは「0」となっています。なので、呼び出しが多くても少なくてもスピードは関係ありません（ということになっています）。

この部分、責務を明確にする、ということで、objA で判別するべきか、objB で判別するべきか、というので見解が分かれそうですよね。例えば、次のコードを見てください。

if ( a == "masuda") {
  objB.Method( a, b );
}
// objB の中でパラメータチェックをする
void objB.Method( string a, string b ) {
  if ( a == null ) return ;
  if ( b == null ) return ;
  // メソッド内の処理をする
}

こうなっていた場合、a == “masuda” は何を意味するのでしょうか？ここだけ見ると、変数 a の内容が “masuda” の時に、objB.Method を呼び出す、という条件にしかならないので、これがオブジェクトの内部を考慮してのものなのか、オブジェクトを呼び出すときの条件なのかが判断がつきません。なので、他のところで、

if ( a == "tomoaki" ) {
  objB.Method( a, b );
}

と違う値で呼び出していることを確認した時に、オブジェクトの呼び出し側がつけている条件（呼び出されているクラスの前提条件ではない）ということが判断できます。
なので、書き方として、

・呼び出し側で判断する制御文
・隠蔽化を強化するための制御文

の2つを区別しないといけません。

objB.Method( string a, string b ) {
	// 前提条件
	if ( a != null ) {
	if ( b != null ) {
	// 処理内容
	if ( a == "masuda" ) {
		objC.Method( a );	
	}
	}}
	return ;
}

のように書き分ける必要があるのですね。
たしか、アスペクト指向の書き方として、そんなのがあった覚えがあります。

obj.Method.Before( string a, string b ) {
	if ( a == null ) return ;
	if ( b == null ) return ;
}
obj.Method( string a, string b ) {
	// 処理内容
	if ( a == "masuda" ) {
		objC.Method(a);
	}
	return ;
}
obj.Method.After( string a, string b ) {
	...
}

Method.Before では、本体 method の前処理を担当して、主にパラメータをチェックします。
Method.After では、後処理を担当します。

…と書いたところで、力尽きました orz もうちょっと大雑把に議論したほうがいいみたい。