読者です 読者をやめる 読者になる 読者になる

methaneのブログ

このブログに乗せているサンプルコードはすべてNYSLです。

僕にとってのOOP

program

http://d.hatena.ne.jp/w_o/20060619#p4 を読んで、OOP擁護派として意見を重ねる。

僕にとっては、プログラムの構造化*1だのOOPだのAOPだのは、全てある一つの目的を達成するための手段でしかない。*2
その目的とは、関心事の分離だ。Aについて書いてるとき(or読んでるとき)は、Aの事だけを考えたい、A以外への影響をでっきるだけ分離したい。

モジュールってのは、たいてい人間が認識できる機能毎に分けられていて、そのモジュールはその機能という関心事を分離する。
C++的classは、ある関心事に関連したデータと関数をまとめ、その他と分離する。
継承は、一般的関心事と、一般的じゃない関心事を分離する。
AOPは、今まではプログラム全体に散らばり埋もれていた横断的な関心事を分離する。

関心事を分離することで、Aを修正しようと思って、気づかずBに副作用を出すという事が防げる。これは、大幅にプログラマの労力を削減する。まさに、プログラマが楽をするための技術。

ソフトウェアの規模をNとしたとき、ソフトウェアの複雑度は、関心事を分離できない場合はO(N**2)〜O(N!)になり、関心事が分離できるとO(1)〜O(logN)程度で済む*3。大量の要素が絡み合う大規模アプリケーションを構築するときには、プログラムの構造化すら出来ないプログラマは邪魔で、できるだけOOPができるプログラマに任せる必要がある。

それとは別に、アルゴリズムだとかハードウェアとの協調だとかが技術的に難しい部分では、OOPは大して役に立たない。組み込み屋がドライバを書くときにOOPを使えるかどうかは大した違いにならない。*4

*1:プログラムのモジュール化の意。gotoを使わないだとか、入り口と出口は1個ずつという構造化プログラミングとは無関係

*2:文としての切れ味を良くするための表現です。本当にそれだけって訳じゃ有りません。

*3:根拠なし

*4:ドライバモデルを設計するときには、OOPが判ってる人間の方がセンスの良い設計ができるだろうけどね