総称性は、パッケージの柔軟性を増加させる
方法論の必要性と言語実装の対立は、プライベートセクションを生み出した
パッケージは純粋に構文的なメカニズムである。モジュールは型とは異なるままである。
例外は、エラーハンドリングからエラー検知を分けるが、実行時エラーの問題の魔法の解決策は提供しない
継承のないクラスを実装するために、原則としては、タスク型を使用できることがある
ソフトウェアの分析、仕様、設計、実装、保守、および文書化に用いることの出来る完全なライフサイクル言語=オブジェクト指向言語
基本ライブラリのなかでも特に基礎的なものは「カーネル(核)ライブラリ」としてグループ化されている。
こうしたクラスを読むことは、ソフトウェアのコンポーネントの広く再利用されている利点を生かして学ぶことのきる良い方法である。
これらのコンポーネントは日々進化している
| 理論的根拠 | ソフトウェアの方法論に関するルールは対象に関するある1つの理論に基づくものでなければならい |
| 実践的根拠 | ソフトウェア方法論のルールは広範囲に渡る実践的経験による裏付けがなければならない |
| 再利用の試験 | オブジェクト指向の分野において専門家の地位を主張するためには、多様な常用の多様なオブジェクトでうまく再利用されたクラスライブラリの開発において中心的な役割を果たさなければならない |
| 絶対的な肯定 | その規則をツールか言語構造として自動的に強制することが可能かどうかを検討せよ |
| 絶対な否定 | そのメカニズムのかわりにほかのメカニズムを使う方法を示す厳密な説明が伴わなければならない |
| 助言に関する規則 | 助言的な規則を作るときには決まり文句ではなく、原則を使うこと |
| 例外を含める | 広く適用可能な指針で、例外の可能性がある指針を方法論の規則として提示する場合、その例外も規則の一部として記述しなければならない |
| 壊れているものを直すということ | もっと良いツールに切り替えることにより、その問題をなくすことが出来るかどうかを考慮せよ |
| 逆転の法則 | ルーチンがあまりにも多くのデータをやりとりするならば、ルーチンをデータの中にいれよ |
| クラス誘出の原則 | クラス誘出はクラスの提案とクラスの拒否という2つの過程である |
| クラス名の規則 | 名詞or形容詞 |
| クラス一貫性の原則 | 1つのクラスに含まれる特性はすべて1つの良く識別された抽象に関係していなければならない |
| ユースケースの原則 | 非常に経験豊富な設計チーム以外はオブジェクト指向分析および設計の道具としてユースケースを使わないこと |
| 具象的な副作用 | ターゲットが属性である代入、条件代入、あるいは生成命令、もしくはプロシージャ呼び出しが含まれているファンクションは具象的な副作用を発生させる |
| 参照透過性 | 式eの値を変えずに任意のサブ式をそのサブ式の値と置き換えることが可能な場合、式eは参照透過的である |
| コマンドとクエリの分離原則 | ファンクションは抽象的な副作用をもたらしてはならない |
| オペランド引数とオプション引数 | ルーチンへのオペランド引数はルーチンの操作対象であるオブジェクトを表し、オプション引数は操作のモードを表す |
| オペランドとオプションの見分けかた | 顧客が値を与えないときに妥当なデフォルト値を見つけることが可能な場合、引数はオプションである。また、クラスが進化する過程において、オペランド引数は変わらないが、オプションは増えたり減ったりする |
| オペランドの原則 | ルーチンの引数にオペランドのみを入れるべきで、オプションは入れるべきではない |
| 継承の「…は…んの一種である」(Is-a)の原則 | BのすべてのインスタンスはAのインスタンスとしても見ることができると何らかの方法で朱鳥できない限り、クラスBはクラスAから継承してはならない |
| 多相性の法則 | より汎用的な型のエンティティまたはデータ構造要素をより特殊な型のオブジェクトに関連づける必要が生じる可能性がある場合「…は…の一種である」と思われる関係を表すのに継承が適している |
| 継承の原則 | すべての継承の使用は許されるカテゴリの1つに属さなければならない |
