増5．プログラム原則考（断章）

スキル

» 2011/11/24

●今回の発端

　前回のPHPフレームワークについてのコラムを作成する際、SOLID原則などプログラムの（ここ数年に出来た最新の）原則について触れる機会がありました。

　もちろん、それらを目にしたのは生まれて初めてではなく、前から目にはしていたのですが、まったくと言っていいほど実務とは無縁でした。

　それには何か理由があるのではと思い、ぱっと思いついた限りで“原則”の形でまとめてみました。

　ただし、あまりに後ろ向きなので“原則”ではなく、“アンチ原則”とさせていただきました。

●Diffツールのアンチ原則

　多人数でレビューしながらプログラミングを実施する際、Diffツール(WinMergeやRekisaなど含む）で追えない修正は認められにくい。

// a = b; //2011/11/23 DEL by くわぢ
a = b + c;

なら通っても、

func a(b, c){実装}
　　　↓
func a(b, c){a_実装への呼び出し}
func e(b, c, d){a_実装への呼び出し}
func a_実装(b, c, d){実装+パラメタdの対応}

は通らない（自分1人で作って後で追認してもらえる場合は通る事があるが、レビューしながらの場合、まず無理）。

　これが通らない限り、単一責任の原則も、リスコフの置換原則も、インターフェイス分離原則も困難。修正するには、行をコメントアウトして、行ADDが基本。

●既存機能のアンチ原則

　いままで当たり前のように使っている機能に何のひねりも無く、新しい名前をつけるだけで新機能するのは無理。

　DIなんてVBプログラマからして見れば、単なる（ポータブルな）参照設定以上でも以下でも無い。にもかかわらず、「新しいプログラミング原則」だとか言われると、致命的に混乱する。

●機能遍在のアンチ原則

　インターフェイスは単に「似ている」を表しているに過ぎず、機能（責務）はどんなプログラムの部分（プログラムで利用される単なるデータであっても）にも遍在して存在する。インターフェイス化しさえすれば機能（責務）が分離されるわけでも、凝集されるわけでもない。

個別の機能（責務）まで細かく勘定するなら、よっぽどの事が無い限り（トイ的に単純でない限り）、「拡張に開いた」なんてあり得ない（“閉じた、発展しない”ならあり得ると思う……）。

●モジュール化不可のアンチ原則

　前回のHTML文書もそうだし、RDBのテーブルによるデータ表現もそうだが、

• モジュール化が原理的に不可の場合
• モジュール化が規格化されて末端の人間でも使える様になるためには、“リニアが新大阪まで全通”なみの大プロジェクトになる場合

　そのモジュール化に依存すべきでない。

　プログラムはいくらでも分離・習合できても、それに応じて他のどんな対象も同じようにできるわけではない（自明ではない）。

　テスト駆動開発が便利なのはわかるが、RDBのテーブルによるデータ表現は、そんなに簡単に個別の分離されたメソッドに寄り添ったりしない。

　まぁ、今回はこんなところです（この話題は未消化なので、また別のコラムで述べるかもしれません）。

●コラムのコメント欄の方針

　

コメントに対し、当意即妙の回答を、それなりのタイミングでする自信がありません。

　ですので、このコラムで、
　・わたしは基本的にコメントに答えない
　・コメントを書く人は、回答がない前提で議論を進めていただく
とさせていただきます。