仕様
値Aと値B のIO用のTextBoxと
加算結果を見せる表示用Label(値C)と指令Buttonを配置し,指令Buttonで C= A+B を計算して, 結果をLabelに見せる,
これを実装するとき,
A:
Class 画面 inheirts Form
lbl_C.text = 計算.加算(txt_A.text,txt_B.text)
End Class
Class 計算
Public Function 加算(a as String, b as String) as String
return cdec(a)+ cdec(b) ' a,b,の非数Check省略
End Function
End Class
とするべきですが,下のようなのも見かけます
B:
Class 画面 inheirts Form
計算.加算(me)
End Class
Class 計算
Public Sub 加算(fm as 画面)
fm.C.text = (cdec(fm.a.Text)+ cdec(fm.b.Text) ).ToString' a,b,の非数Check省略
End sub
End Class
違和感とは違う不安定感を感じます。
Object指向云々以前の役割分担の切り分けの話になります。
引っかかる点は二つ.
加算メソッドの役割が, 加算演算のロジックと, labelのtextプロパティ操作の二種類混在している。
加算メソッドに,画面Objectの構成を持ち込むのは独自性が崩れる
なぜこのmeを渡したがるのか、
「加算関数はこの画面からしかCallされない。 A,BはTextboxで固定だから, このほうが.,わかり易いし,記述,テストが早い。その他.....」
手軽だから,このように記述してしまうようです。
役割分担からみると, 画面上のTextBox, Labelは,値の入出力用の器です。 演算メソッドは,値の加工です。 加工工場に,器を渡すと,器から値を出し入れする手間が,演算メソッドに加わるだけでなく,どの種類のどの名前の器なのかを意識しなくてはならなくなり,負担増になります。
加算メソッドのような1行メソッドでも,実装の仕方如何で,効率性が左右されます.ましてやシステムをや。