すでに教員を辞めているが、教え子達と年1,2回程度飲み会をしている。ほとんどは私の研究室出身ではなく、学生の時からIT技術に関しては私より遥かにレベルが高かった。彼らの年齢は40前後であるが、いまだに付き合いがあるという奇妙な関係である。そこで話題になったデザインパターンの話を取り上げる。私はIT系の仕事から離れて現状には疎くなってしまったが、教え子達が言うにはデザインパターンという用語も最近ではあまり聞かなくなったらしい。発端は私が響研究室の助教だったときのゼミでの話である。
大学院生がゼミで「しばらくデザインパターンを勉強しようと思います」と発言した。本来なら進捗報告をする場であったが、勉強をするからしばらく進捗は無いという意思表示だったようだ。私は「君が使っているのは C 言語だろ。Cではデザインパターンはできないよ。」と発言した。デザインパターンという用語もそこそこ浸透してきた時代であるが、響教授は知らなかったようで「デザインパターンとは何だ？」と問いかけてきた。「オブジェクト指向のプログラミングテクニックで、例えばシングルトンはインスタンスを１つに限定する技法です。」と答えた。何が気に入らないのか響教授は突然「オブジェクト指向の思想は言語に限定されるものではない。アセンブリでも可能だ。そんなのはインスタンスを１つにすると決めておけば良いのだ。」と私を罵倒した。こんなことは日常茶飯事であるが、私の説明が不適切だったのだろうか。少なくとも響教授の取り決めで解決する案は正しくない。ルールは決めても守られないから強制する仕組みを与えるのがシングルトンだからだ。
教え子達の話では、オブジェクト指向言語でなくてもデザインパターンを実装できるという。デザインパターンには色々な種類があるから、オブジェクト指向言語でなくても実装できるパターンも多数あっても不思議ではない。それでは、シングルトンをアセンブリで実装できるのかを聞くと、それは難しいようだ。アセンブリや C は制限が緩いだけに何でもできそうであるが、逆に禁止することが難しい。例えば、変数へのアクセスを制限するような場合である。setter や getter を介して変数をアクセスする仕様を決めても、手順を守らずにアクセスするプログラマーは出てくるであろう。言語仕様を利用して防ぐのは良い方法だと思う。
1990年代にIT系の教員となった頃、Fortran を使っている研究室はまだ残っていたが、Cが主流になっていた印象である。2000年代になってから C++ や Java が普及し始め、開発言語も移り変わってきた。この間にプログラミングの考え方も大きく変化したように感じる。以前はライブラリの利用者が十分理解する義務があり、誤使用は利用者側の責任であるという考えであった。難解なコードを作成して、「俺様の高度なプログラミングが理解できるかな」と自慢しているかのようなものもあった。C言語のライブラリの中には副作用を伴うものがあり、問題が生じても十分理解しないで利用したプログラマの責任と解されていた。今ではこういったライブラリは使用を推奨されなくなってはいる。それが誤った利用をさせないソフトウエアを提供すべきという思想に移行した感がある。誤使用は出来るだけコンパイラにより、少なくとも実行時に例外で検出されるようなプログラミングスタイルが求められるようになった。そういうプログラミングの思想を意識する授業を心がけてはみたが、伝えるのはなかなか上手くいかなかった。
