認知的プログラミング

デザインパターンとその運用

GoF デザインパターンが発表されて２０年近く経過していますが、開発の現場では、その真意があまり理解されていないように感じます。特に Java プログラマが実装した C++ コードや、C++ プログラマが実装した C# コードなどでは、異なる言語仕様の上に自分が得意な言語での実装方式を無理矢理持ち込んでいるような事例を見る機会は少なくありません。

GoF の本を読めば、一番最初に書いてありますが、目の前に解決すべき実装上の問題があって、その問題の解決手法を抽象化したデザインがデザインパターンであり、実装については、実装を行う言語の言語特性を正しく理解した上で、どのように実装すべきかを考えるべきです。特定の言語における実装は、あくまで例であり、異なる言語で実装する場合には、再びどのように実装すべきかを検討しなければなりません。

確かに、自分の得意な言語があって、似たような言語であまり使い慣れていない言語を利用する場合には、過去の経験に従って実装を行うことは自然な流れであり、また新たな言語は「使い慣れる」までに相応の時間を必要とするため、前述のような結果になってしまうことは無理もない話ではあるのですが、そのコードをメンテナンスするプログラマに対しては、全てを書き直したくなる欲望との戦いを強いることになってしまいます。

問題記述におけるプログラミング言語と自然言語の持つジレンマ

GoF の本は、主として オブジェクト指向設計における実装時の問題とその解決方法に着目しているわけですが、その記述はサンプルコードが付属しているとはいえ、あくまで英語や日本語の自然言語での記述が中心です。

しかし、自然言語での論理記述は、文書化された RFC などの規約をもとに実装を行った経験がある方は思い当たる部分があるかと思いますが、自然言語での規約の定義はいざ実装してみると、抜けや矛盾を含んでいる場合が少なくありません。

つまり、プログラム設計時の問題をプログラム言語で表現すると、その問題の本質を覆い隠してしまい、かといって自然言語で表現すると、そこに抜けや矛盾を含んでしまうというジレンマが、デザインパターンに限らず、論理的な問題を的確に記述することを困難にしているとは考えられないでしょうか。

問題共有のための記述

長々と述べましたが、システム開発における成功と失敗を分ける大きな要因である情報共有を確実に行うためには、問題を的確に記述する必要があり、その手法について今後も考えていきたいと考えています。