# Clean Architecture　第II部　構成要素から始めよ：プログラミングパラダイム　読書会#3

###### tags `book`

## 概要
|項目|内容|
|-|-|
|開催日|2021/02/14|
|開始時間|11:00|
|終了時間|13:15|
|メンバー|nyx,niro|

***

## 第II部　構成要素から始めよ：プログラミングパラダイム

### 感想・気づき・疑問

#### -
P47
>ソフトウェアアーキテクチャはコードから始まる。
構造とか設計書みたいなものから始まると思っていたんだけどコードから始まると書いてあってびっくり
著者は、構造ととコードを同じものとみなしているととらえられる。

P47
>プログラムが単なるデータ
?そこまで到達できていない。
バイナリまで落とし込んだらデータになるよねという話かな？

P47
>彼の使用していた言語はバイナリ
衝撃。

プログラミングパラダイムの革命。
-> パラダイムとはプログラミングの書き方。
　パラダイムはどのプログラミング構造を使うか、いつ使うべきか教えてくれる。

P47
>彼女が「コンパイラ」という言葉を生み出したのだ。
女性(Grace Hopper)初であったことに驚き。

P47
パラダイムは大別して３つ。**どれも似ているところがない**

***

## 第3章 パラダイムの概要

### 感想・気づき・疑問

#### -

- 構造化プログラミング
- オブジェクト指向プログラミング
- 関数型プログラミング

***

#### 構造化プログラミング

>Edsger Wybe Dijkstraが発案

制限のないジャンプ(go to 文)は有害
-> 代わりに(if/then/else), (do/while/until)を使う

構造化プログラミングは、直接的な制御の移行に制限を課すものである

無秩序になることを防ぐ。
JUMPを何行に飛ぶとかを直接的に書くことをやめた。

***

#### オブジェクト指向プログラミング

関数呼び出しのスタックフレームをヒープに移動できる
-> 関数が返ってきた後も関数内で宣言した変数を存在し続ける事ができる

オブジェクト指向プログラミングは間接的な制御の移行に制限を課すものである

ネスト構造を表現できるようになった。
何かのまとまり(データと振る舞い)に対して操作すること

***

#### 関数型プログラミング
発見は新しいが、導入は一番最後だった。

P50
ラムダ計算の基本的な概念は不変性（シンボルの値が変化しない）
-> 関数型言語には代入文がない（実際には変数の値を変更する手段は用意されている関数型言語も多いが、その手段は**厳しく制限されている**）

関数型

関数型プログラミングは代入に規律を課すものである

代入を制限するとで何が良いかわからない。
何かメリットはあるんでしょうか？
何が入っているかわからなくなったりして混乱する状態を回避するための施策。
const val

***

#### 考えるべきこと

P51
>パラダイムは、**何をすべきか**を伝えるというよりも、**何をすべきでない**かを伝えている。

P51
>3つのパラダイム以は、ーーーこれら以外には存在しないという証拠
>何十年も追加されていない

構造化プログラミング         ->直接的な制御をすべきでない
オブジェクト指向プログラミング ->一つの関数の中で複数の処理をすべきでない。
関数型プログラミング         ->変数を使うべきではない。再代入をすべきでない。

メモリの消費は上がっている
そのため、関数型言語の導入は遅れた。

***

#### まとめ
P51
>アーキテクチャの**境界**を超えるための仕組みとしてポリモーフィズムを使う

境界とは？

P51
>データの配置やアクセスに規律を課すために、関数型プログラムを使う

P51
>モジュールのアルゴリズムの基盤として、構造化プログラミングを使う。

>アーキテクチャの3つの大きな関心事と対応していることに注目してほしい
「コンポーネントの分離」「データ管理」「機能」

どれがどれと対応しているのか？
「コンポーネントの分離」->ポリモーフィズム？
「データ管理」->関数型言語？
「機能」->構造化プログラミング？

上は共存するのか？
->個人的には共存する
レイヤーが違うのか？
目的に合わせて使い分ければいい

Function<Integer,String> toString -> i-> String.valueOf(i);
String value= toString(1).apply();

interface Lambda(){
  public String sum(Pair pair); 
}

並列処理を行うためにObject指向プログラムにも導入されている。
マルチパラダイム言語となってきている。

***

## ふりかえり

### YWT
#### Y: やったこと
- 第3章 パラダイムの概要を読んだ
#### W: わかったこと
- プログラミングのパラダイムには大別して３種類あって、それぞれ以下の制限・規律を課している。
- 構造化プログラミング ->直接的な制御をすべきでない
- オブジェクト指向プログラミング ->一つの関数の中で複数の処理をすべきでない。
- 関数型プログラミング ->変数を使うべきではない。再代入をすべきでない。
- パラダイムはコードに秩序を与える。

#### T: 次にやること
- 第４章 構造化プログラミング

***

### KPT
#### Keep
- 事前に書いておくことは時短になり有効
- 事前準備パライムの導入
- 進行の秩序が生まれた。
- 分からないことは分からないので、文章から読み取れることの範囲で十分わかることを分かっていく姿勢
#### Probrem
- アーキテクチャの**境界**などの概念を現状放置している状態。
#### Try
- 疑問点のリスト化をしてすぐにアクセスして解消できるような仕組み

***

### Fun-Done-Leanrn
#### Fun:
- a

#### Done:
- a

#### Learn:
- a

速度
満足度
進め方