オブジェクト指向入門 第2版 原則・コンセプト の読書メモ
自分がこの本に求めること
- きれいなクラスを設計するための知識
- コードレビューの時の根拠となる知識
- 型がなく、関数ファーストな言語(ruby)だとどうするのが良いか?
外的品質要因、内的品質要因
- 外敵品質要因 ユーザが認識できる要因。使いやすさ、スピード
- 内的品質要因 モジュール性
最終的に問題になるのは外的品質要因
本書は内的品質要因の話
内的品質要因は外的品質要因を達成するための手段
外的品質要因
色々ある
- 正確さ correctness
- 頑丈さ robustness
- 拡張性 extendibility
- 設計の単純さ design simplicity
- 再利用性 reusability
- 互換性 compatibility
- 効率性 efficiency
- 可搬性 portability
- 使いやすさ ease of use
- 機能性 functionnality
- 適時性 timeliness
正確さ correctness
仕様によって定義されている通りに仕事を実行すること
- 一番大事 → 後述
- 型付け、表明で最初から正確なソフトウエアの構築を支援できる → 後述
頑丈さ robustness
異常な条件に対して適切に対応できること
- 仕様の外側の話
- あらかじめ分かっている例外は仕様の話
- 仕様外の出来事が破壊的なイベントを起こさないようにする
- 適切なエラーメッセージを出力して、ソフトウェアを終了する → 気配りのグレードダウン
- 例外処理については12章
拡張性 extendibility
仕様の変更に対するソフトウエア製品の適用のしやすさ
- 仕様は変わるもの
- 要求の変更、要求の理解の変化、アルゴリズムの変更、データ表現の変更、実装方法の変更、といった変更をサポートすることがオブジェクト指向技術の基本的な目標
- 拡張性を向上させる原則
設計の単純さ design simplicity
非集中化(decentralization)モジュールの自治性が高いほど、他のモジュールに影響を及ぼしづらい
- オブジェクト指向は、単純で非集中的な構造のシステムの設計を助ける技法
再利用性 reusability
多種多様なアプリケーションの構築に使うことができる、ソフトウエア要素の能力
- 書くべきコードが減る
- 4章で後述
互換性 compatibility
他のソフトウエア要素との組み合わせやすさ
-
周囲の世界と同調する
-
設計が同質であること、プログラム間のコミニュケーションの標準的規約が一致していること
- 標準化されたファイル形式 Unixではテキストファイルは単純な文字の並び
- 標準化されたデータ構造 Lispではデータはすべて二分木
- 標準化されたUI
-
ソフトウエアが操作するすべての重要なエンティティに対して、標準化されたプロトコルを定義する
-
抽象データ型については6章
効率性 efficiency
リソースをできる限り必要としない能力
- 抽象博士とマイクロセカンド氏 → どっちを取るべき？
- 正しく無いならば速さを気にするな → 正確性 >>> 実行速度
- 効率性と拡張、再利用性のバランス
- ソフトウエアの構築が難しいのは、多くの異なる要求を考慮する必要があるから
-
コンピュータの処理能力の進歩によって顕著に現れるのは、悪いアルゴリズムに対する良いアルゴリズムの優位性が際立つこと
- O(n) とO(n^2)だとCPUパワーが2倍になっても伸びが違う
-
実行性能の制約が正確さを損なう原因になる
- 24時間かかる明日の天気予報は使えない
- 本書ではあまり明示的には触れないが、オブジェクト指向的解決方法を紹介する度に、それが効率的でもあることを保証する
可搬性 portability
多様なハードウェア、ソフトウエア環境への移植のしやすさ
使いやすさ ease of use
学習しやすさ、操作、インストール、監視の容易さ
- 上級者を邪魔せず、入門者に適切な指示と説明
- 構造の単純さ
- オブジェクト指向はエンドユーザを助ける新しい強力なインターフェースのアイデアを生み出す
- 成功したシステムは想定とは異なる人々に使われる
- あるグループに特化したシステムは、他のグループには受け入れづらい
- そのユーザのことを知っている気になるな。あなたは知らない
機能性 functionnality
そのシステムが提供できる機能の範囲
どこまで機能があれば充分か？
忍び寄る機能主義 creeping featurism → より機能を求める圧力
- 簡単な問題 : 追加により使いやすさ、一貫性が損なわれる
- 難しい問題 : 機能追加に集中して、他の品質要因を忘れる
品質が充分に高まってから機能追加するのが理想
→ クラスタモデル(後述)を使うと良い
適時性 timeliness
必要とする or 必要とする前にソフトウエアをリリースできること
その他
- 実証性 : 不具合検知、不具合からエラーの辿りやすさ、受け入れテストしやすさ
- 統合性 : 認証されていないアクセスや修正からシステムを守る能力
- 経済性 : 適時性と対。予算以下でシステムを完成させられるか
品質のトレードオフ
- 経済性と機能性
- 効率性と可搬性、再利用性
- 適時性と拡張性
→荒ぶる四天王とおんなじ話
- 選択肢を検討する時間をとらずに感覚で決めてない？
- 基準を明確にして、意識的に選択すべき
- 正確さはトレードオフの材料たりえない → ソフトウエアがその機能を遂行しなければ他のことを考えても無駄
特に重要なことがら
正確さと頑丈さをまとめて : 信頼性
拡張性と再利用性をまとめて : モジュール性
→ オブジェクト指向は上記2つを改善する
しかし、万能薬ではない
問題に対処するのを助けることは問題を解決するのと同じでは無い
保守について
コストの70%が保守
- 41.8% : ユーザ要求の変更
- 17.6% : データフォーマットの変更
- 12.4% : 緊急対応
- 9% : 定期的なデバッグ
ほとんどがユーザ要求の変更
拡張性を考慮するの大事だよ！
データフォーマットの変更
システムの多くの部分がデータの構造に依存する問題
郵便番号の桁増、2000年問題
抽象データ型 → 6章を参照
まとめ
- ソフトウエア工学の目的 → 品質の高いソフトウエアを作る方法の探求
- ソフトウエアの品質は、複数の目標のバランスを基準に判断する
- 最終的に重要なのは外的品質要因だけど、それを実現するには内的品質要因が大事
- よりよい開発手法を実現するのに大事なのは 信頼性、 モジュール性 で、それはオブジェクト指向の守備範囲
- ソフトウエアの保守コストは高い
- 変更を実装するのが困難
- 操作するデータ構造にプログラムが依存しすぎている