「デザインパターンとともに学ぶオブジェクト指向のこころ」についての気になった部分の抜粋
オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)
- 作者: アラン・シャロウェイ,ジェームズ・R・トロット,村上雅章
- 出版社/メーカー: 丸善出版
- 発売日: 2014/03/11
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (4件) を見る
まえがき
オブジェクト指向の謳い文句
- "現実世界をそのままクラスにできる" という宣伝文句も最近では目にする機会は減った
- 差分プログラミング という言葉も目にすることがなくなった
システムは完成しない
- ほとんどのシステムは本番稼働後も保守開発が続けられる
- システムは捨てられる時が来るまでずっと変化し続ける
要求の追加や変更が発生したときに・・・
- システム全体を見直して影響する部分を探したり、既存機能に悪影響が無いか確認しなければならない場合は莫大な保守コストがかかる
- 開発時点で詳細が見えていない部分をカプセル化しておくことでシステム変更での影響範囲を局所化できる
- 追加変更がおきても新規クラスを作成し、システムにプラグインするだけで既存部分を丸ごと手つかずに残せる
- すなわち「再利用」できるようになる
- 「システムの変化を特定部分に封じ込めて、そこ以外を再利用する」ということがクローズアップされるようになった
オブジェクト指向パラダイム
機能分解
- ある問題を小さな（手続き的な）機能にブレークダウンすることで、その問題を構成する機能要素の洗い出しをすることを機能分解と呼ぶ
- 機能分解には大きな落とし穴がある
- （手続き的な）機能を適切な順序で呼び出す「メイン」プログラムが必要になる。
- メインプログラムにはすべてを正しく動作させる、すなわち機能の組み合わせと呼び出し順序を制御するあまりに大きな責任が課せられる
- 結果的にソースコードは複雑になる
- 機能分解に対してどうするのか
- 部分機能に対してそれ自体の振舞いに関する責任を持たせ実行指示を行うだけであと任せておく。とすると話は簡単になる
- これが委譲（delegation）という考え方
- 多くのバグはソースコードの変更によって生み出される
- あまりに多くのものごとを同時に行うプログラムはちょっとした変更でおかしくなる
要求における問題
- （筆者が）長いソフトウェア開発経験で学んだことは、要求は常に変化するということ
- 要求が変化する理由
- 開発者とのディスカッションを行うたびにユーザがソフトウェアの新たな可能性に気づき自らのニーズを変更する
- ソフトウェア開発の進展に伴い、問題領域に対する理解が深まり開発者側の考え方が変わってくる
- 初期分析を完璧にやり終えても要求は変化する
- 要求の変化に愚痴をこぼすよりも、開発プロセスを変え、変化に対して効率的に取り組めるようにするべき
変化に対応する（機能分解を用いた場合）
- 機能分解を用いると低い凝集度と高い結合度のコードが生まれやすい
- 凝集度が低いクラスは関係のない作業が多数詰め込まれたクラスで、そのソースコードは混乱を引き起こす
- システム内のほとんどのクラスと絡み合うクラスをゴッドオブジェクトと呼ぶ
- たぶんそのクラスを理解できるのは神様だけ
- 多くのデータを使用するような機能は要求の変更にさらされやすい
- 好ましくない副作用が引き起こされる可能性も増加する
- バグの中でもたちの悪いものの温床になる危険性がある
