- gotoの追放
- gotoを追放して作られたのが構造化プログラミング
- 機能ごとに関数で分けましょう
- 機能を呼び出したら元のところに戻るということができる
- 変数にスコープの概念ができる
- 普通にプログラミングしていたらgotoは出て来ない
- forの追放
- 正確はループカウンタの追放
- foreachで「集合の全て」に関して処理ができる
- mapメソッドで集合の全てに処理をした結果を集合で返すことができる
- ループカウンタを追放することで、処理の最初と終わりの境界値を気にしないでも良くなる
- 繰り返しの追放
- forをforeachに変えるとかじゃなくてそもそもループの構文から追い出すという発想
- 一行ずつ処理をするという発想を追い出す
- SQLは繰り返しの処理をしてる感じじゃない
- UPDATEには順番さえ存在しない
- 検索結果でさえも並び替えを指定しない限り並びを保証しない
- 連想配列によるスキャンの追放
- 裏では何かしらの繰り返し処理を行ってるんだけど、プロウグラマーからは繰り返しによるスキャン処理をみせないようにしているのが連想配列
- プログラマーが意識してないだけで、裏では効率の良いスキャンが行われているはず
- 再帰による繰り返しの追放
- 一行ずつ処理をするにしても再帰で繰り返す方法がある
- 関数呼び出しがネストするのでスタックがあふれることがある
- 再帰が効くのはただの繰り返しじゃなくてツリー構造を処理するようなデータ構造としてもネストしているケースだと思う
- ただしコンパイラの最適化で再帰がループに変換されるケースもあるらしいので、今後は再帰だけでもいいのかも
- ifの追放
- ポリモーフィズムによるifの追放
- 局所的には同じ処理でありながら、別のクラスが呼ばれることで同じメソッドを呼んでも別の機能が呼ばれる嬉しさ
- ただしクラスをnewする段階で何らかのif文あるよね
- ビジネルールにifがあるならプログラム上のロジックにもifがある事自体おかしくはない
- 声にだして読み上げるルールが非エンジニアに伝わるならそれ以上の抽象化は要らない
- ポリモーフィズムによるifの追放
- 副作用の追放
- オブジェクト指向に対する関数型の売りとして副作用の追放というのがある。
- ただ古いプログラムも好き好んで変数の寿命を長くしてるわけではない
- キャッシュ的なものを長く保存したいだけ
- キャッシュとメモリリークの違いって理屈の上では差がない
- 散らかってるのを指摘すると「いやこれはすぐに手がとどく範囲に置いてるのです」という反論に近い
