手作りネットプロトコル工房コミュのオブジェクト指向と哲学の違い

okt様
(前略)... よって、何をモノとして認知するかが視点によって異なり、さらに、それをどのように分類するかも異なります。

これについては、どのようにモノを認知すればO.K.であるか、
また、どのように分類すればO.K.であるか、についての絶対的な基準ないですが、うまくクラスを作成するコツを経験者はそれぞれ知っていると思います。 (後略)

こういう質問がありました。 返答を書いていたのですが、返答が大きくなってしまいましたので、一つのトピックとして作成しました。

--------------

オブジェクト指向が哲学と大きく違うところは、プログラミングでは、全世界を表現するほど厳密じゃなくていいことでは無いかと思います。

あたりまえですが、素粒子クラス→原子クラス→分子クラス→...→有機物クラス→...→イヌクラス とか書かないといけないなんて馬鹿な話は無い訳ですが、それは単に必要が無いからだと思います。

したがって、コーディングするに当たっては、最低限必要な抽象化だけをすればいいのではないかと僕は思います。

ほんの数年ほど前はリファクタリングするためのツールが無かったので、作り込んだ後で大規模な構造変更を行うのは、すごく大変でした。 作りこむ前に起こりうる問題をじっくりと予想し抽象化してから作る必要があったためとても時間が掛かりました。

でも、今はEclipseの様な本格的なリファクタリングツールがあるため、作りこんだ後でも大規模な構造変更を気軽に行えるようになりました。 何も考えずに作っていいような気がします。

例えば(月並みなたとえで恐縮なのですが)プログラムの中にアリが居ないなら、イヌクラスから作ればいいと思います。極端な話、ポチしかいないなら、ポチクラスだけでいいのだと思います。クロが出たところでイヌクラスを、ネコが出たところで哺乳類クラスを、アリ出たところで 昆虫・動物クラスを作ればよいと思います。

また、正規化すると多かれ少なかれ実行時の効率は落ちます。

きちんと正規化するのは当たり前として、どこまでが絶対に必要な正規化なのかを見極めたうえで、『途中でやめる』のが大切なんだと思います。

僕は、この話を思い浮かべる時、リレーショナルデータベース設計者の間でよく「正規化をどこでやめるのかがキモ!」と言われていたのを思い出します。


＞よって、何をモノとして認知するかが視点によって異なり、
さらに、それをどのように分類するかも異なります。


さっきの話ではないですが、正規化しようとすればいくらでも無限に正規化できますし、視点によっていくらでも正規化の方法があります。でも、結局プログラミングは哲学じゃなくて、しょせんはドカタ作業の「プログラミング」なので、案件と仕様に一番都合がいい正規化を選べばいいのではないか、というような気が、僕はしています。

都合がいい、というのは、例えば、

・後で改造しやすい
・バグの入り込む余地が少ない
・プログラムが小さい → 見通しがよくなってバグ減
・コードに似て非なる重複が出現しない
・既存コードを再利用しやすい
・正規化しないでいい (その1. 後で絶対に変更しなくてよいと知っているので、正規化せず開発時間を節約)
・正規化しないでいい (その２. 後で抽象化が難しい変更が来るのを知っているので敢えて正規化しないで時間を節約→重複コードが出たところで初めて正規化)
・その他その他...

ということではないでしょうか。

分類の方法によって色々なメリット・デメリットのトレードオフが起こるので、その中で一番デメリットが少なくて、なおかつ絶対にはずせないメリットを踏まえている正規化を選択するのがいいような気がします。



あと、イヌでもあるのだが黒いとか、ネコでもあるのだが赤いとかいったように、複数の分類の視点がある場合は、クラスではなくてインターフェースを使えばいいのではないかな、と僕は思います。

インターフェースは、共通のスーパークラスを持たなくていいので複数の分類方法をまたいで抽象化できるからです。

勿論、状況によっては、インターフェースを使わないでプロパティを使って実装するというのもありだと思います。 その場合は インターフェースでしか出来ないこと、プロパティでしか出来ないことを比べて いちばん つごうがいい方法を選ぶしかないと思います。

また、実際に問題が起こってから正規化する、というのも意外と大切かもしれません。

将来何が起こるか経験して知っている時は、沢山考えればそれ相応によい結果が出せます。ですが、知らない時は考えても「心配し過ぎ症候群」「石橋を叩いて壊す」になる場合がほとんどだからです。すごい時間をかけて正規化しても、全然違う切り口の変更を迫られて結局最初っから作り直し、っていうのはなんだか良くあるパターンです。


＞余談．性質の違うものを同じとみなして、スーパークラスで
　　　IF文というPGをみると、、、（T-T

視点１
Visitorパターンっていうパターンがありますが、Visitorパターンこそがこれを避ける方法の一つではないか、と僕は思うのです。

ですが、あそこまで ゴリゴリに正規化してしまうと if文は１個もなくなるかわりに、結構読みづらいのではないか、と僕は思うのです。

また、結局は『書く場所の問題』でしかない、という冷めた見方もあると思います。 Visitorパターンで書けば 全ての処理が一つのクラスに集約されますが、使わなければ各クラスに処理が分散します。 状況によってそのほうが読みやすい場合もあると思います。

視点２
コンストラクタを共通化したいときなんか、僕はスーパークラスでIF文を書く時があります。 邪道ですが、僕は サブクラスでコンストラクタの仕事を意識させたくない時に、例外的に使います。

視点３
ほとんどのプログラマはそこまで考えて無いのではないか、という視点。 だからそんなこと以前にプログラムはグチャグチャである、という視点。

視点４
ほとんどのプログラマは開発だけして退散し、だから何故かプログラムをメンテナンスする人だけがそういう苦労を背負い込むのではないかという視点。

視点５
... 以下省略

P.S.
僕は、結構メンテナンスの仕事が長かったのです。だからグチも多くなるって言うもんです。

はーぁ (´Д`)

だから 汚いプログラムを読むのはプロ級の腕前です。