ウェブサービスにとってのオブジェクト指向とは

ウェブサイトを作る身としては、パフォーマンスというのは常に気を使うところです。

perlで書いてたけどFastCGIとかサーバに無いからphpを覚えて書き直したり（上のサイトは専用サーバですが）、とりあえずApacheでgzipで転送するようにしたり（でも携帯は対応していなかったり。パケット代搾取のためだな）、キャッシュコントローラ入れてみたり。スクリプトをバイトコードに落とすようなアドオン入れてみたり。もういっそのことapacheのアドオン書いちゃったり。

それぐらいパフォーマンスには世のウェブ系プログラマは気を使っていると思います。それは当然のことで、なぜならパフォーマンスはお金になるからです。
基本的にウェブサービスを運営するにはどうしたってサーバ代と人件費はかかります。そしてアクセス数の多い人気サイトになればなるほど、サーバ代（通信費含む）の比率は増していきます。

大体において1リクエストにかかる時間なんていうのは1秒もかかることはまず無いわけで、ローカルで実行する分にはどーでもいいぐらいの時間です。しかし秒間数百リクエストぐらい捌く（これぐらいの数字にはすぐなるでしょう）となると、話は変わってくるわけで、最適化されているか否かで必要なサーバの台数や回線がガラッと変わってきます。

ってなわけでパフォーマンスはお金になる。そこで思うのはオブジェクト指向です。
オブジェクト指向が流行り始めたころ（〜90年代頭ぐらいですかね。よく覚えてませんが）、オブジェクト指向は遅いって言われてました。まぁ何かをwrapするってことはオーバーヘッドがあって当然なのですが。
それでもコンピュータ自体が高性能化してくるとオブジェクト指向のコストぐらい大したことないって場合が増えました。まぁなんだかんだ言っても便利ですからね。オブジェクト指向。

でも私は高校生のころ弾幕シューティングを作るときは画面上のキャラクタをただの構造体として扱いました。画面が敵と弾で埋め尽くされるほどにキャラクタクラスを生成（確か数千）する必要があり、またこれが生成と開放を毎フレームゴリゴリしないと駄目なので結構重かったのです。しかも毎フレームの移動を行うメソッドなどはポリモルフィズムも使ってる訳ですし。構造体の配列を事前にプール（+関数ポインタ）して使うほうが圧倒的に軽かったのです。
それでもゲームのタスクシステムやらなんやらはオブジェクト指向の恩恵を受けまくりでしたが。

で、こういう経験から、オブジェクト指向をウェブサービスに使うのってどうなんだろ？って思ったりするんです。昨今はウェブで使われる言語もそれに関連するフレームワークもオブジェクト指向を根底において設計されています。こういうのってプロトタイプを作る分にはいいけれど、大規模な本番用としては駄目じゃないですかね。オーバーヘッド的に。
もちろんドッグイヤーといわれる（古い）ウェブの世界では開発効率を重視してライバルに先行して製品をデプロイするのが重要、という考え方もありますが・・。

後はフレームワーク自体が大きくて、読み込みと起動に時間がかかるという話も。Ruby on Railsが出始めたとき、ウェブサーバがrailsに対応してるとかしてないとかいう話を聞いて不思議に思っていました。railsってライブラリ+コードジェネレータみたいなものなんじゃないの？なんでサーバが対応する必要があるんだ？rubyが入ってりゃいいんでないの？と。
これは後で分かった話なのですが、まぁ実際CGIとして動かせば動くんですよね。クソみたいに重いだけで。それぐらいRoRは巨大ってことでしょう（別にこれはRoRへの批難ではないです）。巨大になるだけの意味があるフレームワークとは思っています。

phpだと、smartyとかわりと便利ですが、アレもでかいので、自分でいくつかヘルパ関数書いてテンプレート自体はピュアphpにしちゃうとかありがちです。cakePHPはこの辺の考えをRoRから受け継いでいますね。

なんだかダラダラ書きましたが、2chでなくてもパフォーマンスはみんな気にしてるってこってす。「じゃあ私はウェブプログラマー!」って人が居るのか居ないのか知りませんが、居たらお金になる話なんで覚えておきましょう。あと、「（略）ウェブデザイナー!」な人も同様。HTTPはTCP/IPの上位プロトコルで、ソケット接続に多大な負荷がかかる。故にデプロイするバージョンだとCSSは纏めておいた方が負荷が減る、とか、そういった知識はあるに越したことはないです（もっと基本的なところだとホワイトスペース除去とか）。そこまでやる必要がない場合も多いとは思いますが・・