積読消化２ iOSアプリ設計パターン ２章 設計にパターンを適用する前に
問題領域、責務、モジュール
切り分けられた責務の境界を守る
- データの変化に応じてViewの内容を更新
- ユーザーインタラクションへの反応
- レイアウト管理
- 他のオブジェクトとの連携
何よりも大事なこと
→責務を明確にイメージできる名前づけ
正しい名前に向き合う
API（メソッド、型、変数など、プログラムで使われるすべてのインターフェィス）が守るべき３つの原則
- 使い道を明確に
- 短い名前よりも明確であることが重要
- ドキュメントコメントを書く
これを行うことで
- 論理の破綻
- 隠れている役割
- 所属のおかしさ
を浮かび上がらせ、設計の改善につなげられます。
アジャイル開発と設計の原則
アジャイル（俊敏）開発とは
設計の原則とは
SOLID原則
コードの臭さ
- 硬さ 変更しにくいシステム。１つの変更によってシステムの他の部分に影響が及び、多くの変更を余儀なくされるようなソフトウェア
- もろさ １つの変更によって、その変更とは概念的に関連のない箇所まで壊れてしまうようなソフトウェア
- 移植性のなさ 他のシステムでも再利用できる部分をモジュールとして切り離すことが困難なソフトウェア
- 扱いにくさ 正しいことをするよりも、誤ったことをするほうが容易なソフトウェア
- 不必要な繰り返し 同じような構造を繰り返し含み、抽象化してまとめられる部分がまとまってないソフトウェア
- 不必要な複雑さ 本質的な意味を持たない構造を内包しているようなソフトウェア
- 不透明さ 読みにくく、わかりにくい。その意図がうまく伝わってこないソフトウェア
原則を使うとき、使わないとき
オーバーエンジニアリングは悪
- KISS(keep, it, simple, small) 簡潔に単純にしておけ
- YAGNI(You Are not Going to Need It) どうせ必要にならないよ
設計の原則を適用するには、適切な設計の判断のために変更可能性がどこにあるか知らなくてはならない
イテーレティブな設計に向けて
what is イテレーティブ
→MVPな開発
やることは１つ → リファクタリング
注意して欲しいのは、
リファクタリング ≠ 作り直し
であること。
そのためにはテストが必要である。
設計はテストのしやすさを前提に進める必要がある
実際のリファクタリングは常に少しづつ行うものであり、テストのしやすさは早く作るためにも重要なことなのです。
直感に反するかもしれませんが、テストの役割はむしろ実装を早くすることにあります。
また、速度の向上に貢献しないテストは価値がないと言っても良いほどです。
TDDのプラクティス
- 開発者の実装を助けるためのテスト → チェッキング
- 品質保証のためのテスト → テスティング
テストの最小単位は不安
テストのしやすさ
最速のテストは型付け
良い設計とは
→諸々の支援を受けやすく、そして十分に単純な設計
パターンを使うのはいつか？
「コードの臭い」を感じたら、原則を使って原因を突き止めます。
小さな歩幅でリファクタリングを行ううちに、全体の構造がより洗練されていきます。
すると、そこに新たなパターンの適用の余地が見えてくる。
パターンとは、ショートカットのようなものである。
