「Form Loadで画面を表示しないでCloseしたい。」 という話題が 定期的に再燃しています。
FormのLoad処理と 破棄処理を同一Eventレベルで考えてしまうことにビックリなのですが. 何故だろうと考えて見ました。
[VBは基礎的知識なしでもプログラム可能だから,VBな人(VB-onlyな人)は不勉強である]といってしまえば元も子もないのですが。
[(以下VBな人(不適切な代名詞ですが,ほかに適切単語がないもので..) と称します]
VBは,Formのインスタンス化を意識しなくても使える (スタートアップの設定をFormしている時)ものだから, objectのインスタンス化の概念が体得できていない。
xxx_load()が最初に動く部分に見える(画面をClickすると該当ソースが生成されますし)ので, xxx_load()がエントリーポイントだと信じている。
Eventドリブンの意味合を斟酌しないで使っている。
「Eventで呼ばれているルーチンは, 処理の途中工程なので,早く制御をもどしてあげないと,後工程が痞えることもある.」このことが,理解できてない。
xxx_Paint() で DB-Accessルーチンを書いたり, lostFocus/LeaveFocusでカーソル制御を行い,壁にぶち当たったりしている人が結構います。
役割分担が曖昧で, 画面のカーソル制御と, DBアクセスが同レベルで記述されていたり, 入力項目Checkのとカーソル制御がごっちゃになって,スパゲティ状態になったり...
(それても,業務的には VBの生産性は高いとされるので,関心します。)
メソッド(関数)内の処理は,単一目的にすべきですが, 意味合いの異なる処理を混在させる人をたまに見かけます。ソースの見通しが悪くなるので,不可なのですが、
パフォーマンスの改善のためだと言い訳してきます。パフォーマンスを疎かにしてはいけませんが、ソースの可読性を犠牲にしてまでパフォーマンスを追求するのはいかがなものでしょうか。
(この局面は,一般的な業務アプリを想定してます。制御系などパフォーマンス重視のアプリは別問題です。)
object指向開発と,厳格なパフォーマンス追求は,対立する場面もありそうです。せっかくのメリットが死にます。
コスト意識のレベルの一貫性がないことも問題です。 100円にたいする 10円の増減はコスト負荷が高いですが, 10,000円に対する10円は誤差の範囲でしょう。
100,000円に対する10円のレベルてパフォーマンス云々を言っているケースも見受けられます。(特に,RDB_IOなどの高コスト処理などで)
1%以下のパフォーマンス向上のためにロジックを汚すのはいかがなものでしょうか?
意味を理解しないで(不勉強でも)作れてしまうVBの構造的な宿命かもしれません。
動けばOKとする、目を覆いたくなる現場が,あちこちにあります。object指向以前の問題で,Eventドリブンの意味すら,きちんと習得していないようです。
VBな人の責任は大ですが, 業界として, 底上げを考えないと, VBの地位低下につながります。 VBなognacとしては残念なことです。
(CF) http://blogs.wankuma.com/jeanne/archive/2006/02/12/21205.aspx