初学者が『iOSアプリ設計パターン入門』で学習する -第2章-
私は未経験エンジニアです。
間違えた理解をしている部分もあると思いますが、一緒に学習していきましょう。
参考書
こちらの書籍を用いて学習を進めていく。iOSの設計に関して学習したい場合は、まずはこの本を購入しましょう。期間を置いて読むと理解できる部分が増えて楽しいです。お値段以上の価値アリです。
以前一読していたが、これから設計を学ぶ必要があるので、学習録を記録していく。
わからない単語や文脈などがあれば、脱線したりしながら、理解を進めていく。（最初読んだときは訳がわからなかった。）
本の情報 ＋ 初学者が理解に詰まる部分を立ち止まりながら、記事を記載していく。
第２章 設計にパターンを適用する前に
-
問題が適切に切り分けられていなければ、パターンも使えない。
→
では、 -
問題はどのように切り分ける？
-
パターンはどのように使う？
→
− 設計のプロセスを整理する必要がある。 -
解決すべき問題の領域は責務という言葉で表す
-
ひとまとまりの責務の置き場としてモジュールが用意されている。
責務がまとまっていて、モジュール同士で責務が分かれている
この状態が理想。
- 設計が正しくあり続けるには、責務の境界を理解し、改修に際して崩さないようにしなければならない。
→本書のDate型 Calenar型の例えがわかりやすかった。Swiftで用意されている型には、それぞれの責務があって、まずはそこを理解する必要があるということ。extentionで拡張させて、別の型を用いるときは注意しよう。
もっと詳しく知りたい方は、どぞ
extension Dateで日付計算をしてはいけない
こちらの記事が参考になるとおもいます。
簡単に結論だけ伝えると、
Date はいかなるカレンダーやタイムゾーンからも独立した、ある時間軸上の一点の表現です。単なる unixtime のラッパーだと思ったほうがよいです。1
という責務があるからです。その事による問題が記事に記載されています。
名前付け
-
何より重要なのが、責務を明確にイメージできる名前付けです。モジュールに限ったことではなく、メソッドや変数においても責務をイメージできない名前をつけた途端に設計は腐敗する。
-
正しい名前に向きあう。名前付けは長くてもいいから明確に。
→もし長過ぎる場合は、メソッドの役割が大き過ぎる。適切な粒度で抽象化できていない。
例
命名規則について書かれている 参考になった。
プロトコルの命名に関しても、曖昧な部分が多かったので、大変参考になりました。
名前を決めるときには「"それが何か"を説明するプロトコル」なのか「"何ができる"という能力を表すプロトコル」なのかという文脈づけた命名を意識をしたい
→すごく重要だと感じた。
- 何かを 説明するプロトコル → 「-able」か「-ible」
- 何ができる という能力を表すプロトコル → 名詞
-
原則は、責務の分割単位が適切かどうかを検証するため物差しです。
-
SOLID原則＋臭いを 取り除いて、高凝集、疎結合「実現するために、設計の原則がある。
臭いとは
本書とは違った説明であるが、参考になった記事がありました。
コメントは悪い臭いではなくむしろいい香り。問題としているのは、コメントが消臭剤として使われているケースがあるということ
→消臭剤というのは面白い例えだ。臭いの原因は消えていないけど、ごまかしている状況みたいなものか。
コメントしているときは、臭いの原因がわかっているけど、臭いままになっていると思っておこう。
- アジャイルのプラクティスには、KISS・YAGNIがある。
KISS・YAGNIについて
KISS
KISS の原則 (英: KISS principle) とは、「Keep it simple stupid.」（シンプルで愚鈍にする）、もしくは「Keep it simple, stupid.」（シンプルにしておけ！この間抜け）、もしくは「Keep it short and simple.」（簡潔に単純にしておけ）という内容の、1960年代の米国海軍において言われた、経験的な原理・原則[1]の略語。その意味するところは、設計の単純性（簡潔性）は成功への鍵だということと、不必要な複雑性は避けるべきだ、ということである。
→ソフトウェアだけで使われている言葉じゃないんだー。
YAGNI
"You ain't gonna need it"[1]、縮めて YAGNI とは、機能は実際に必要となるまでは追加しないのがよいとする、エクストリーム・プログラミングにおける原則である。
→今後必要になるかも？ぐらいだったら追加しないほうがよいな。時間を無駄にしてしまう。絶対に必要なことに時間を費やそう。
-
適切な設計の判断のためには、変更可能性がどこにあるか知らなくてはならない。
→私の場合は、Repositoryパターンで、Realmを実装していたけど、実際Realmからローカルのデータベースの管理を変更するかと言われるとわからない。でも、これから先ローカルのデータベース管理がAppleのフレームワークで簡単になったりする未来があれば、Repositoryパターンで実装した恩恵を受けるのか。 -
設計を状況に応じて少しずつ進化させていくイテレーティブな者だと捉える。
-
リファクタリング＝作り直しではない。書き換えは前後で既存機能が壊れていないことを確かめながら行う。そのためにテストが必要
-
設計はテストのしやすさを前提に進める。
-
リファクタリングは少しずつ行うもの。テストのしやすさは早く作るため。
→テストを行うと、結構時間を要してしまうので、おろそかになりがちであったが、テストによって現在・未来も恩恵を受ける。 -
テストの最小単位は「不安」 という言葉で表す。
例
参考記事。
上の記事に、最初の不安を感じる点、凄く共感した。確かにif文 、for文 の両方を含めた関数を実装するとき、「不安が強くなる」。そのときにテストコードを書けばよいのか。「不安」＝「テストコード」
テストのしやすさ
- 入力と出力が明確で、副作用が少ない
- 複雑な内部状態に依存しない
- 疎結合。処理に影響のあるオブジェクトは抽象的なインターフェイスとして表現されており、モックやスタブに差し替え可能。
複雑な内部状態に依存しないとは？
説明記事
記事を書いてみました。 参考までにどうぞ。
「コードがデザインパターンに回帰していく。」
コードを修正していく過程で、その最終形にパターンを見出す。
間違いなどがあれば、コメントいただけると大変うれしいです。
良かったと思ったら、いいねやTwitterのフォローよろしくお願いいたします！
個人でアプリを作成しているので、良かったら覗いてみてください！
Discussion