現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

サポートページ

この記事を読むのに必要な時間:およそ 0.5 分

お詫びと訂正(正誤表)

本書の以下の部分に誤りがありました。ここに訂正するとともに,ご迷惑をおかけしたことを深くお詫び申し上げます。

(2019年10月23日最終更新。これ以下は第3刷にて反映済み)

P.11 「第8章のまとめ」の2行上

複雑なデータの交換
構造が複雑なデータの交換をどうするか

P.215 上から10行目

ドメインオブジェクト側にclass属性を返すメソッドを用意するやり方で、~
ドメインオブジェクトが状態を表す情報を返し、それをclass属性で利用するやり方で、~

P.215 リスト「ドメインオブジェクトが論理的な属性を返す」の3行目


return "";


return "read";

P.215 リスト「ドメインオブジェクトが論理的な属性を返す」の最終行


// <p class="${mail.readStatus}">


// <p class="${mail.readStatus()}">

P.215 下から7行目

ドメインオブジェクトがHTMLのclass属性の値を返すこのやり方は、~
ドメインオブジェクトの返す情報をclass属性として利用するこのやり方は、~

P.264 上から9行目

複雑なデータの交換
構造が複雑なデータの交換をどうするか

P.264 上から16行目(箇条書きから3行上)

JSONよりもXMLが有力な選択肢となります。
JSONだけでなくXML選択肢となります。

P.265 上から6行目

そもそも、オブジェクト指向設計の観点から言えば、基本の選択肢はJSONではなくXMLです。設計が変化してくことも重視すると、JSONよりは、XMLのほうが、対応が楽で安全です。
複雑な構造のオブジェクトをそのまま表現することを重視すれば、基本の選択肢はJSONよりもXMLです。構造が変化したときに、JSONよりは、XMLのほうが、対応が楽で安全です。

(以下2018年11月6日更新)

P.203 表「小さな単位に分ける」,ドメインオブジェクト項の下から2番目

ConatctTo
ContactTo

(以下2017年10月25日更新)

P.37 リスト「独自の型を使って意図を明らかにする」の2行目


if(quantity.isDiscountable)


if(quantity.isDiscountable())

P.58 リスト「if文を使わずに区分ごとのオブジェクトを生成するやり方の例」のstatic{}内


static
{
     types.put( "adult", new AdultFee());
     types.put( "child", new ChildFee());
}


static
{
     types = new HashMap<String, Fee>();
     types.put( "adult", new AdultFee());
     types.put( "child", new ChildFee());
}

P.111 上から4行目

判断/加工/処理
判断/加工/計算

P.144 下から9行目

判断/加工/計算処理
判断/加工/計算

(以下,2017年10月23日更新)

P.31 リスト「正しい数量を扱うための独自クラス(Quantityクラス)を定義する」内,31ページ上から5行目


throw new IllegalArgumentException("不正:合計が" + 100 + "以上");


throw new IllegalArgumentException("不正:合計が" + MAX + "");

P.43  リスト「コレクション操作の結果を同じ型のコレクションオブジェクトを作って返す(良い例)」の6行目


return new Customers(result.add(customer));



result.add(customer);
return new Customers(result);


(以下2017年8月10日更新)

P.34 上から8行目

~特定にクラスに集めて整理しておけば、~
~特定クラスに集めて整理しておけば、~

P.66 上から3行目

次のようなルール宣言的に~
次のようなルール宣言的に~

P.69 表「データクラスのいろいろな呼び方」内,Formクラス項目の説明

画面とデータとやりとりするための~
画面とデータやりとりするための~

P.165 下から9行目

契約による設計と対象的な技法が~
契約による設計と対的な技法が~

P.166中段 上から14行目

~設計が重要なテーマです。
~設計重要なテーマです。

P.170 下から4行目

~具体的にどやってデータベースで実現するかは、~
~具体的にどやってデータベースで実現するかは、~

P.171 「第5章のまとめ」の5行目

~シンプル保つための設計の徹底が重要
~シンプル保つための設計の徹底が重要

P.181 下から12行目

一意性制約とNOT NUL制約を徹底すれば、~
一意性制約とNOT NULL制約を徹底すれば、~

(以下,2017年7月26日更新。これ以下は第2刷にて反映済み)

P.17 表「名前の違い」の3行目

unitPrice;
int unitPrice;

P.148 「第4章のまとめ」の5行目

起きてよいこと/起きてはいけなくこと
起きてよいこと/起きてはいけなこと

P.215 リスト「ドメインオブジェクトが論理的な属性を返す」の最終行


// <p class="${mail.readStatus}>


// <p class="${mail.readStatus}">

P.234 リスト「GETリクエストで返されるレスポンスデータの例(JSON形式)」の2行目


"id" : "1234"


"id" : "1234",

P.245 リスト「単純な用途を実現するAPI」の5行目

"name":" 田中太郎"


"name":" 田中太郎",

(2017年7月6日更新)

P.63 図2-2

誤
正

「審査中」と「差し戻し中」の間の,「再申請」に相当する左向き矢印(赤丸で囲った部分)が抜けていました。