# 13. System Design
________________________________________
【電子合本版】Code Complete 第2版 完全なプログラミングを目指して（上巻：第5章、第6章）  
https://bookplus.nikkei.com/atcl/catalog/05/589000/

________________________________________
## 1. システム設計

基本的な設計方針

```text
[設計の基礎]
1. 設計要素
    1. アーキテクチャ選定と方式設計（基本設計の背面上段）
    2. UI設計（基本設計の前面上段）
    3. DB定義（基本設計の背面下段）
    4. 機能仕様（基本設計の前面下段） 
2. 設計作業そのものはルーズだ
    - トライ&エラーの繰り返しだ
    - 良い設計と悪い設計の判断が難しい
    - 十分な設計を定義できない
    - 設計は妥協と優先順位によって決まる
    - 設計は非決定的でヒューリスティックだ
3. 本質的な属性と偶発的な属性を見分ける
4. ある部分の修正の影響がどこかが誰も分からなくなったとき、プロジェクトは停止する
5. 設計は複雑さをいかに下げるかという戦いだ
    1. 外部の人間から見て、明らかに見当違いの内容を守っているのは、危険な兆候の一つ
    2. 凝った設計は大抵は誤り
    3. 保守性が悪いのは良くない
    4. 疎結合になっていないのは良くない
    5. クラスが利用するクラスが多すぎると大抵は良くない
    6. 未使用のコードが放置されているのは良くない

[設計のレベル]
1. レベル1 システム全体
2. レベル2 レイヤーとサブシステム
    - サブシステム間は、最初は厳しく隔てて設計を開始して緩めるのが良い
　      - 業務ルール
        - UI
        - データアクセス
        - OSやハードウェア環境依存
3. レベル3 パッケージ内の大まかなクラス分割
    - ここまでがいわゆる外部設計、基本設計
4. レベル4 ルーチン、シグネチャの用意
5. レベル5 疑似コードおよび実装

[ヒューリスティクスなアプローチ]
- 現実の概念、業務言語と合わせる
- 抽象化されたクラスや手続きを組み合わせる
    - ここでいう抽象化とは、abstract classなどのことではなく、詳細より本質に着目する、というニュアンス
- カプセル化、情報の隠蔽、限定されたインターフェース
- 多態性の活用
- 仕様変更可能性の予測と時期尚早で後回しにする判断
- 様々なレベルでの疎結合。サブシステムレベル、クラスレベル、関数レベル
- デザインパターン採用の検討
- 高い凝集度
- クラス規約の形式化
- クラス責任の考慮
- テスト可能な設計
- DRY
- 図を書く
```

クラスの設計

```text
- ADTの推進（型は抽象的（本質的）にしましょう）
    - 実装を染み出すな
    - currentFont.size = 16より
      currentFont.SetSizeInPoints(12)
    - currentFont.attribute = currentFont | BOLD より
      currentFont.BoldOn()  
- ADT違反の例
    - なんか関連性の低いメソッドの集合になっている
　　- クラスの使用者が、そのクラスのメソッドの内部挙動を知っていることが前提になっている
    　　- 例：GetResourceは、
　　    　暗黙的にInitializeResourceを呼び出しているから呼び出さなくてよい
　　- 一部がItem型のリスト操作、一部がEmployee1つに対する操作になっている
　　  （2つの役割が1つの型に収まってしまっている）
- インターフェースや仕様書で分からない時、実装を確認するのは、アプローチとしては実は良くない
    - 正解は、作者に問い合わせる
    - 作者は、その場で回答せず仕様書を訂正して見直してもらう
- is-aよりhas-a
- クラスのメンバ変数の数もマジックナンバー（7）に従う
- 継承は、3つが限界
```