業務システムでオブジェクト指向は必要か？
半年前に爆発的に盛り上がったネタで今更ですが、
実はオブジェクト指向ってしっくりこないんです！：気分はstatic！：エンジニアライフ
について。多態性（ポリモーフィズム）やGoFのデザインパターンなどの常識を知らない筆者が、C#でpublic staticメソッドを使えば*1インスタンス化が不要などと知ったかぶりの口調で説明したところ、コメント欄やその他のブログで爆発的に議論（多くは反論）が巻き起こったという、伝説的な内容の記事です。多くの方が既にコメントしているので、ここでは筆者の無知や態度については繰り返し言及しないことにします。ユーザー企業のIS部門という業界のピラミッド構造のかなり上の方に属する立場のSEにはこの程度の見識しか持たない人もいるのか、井の中の蛙の技術者とはこのようなものなのかという事実をあらためて世に知らしめたという意味で、（炎上した多数のコメントも含めて）非常に貴重な記事です。「システムエンジニア 生き残りの極意」ということなのですが、この業界では真面目に技術を勉強して、パフォーマンスを発揮するということが必ずしも評価や出世に結びつかないということでしょうね。熱狂的な信者の多いオブジェクト指向という微妙なテーマを扱っていることもありますが、日ごろからそうした矛盾に不満を感じている技術者というのが多いというのもこのコラムが炎上した理由なのでしょう。
ところで、｢業務システムでオブジェクト指向は不要」というのは、DBを中心にした処理しかしないシステムにおいては一理あるところがあります。このコラムの筆者が上から目線ではなくて、初心者という立場で「オブジェクト指向はしっくりこない」と質問する内容であったら、共感する読者が多かったのではないかと思います。実際伝統的な業務システムで必要なバッチ処理や帳票生成、データ入力などの単純な処理しかしないのであれば、筆者のようにクラスからインスタンスを生成して処理するというのが大げさで無駄に感じる人も多いのではないでしょうか。実際、オブジェクト指向狂信者にありがちですが、何でもかんでもDomain Modelにして、複雑なアグリゲートやらValueObjectやらを定義することで、非常にプログラミングが難しくなってしまうことだってあるのですから。要は「要件をみたす最もシンプルな実装」を心がければよいのですから、私だってCRUDしかしないシステムはTransaction Scriptで作成すると思いますし、Domain Modelを構築する場合でもFacadeパターンをつかって手続き的なサービスインターフェースをアプリケーション層に置く事は、多くのシステムでは有用だと思います。この場合サービスの実装はステートレスでインスタンスは一つあればよい（Singleton的）わけですから、筆者のstaticメソッドにすればよいという考えと大きく異なるものではありません。*2
ただし、インターフェースに対するコーディング（多態性の応用の一種）が重視されている、SpringやEJB3のユーザーには常識的なことだと思いますが、staticメソッドのみ持つUtilクラスとDIで管理されたSingletonのステートレスなサービスクラスとの違いは以下が重要です。
- サービスクラスはProxyパターン、Decoratorパターンを使ってAOPのインターセプターを仕掛けることができる
- サービスクラスはMockオブジェクトを使った単体試験の作成が容易
C#ではありませんが、少なくともJava EEの世界では上記のような理由から、staticメソッドのみのクラスで業務ロジックを実装することはありえません。
結局、｢業務システムでオブジェクト指向は不要」かどうかは要件しだいなのでなんともいえませんが（といってもオブジェクトを一つも使わないことはありえませんが）、業務ロジックを実装するクラスのメソッドを全部staticにするのはありえないというのがこの記事に対する私の見解です。SpringなどのDIコンテナーを利用することで、newによる明示的なインスタンス生成を不要にしつつも、多態性を有効に活用できるのです。DIコンテナーが業務システムと特に相性がよいのはそのようなところもあるのだと思いました。C#でもSpringの.NET版を利用することでDIを活用できるはずです。
Spring.NET - Application Framework
