「実はオブジェクト指向ってしっくりこないんです！」というタイトルで執筆したコラムを公開してから今年で13年が経過した。
内容としては、オブジェクト指向の有用性に疑問を感じ、シンプルなstatic関数を使って社内アプリを構築していることを述べたものです。自分としては正常にプログラムは動作して多くのユーザーが利用していたので社内SEとしては問題ないものと思っていいたのですが、今流に言うと多数のアンチコメをいただきこの記事は炎上した。プログラミングネタを書くとコラム主の足を引っ張ろうとするその手のアンチコメが多く当時の＠ITの炎上対策が手薄のためIT業界としては今だに最大のブログ炎上となっています。オブジェクト指向関連の書籍販売やプログラミング教育関係者などの利害もからんでいるのもアンチコメが多い要因になっていると思われます。実際にデザインパターンというオブジェクト指向技術に関する本を買うのを薦めるコメントがありましたし、Twitterなどで、「この人は勉強しない人」「反面教師、こうならないように勉強しましょう」などと、オブジェクト指向の書籍購入や勉強を示唆するコメントが多数ありました。インターネットで無料で技術情報が収集できる時代になってきましたので、やはり出版業界といのは苦しいと察しがつきますが、学生は無料で得られるコンテンツのみ求めているのが当時からの風潮ですよね。アンチコメントに反論すると、当人のブログやTwitterなどで「上から目線」と非難されましたが、今もYoutubeなどで「上から目線」はアンチコメの捨て台詞としてよく書かれる言葉みたいなので、もう気にしないことにします。
ここ数年は、関数型言語に注目が集まっているので、オブジェクト指向技術も万能ではなく弱点があると言われるようになりました。とあるYOUTUBERによると最大のオブジェクト指向の産物はWindows95だそうです。今だに全盛期の産物なのですから、やっぱり何かオブジェクト指向はしっくりこない点がありそうです。Windows95はマイクロソフト社がグラフィカルユーザーインターフェース(GUI)を採用したPC OSです。
GUIにはボタンやテキストボックスなどの部品がディスプレイ上に表示されるわけです。こういったGUIアプリケーションの部品は、開発ツールで配置設定することができます。ボタンですと、ボタンの位置や、縦横の長さ、ボタン上に表示する文字列を設定すれば、指定された形状にディスプレイに表示されます。これらの位置や、縦横の長さ、表示する文字列などをオブジェクト指向の世界ではプロパティと呼んでいます。
GUIでオブジェクト指向が成功した理由は、このボタンなどのソフトウェア部品のプロパティというもは、ほとんど独立のパラメータで、お互いに干渉したりしない、それらの部品を設置設定し、正確にディスプレイに描画させる開発ツールや実行環境を作ってしまえば、アプリケーションの動作に影響を与えない点にあります。ですから、多種多様な様々なパラメータをプロパティとして定義で、実装検証もとにかく正しく表示制御されれば問題なく使えるわけです。しかし、同じ縦横のパラメータでも長方形の面積を計算する上での縦横の長さはどうでしょうか？この二つだけのパラメータだけならいいんですが、他の多種多様のパラメータと混在する場合、的確なパラメータを拾ってきてメソッドで演算することはバグや手違いが発生しやすいです。
クラスのプログラムコーディングではメンバー変数やプロパティというものは、クラス内のメソッドの演算結果に影響を与えるのが可能なことから、プロパティが増えることはリスクが高くなります。バクの発生を抑えるという観点からば、メンバー変数、プロパティは最小限が望ましくなります。そんなわけで、ビジネス用途でのオブジェクト指向の適用は適切でないのかもしれません。私の感覚ですと、なるべくメンバー変数をつかわないstatic関数で、よく使う共通処理などを実装すればデバックが容易になります。
オブジェクト指向の入門演習などで、メンバー変数やプロパティ値の値を入れて、メソッドで四則演算する課題などありがちですが、四則演算といえどもビジネス計算の基本なので、実践開発では、メソッドの入力値は、メンバー変数やプロパティでなく、メソッド引数として割り当てるのが私流の考え方です。
オブジェクト指向の利用目的は現実世界のシミュレーションとも言われています。Windows95におけるオブジェクト指向技術によるGUIインターフェイスの実現は、オブジェクト指向技術が正に現実世界のボタンやテキストボックスの配置をディスプレイ上に反映してものであって、それ以上のものではないのです。あくまでも視覚的な効果で、それらは従来ビジネス計算で扱っていた数値ではないのです。GUIコンポーネントが最適な位置、大きさ、色に表示されていればいいだけなのです。適切は配置ならば使いやすく、そうでないならば使いにくいだけです。しかし現代の私たちはコンピュータとインターネットを駆使して商品の売買、銀行取引、株の売買をします。そういった取引の数値や金額は少しでも間違えがあっても不可で、どのようなパラメータが反映されて計算されていないか明確でなけらばなりません。そういった意味で、配置や大きさや色が適切ではればいいボタンやテキストボックスの表示とは全く別の問題で、それらを一緒に扱おうとするオブジェクト指向分析手法には無理があるように思えます。
オブジェクト指向パラダイムは従来型のプログラミングパラダイムにとってかわるものではなかった・・・
プログラミングパラダイムはいくつかのものが共存しててもかまわない、オブジェクト指向パラダイムと従来型やその他のプログラミングパラダイムと共存可能
オブジェクト指向的技法でソフトウェア部品を作るとするとフロントはクラスで実装し、プロパティやメソッドにアクセスできるように、つまり部品が使えるようにコーディングしますが、クラスからは従来型の関数を呼び出しても問題なく、むしろそのほうがシンプルで可読性の高いコーディングとなります。
今でこそグラフィカルユーザーインターフェースが当たり前で、画面上にボタンやテキストボックスのあるアプリが主流ですが、それ以前の時代は手探りで、ディスプレイ上に仮想現実を作り出すには、オブジェクトからどのようなパラメータをプロパティとして定義したらいいのか真剣に研究していた時代が過去にあったのでしょう。オブジェクト指向の入門書で、よく犬や猫や車の事例で現実世界のシミュレーションとして語られますが、あれはたとえ話ではなく、本当にその手のことが当時の研究者の間で検討されたと思います。実のところ私もあれはたとえ話であって入門者にわかりやすくオブジェクト指向を理解していただくためと思ってました。テレビや映画の映像をディスプレイに映し出すのは当時の技術でも当たり前に行われていましたが、実在する物体からその特徴をプロパティやメソッドとして分析し、仮想現実でディスプレイ上に映すことは当時は画期的なことだったんです。そういった意味で、オブジェクト指向分析は当時としてはもてはやされたのでしょう。会計処理で用いられる金額や数量などのビジネスデータにオブジェクト指向分析を用いるのは見当違いで、それはオブジェクト指向以前の技術でも処理できることです。映画ターミネーター２公開により仮想現実が作り出す世界が知られるようになり、さらにGUIインターフェイスのPC OSが主流になった1990年代という時代背景で花開いたプログラミングパラダイム、それがオブジェクト指向です。
オブジェクト指向技術により、バグが少ないプログラムが書けたり、メンテンスが容易になる、というのは根拠がない論説です。むりろクラスコーディングとのは、プロパティやメンバー関数をグローバル変数、または状態として扱うので、メソッドの実行順序により、実行結果が違うことが起りえます。このことを関数型言語推進者からは、「オブジェクト指向技法には参照透過性がない」と指摘されています。データベースの利用が普及した昨今では、状態にはデータベースに保存し、プロラムではロジック演算と更新処理をデータベースに発行することにより状態制御が実現できます。プログラム自体はステートレスに実装されます。
オブジェクト指向を参照透過性のダメージを最小限にするには、プロパティの書き込をクラスの内部で行わず、クラスの外部でのみプロパティの設定を行うことが考えらます。ボタンの例では、ボタンの大きさや色などは、ボタンのメソッドではなく、外部で設定されます。ボタンの大きさを半分に変更するようなメソッドを、そのクラス内部に実装することは、参照整合性を損なうのでやめたほうがいいです。またクラスの内部関数はメソッド（手段）と呼ばれています。メソッドはその意味合いから関数というよりは抽象度が高いものと考えらます。ボタンの実装では、クリックで起動されるメソッドを定義し、クリック時の具体的な処理は外部で記述します。このようにすれば、ボタンクラスのプロパティやメソッドにアクセスしないので、参照透過性のダメージがなく、しかも実用的な実装になります。