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

ソフトウェア開発メモ

日々のソフトウェア設計、実装で考えている、気づいた事を書いています。それが真実か否かは保証しません。悪しからず。

スモールオブジェクトプログラミングについて〜クラスはより小さくする

はじめに

SmalltalkerのケントベックやThoughtWorksの中の人が暗に提唱し、最近いろんな識者がネットや本で語っている*1*2、バリューオブジェクト、小さな部品、小さなクラス、小粒クラス、粒度の小さいクラス、スモールオブジェクトプログラミングと言われている、ストイックなまでに小さくしたクラスを使った開発手法について長所/短所を補足、記述しました。

長所

  • 部分的な問題に分解できる。

  • 割り込みに強い(仕事中の電話から、数ヵ月毎の保守まで)。

  • 要求仕様を表現しやすい。

  • フレームワークと違って、作ったクラスを他のプロジェクトに再利用しやすい。

  • モデリング作業〜コーディング作業の行き来がしやすい。というかコーディング作業そのものが オブジェクト間の関連やメッセージパッシングを検討する作業にすり替わる。

  • クラス間の依存が減る?

  • ソースコードが簡素になる。オブジェクト指向に慣れた人にとっては読みやすい。というかこの実現方法以外にありえない。

  • 処理のコーディングレイアウト、コメントとかどうでもよくなる。そんなものやっている暇があれば即クラスに分割を検討。

  • 仕様書からコードが自動生成できる?

  • クラスがする仕事が明確になる。急に質問されてもパッと答えれるぐらいに。

  • クラスの不変性を表現しやすい。

  • 同様にクラスの状態が減ってわかりやすくなる。

  • XPライクなアジャイル開発に強い(1時間置きに客やPMが話しかけて、ちょこまか小さい方針がかわったり、要求仕様を探るためのライブコーディングするような場合)。

  • 重複コードが減る。

短所

  • O/Rマッパとの相性が悪い。

  • 高い概念構築、構成能力が必要(=オブジェクト指向分析/設計能力)。

  • 正しくクラス分割するにはオブジェクト設計へのかなりな習熟が必要(クラスの命名やメソッドも同様)。

  • ソースコードが自然とオブジェクト間のメッセージパッシング表現する事になるので、オブジェクト指向に慣れていない人にとってはソースが読みづらい?

  • パフォーマンスやメモリ使用に影響与える?

  • スモールオブジェクトプログラミングを禁止されると退職を考えてしまうw。

  • パッケージ編成を上手に行う必要がある

結論

週末書きます。