プログラム＝インターフェイス＋アルゴリズム＋データ構造

ここの記事「「アルゴリズム＋データ構造＝プログラム」？ 本当に？」がすごくホットで面白い。

普通、IT業界に入社した当初は、現実世界をコンピュータ上へシミュレートする時、全てのロジックを構造化された形式に直すのがSEの仕事だと習う。
まさに、アルゴリズムやデータ構造を考えているのと同じ。

プログラマは、インターフェイスよりも、アルゴリズムを考えたり、データを保持するためのデータ構造を考える時が多い。

インターフェイスは、設計者によって既に作成され、プログラマは設計書に従ってコーディングする時が多い。

だから、インターフェイスを考えるプログラマは少ないのでは？

昔のFortrunやBasicのプログラムを読むと、ローカル変数が存在せず全てグローバル変数とか、サブルーチンが存在せずGoTo文しかないとか、今では考えられないような制約があった。
その頃の考え方の遺産が「アルゴリズム＋データ構造＝プログラム」。

最近何故かVBを仕事でやらされているが、JavaやC#がいかに書きやすいか、まざまざと感じさせられる。

・型チェックが弱い。コンパイルしても、実際に動かさないと、コンパイルエラーすら見つからない！！
・実装継承がないのでポリモルフィズムが使えない。Case文がやたらと多い。
・例外処理がないので、GoTo文を使うしかない。
・Formに全てのロジックを書いてしまっているために、シーケンス図で書くと、肥大化したクラスそのものになってしまう。
・クラスを使うロジックが少ないため、関数の引数がやたらと長い。
・関数の引数に戻り値を渡す書き方が多いため、混乱しやすい。
・VBはFTP等のネットワーク系ライブラリが使いづらい。
・Collection等のコンテナのライブラリの機能が少ないため、基本的なアルゴリズムをわざわざ実装する手間がかかる。

オブジェクト指向プログラミングは、アルゴリズムやデータ構造をオブジェクトの中に隠蔽してしまい、インターフェイスだけを考えれば良いプログラムが書ける、という発想。
インターフェイスを突き詰めて考えると、複雑な処理は、多数のクラスへ分割され、プログラム構造は階段状のシーケンス図で書き表される。
GoFのデザインパターンは、結局インターフェイス設計を説明しているのと同義。

現代の考え方は「プログラム＝インターフェイス＋アルゴリズム＋データ構造」。

しかしながら、少なくともVBプログラマにはそういう発想はないみたい。
VBなんか、消えてしまえばいいのに。