しめ鯖日記

swift, iPhoneアプリ開発, ruby on rails等のTipsや入門記事書いてます

「コーディングを支える技術」 感想

「コーディングを支える技術」を読んだ感想です。

本の概要

この本は、例外・関数・スコープ・オブジェクト等の比較的基本的な概念について詳しく書かれた本です。
機能の挙動について書くだけでなく、そういった機能はどうして言語に組み込まれたかという歴史的経緯も話してくれる本でした。
ある程度プログラミングに慣れた中級者が読むと更にプログラミングへの理解を深める事ができそうな本です。

面白かった点

例外の歴史的経緯

例外のできた経緯や各言語の実装方法を聞く事で例外の意味がより分かった気がします。

例外の生まれた経緯

例外はプログラムの見通しを良くする為に生まれました。
例外処理のなかった時は、関数がfalseを返したらエラー処理をする方式を取っていました。
しかしそれだとif文だらけだし実際の処理と例外処理が混在していてとても見難い。
それを解消する為に例外が生まれました。

Javaのthrows構文

Javaでは、そのメソッドが投げる可能性のある例外を定義時にthrows構文を使って書きます。
これは1975年の論文で主張された下の主張に沿っています。
プログラマは例外処理を忘れる、その対策として例外を囲む処理と投げる可能性のある例外を明示する必要がある」
後半の「投げる可能性のある例外を明示する」がthrowsになります。
こちらは理屈としては正しいのですが、Javaの方式では少しめんどくさいという事もあって他言語ではあまり取り入れられていません。
上記論文の「例外を囲む処理」は今でも良く使われるtry-catch構文のことです。

スレッドの競合

競合が起きる条件

スレッド間の競合が発生する条件は下の3点が揃った時のみです。
・2つの処理が変数等のリソースを共有している
・少なくとも1つの処理が変数を書き換える
・片方が一段落付く前にもう片方が割り込み処理をする可能性がある

冷静に考えるとその通りで、複数スレッドで困るのはリソースの共有部分です。
複数スレッドはとても色々な問題があると思ってましたが、上記説明を受けてスレッドが今までより分かった気がします。

競合を避ける方法

・ 共有しない
リソースを共有すると問題が起きるならメモリ空間を別に分ければ良いというのがこの方法です。 これはUNIXのプロセスにあたります。
しかしメモリ空間を共有しないという方式は少し厳しかったらしく、10年後にはメモリを共有する方式(スレッド)を機能追加しました。

・書き換えない
共有変数を書き換えないという方式です。
Scalaのval宣言のように、変数を書き換えず新しい値を取得する時は常に新しい変数に入れるという方法になります。
データベースの共通の値を使いたい時等は難しいですが、プログラミングの種類によっては有効そうな手法です。

スレッドまとめ

スレッドは上記のように色々なアプローチが取られていますが、それでもまだまだ色々な問題が出ているようです。
結局の所、色々な方式を知って都度最適なやり方を探していくしかないのではないかと思います。

「コーディングを支える技術」まとめ

冒頭にも書いたとおり、基本的な構文について理解が深められる良書でした。
自分はスレッドについて理解が深まった点がとてもよかったです。
他にも、Rubyのmix-inの問題や各言語の例外に対するアプローチ等面白い話題が多くありました。