『Clean Architecture 達人に学ぶソフトウェアの構造と設計』/Errata
第6章 P.73 可変性の分離
不変コンポーネントは、変数の状態の変更を許可している
↓
（これは原文からの間違い）
可変コンポーネントは、変数の状態の変更を許可している
# 第12章「コンポーネント」の p.112 「リロケータビリティ(再配置可能性)」
リロケータブルなコードにはフラグが組み込まれていて、どの部分をどのアドレスにロードする必要があるかを示している。
↓
リロケータブルなコードにはフラグが組み込まれ、選択したアドレスにロードするときにデータのどの部分を変更すべきかをローダに伝えていた。通常は、バイナリのメモリ参照アドレスに開始アドレスを加算するだけだった。
# 第14章「コンポーネントの結合」
p.130
このインターフェイスを Entities に入れて、 Authorizer からはそれを利用する。
↓
このインターフェイスを Entities に入れて、 Authorizer からはそれを継承する。
# 第15章「アーキテクチャ」 - 「選択肢を残しておく」の最後の部分
「優れたアーキテクトは、決定しない数を最大化するのである。」の訳語抜け。
# 第24章「部分的な境界」
FitNesse の話は、このアプローチの危険性も示している。時間が経つと、ウェブコンポーネントが必要なくなってきたからだ。
↓
FitNesse の話は、このアプローチの危険性も示している。時間が経つと、分離したウェブコンポーネントが必要なくなってきたからだ。
# 第27章 サービス: あらゆる存在
p.231
明確に定義されたインターフェイスに関しては、確かに正しいところもあるが、
関数のときほど正しいものではない。サービスのインターフェイスは、関数と
比べると、正式なものではなく、厳密なものではなく、明確に定義されている
ものでもない。こうしたメリットは、明らかに幻想である。
↓
明確に定義されたインターフェイスに関しては、確かに真実ではあるが、それは関数も同様である。サービスのインターフェイスは、関数と比べると、形式的なものではなく、厳密なものではなく、明確に定義されているものでもない。こうしたメリットは、明らかに幻想である。
p.232
ユーザーの条件に合ったタクシーを決定する。
↓
ユーザーの条件に合ったタクシーの候補を決定する。
p.236
めったにないが＊2、アーキテクチャに重要性を持たせないために、クライアントとサービスを結合させることもあるだろう。
↓
めったにないが＊2、アーキテクチャ的に意味をなさないほどクライアントとサービスが密接に結びついていることもある。
# 付録A アーキテクチャ考古学
p.306
ユーティリティレイヤーがMOPを読んでいる間にもMOPはそのレイヤーに手出
しをしていたり、逆にMOPからコールバックしたりすることもよくあった。
↓
ユーティリティレイヤーがMOPを呼び出す一方、MOPはそのレイヤーのために特別に修正されていたり、MOPからコールバックしたりすることもよくあった。
p.316
8085用の標準アセンブラをBoston Systems Officeから購入した我々は、> 4-Telのマイクロコードを8085用に移植した。
↓
8085用の標準アセンブラをBoston Systems Officeから購入した我々は、4-Telのコードをそのアセンブラの構文に変換した。
p.318
問題は、すべてのCOLTが同じ装置の発信と測定の両方を実施していることだった。
↓
問題は、すべてのCOLTが同じ装置で発信と測定の両方を実現していることだった。
p.326
そのためには、柔軟な解析とデータの表現技術が必要だった。
↓
そのためには、柔軟な構文解析とデータの表現技術が必要だった。
p.327
大した違いはないのである。
↓
この世に新しいものはないのである。
p.327
3 年後、我々は販売をやっていなかった。
↓
3年後、我々は販売に失敗していた。
hr.icon
thanx @masahiro_sakai