初学者が『iOSアプリ設計パターン入門』で学習する -第１章-
私は未経験エンジニアです。
間違えた理解をしている部分もあると思いますが、一緒に学習していきましょう。
参考書
こちらの書籍を用いて学習を進めていく。iOSの設計に関して学習したい場合は、まずはこの本を購入しましょう。期間を置いて読むと理解できる部分が増えて楽しいです。お値段以上の価値アリです。
以前一読していたが、設計を学ぶ必要があるので、学習録を記録していく。
わからない単語や、脱線したりしながら、理解を進めていく。（最初読んだときは訳がわからなかった。）
本の情報 ＋ 初学者が理解に詰まる部分を立ち止まりながら、記事を記載していく。
私が特に重要だと思うことは、設計というのは手段であって、目的であってはならないと思う。
なにか課題を解決するために、「〇〇パターン」「MVC・MVVM」などを用います。
その課題を十分理解するために、今回はじっくり読んでいこうと思う。
1章 設計をするということ
昨今の開発状況
- アプリでできることが増えた
- 頻回・継続的なリリース
- アプリの大規模化
- プロジェクトの長期化
- チームでの分業
これらの状況が良い面もあれば、悪い面もある。
「関心の分離」 という概念がある。
関心の分離とは
関心の分離（かんしんのぶんり、英語: separation of concerns、SoC）とは、ソフトウェア工学においては、プログラムを関心（責任・何をしたいのか）毎に分離された構成要素で構築することである。
関心の分離を平たく言えば「コードの整理整頓」です。
関心が分離されたコードとは。
-関数やクラスが一つの関心（目的・責務・役割）に専念している。複数の関心を一つの処理に混ぜていない。
-処理に関心事以外の副作用がない。
-クラスや関数の命名が関心（目的・責務・役割）を適切に表している。
副作用の意味も理解できていない。
副作用とは
副作用について
一般的な副作用の「服薬にともなう副作用」と似ている部分はあるのか？
を参考に調べる。
副作用とは
-「本来想定している作用」とは別に発生する作用のこと
-ある機能がコンピュータの(論理的な)状態を変化させ、それ以降で得られる結果に影響を与えることをいう。代表的な例は変数への値の代入である。
ふむふむ
「本来の作用」とは何を指しているのか
-(純粋)関数における、「本来の想定作用」とは、「入力値(引数)」をもらって、「出力値(返り値)」を出す処理のことです。(純粋関数とは、副作用がない関数のことです)
「想定外の作用」とは何を指しているのか
-関数において、 「想定外の作用」とは、 関数の外部の変数の影響のこと
「状態」とは何を指しているのか
-「状態」というのは、(現実世界における)ある時間Aとある時間Bで、「変わる可能性がある値 = 変数」のことです。
記事内の一次関数の例がわかりやすかった。
「副作用」には、「状態への操作＝外部への影響」と「状態の参照＝外部からの影響」の2種類ある
なるほど、外部の変数を変更してしまうこと・外部の変数を使うことによって、変数内の値を変更してしまうことということか。
AppleはiOSアプリ開発に必要な関心事を、フレームワークに分離して提供している。
そのフレームワークに則って実装すればいいわけでもありません。
複雑な問題は、より単純な問題に切り分ける必要がある。
そこで、強い味方となるのが、設計パターン。
再現性のある問題に対する共通の解決策である。
有名なパターンには、GoFのデザインパターンがある。（２３種類）
GoFのデザインパターン
面白い！！Swiftでデザインパターンの実装例が書かれていた。
ドメイン駆動設計（DDD）これもパターンの一種。
ドメインとは
なんとなくイメージはできるが、深堀りする。
ドメインは「領域」の意味をもった言葉です。ソフトウェア開発におけるドメインは、「プログラムを適用する対象となる領域」を指します。
知識がコードに埋め込まれ、ソフトウェアとなって直接的に誰かを支援する。そこに喜びを覚えない開発者はいないでしょう。ドメイン駆動設計はまさに知識をコードへ埋め込むことを実現するのです
モデルとは現実の事象あるいは概念を抽象化した概念です。抽象は抽出して象るという言葉のとおり、現実をすべて忠実に再現しません。必要に応じて取捨選択を行います。何を取捨選択するかはドメインによります。たとえばペンはどのような性質を抽出すべきでしょうか。小説家にとってペンは道具で、文字が書けることこそが大事な性質です。一方、文房具店にとってペンは商品です。文字が書けることよりも、その値段などが重要視されます。このことが指し示すのは、対象が同じものであっても何に重きを置くかは異なるということです
→確かに、たとえ話がわかりやすい。あるモノことが、状況によって、ソフトウェアで必要となるものが変わってくるというところが大変勉強になった。イメージはできていたが、言語化できていなかった。
パターンを知るメリット
- 問題を定型化して捉える
- 解決策を客観的に比較できる
- メンバーの共通言語となる
アーキテクチャも「パターン」
- パターンを知ることができれば、アーキテクチャを知ったことになる。
→アーキテクチャはパターンの組み合わせでできているのかな？ - 各アプリの問題も、単純な問題に切り分けたときには、先人の解決策が適用できるはず。
→なるほど、数学の公式のようなものか。 - パターンにはトレードオフがある
まとめ 重要ポイント
アプリが持つ複雑な問題を
関心の分離によって
単純な問題の群として切り詰める
それが設計という行為であり
そのための武器がパターンである
レイヤーが抱える問題はさらにブレークダウンされる必要がある
関心の分離は再帰的に適用されなくてはならない
アーキテクチャーの違いは
システムを分割するレイヤーの捉え方
の違いです。その違いにフォーカスする必要がある。
良かったと思ったら、いいねやTwitterのフォローよろしくお願いいたします！
個人でアプリを作成しているので、良かったら覗いてみてください！
Discussion