地引製作所

私が最初に読んだオプジェクト指向プログラミングの本です。よくあるオブジェクト指向の本は、特定の言語やフレームワークに特定して語られるものが多く、偏った見方のものが多いと思います。しかし、この本では、4つの言語を使用し、それぞれの言語で書かれたサンプルコードを提示したり、同じ機能に対してそれぞの言語のアプローチの違いや、実装の違いなどの解説しています。特定の言語やシステムに偏ることなく、オブジェクト指向本来の概念や思想について書かれている良書です。

最初に買ったのは第一版で、出版されたのは1995年でした。その当時 Java はまだ生まれたばかりなので、サンプルコードの言語に入っていませんでした。その後、第二版を買ったのですが、Objective-Pascal が外され、代わりに Java が入ってきました。原書は第三版が出ているようですが、まだ日本語訳は出ていないようです。

中島聡さんのメルマガを購読していますが、Google I/O に参加した成果として、Firebase の良さを知ったとのこと。
今までは、サーバー側のシステムを作るのに、別の人に頼まないといけなかったのが、自分でサクサクと作れてしまうらしい。

早速、以下のようなゲームのサービスを作って見たとのこと。
https://tourneygames.com/play/be7eMqKVNtydv0mJrUah

• React.js + Firebase で開発
• NoSQL Database（firestore） + サーバーレス（firebase + Cloud Functions）上に作られている。
• ユーザー数が１００万人に増えても勝手にスケールしてくれる。そんなスケーラブルなサービスが、Firebase だとあっさりと作れてしまう。

今まで、自分で作るアプリはサーバーが不要なものだけだったけど、これでサーバー側もいけるかも。

ちょっと調べてみよう。

借りて読んだので、気になった箇所を簡単にまとめました。
基本的に Web アプリケーション向けの内容なのですが、随所に他のシステムでも役に立ちそうな Tips が入ってます。

第1章 小さくまとめて分かりやすくする

ValueObject

• 電話番号なら String ではなく TelephoneNumber 型など業務専用の型を作って、長さなどの制限する。
• 完全コンストラクタ（初期化時に値が決まり、以降変更できない。Immutable なもの）にすると、コードを読む時に値の変化を気にする必要がなくなる。
• 金額と数量はどちらも Int で表せるが、それぞれ独自の型を作っておくと誤った代入をコンパイル時に検出できる。
• typedef のような型を別名で定義するのと比べて、コンパイル時に上記のような型誤りの検出が可能。

コレクションオブジェクト

• List や Array のプロパティを１つだけ持ち、それの操作メソッドを持つ。
• immutable にする
• 操作の結果は、同じ型のコレクションオブジェクトとして返す。

第2章　場合分けのロジックを整理する

• 早期リターンを使って if 文の else 節を排除すると、コードの見通しが良くなる。
• インターフェイス宣言（Swift なら protocol）と区分ごとの専用クラスを組み合わせて、多態(Polymorphism)を実現する。
• 区分オブジェクト：列挙型を使って業務で扱う区分の一覧を宣言する。

第3章　業務ロジックをわかりやすく整理する

• ドメインモデルに業務データと業務ロジックを集める。
• ドメインモデルは画面やデータベースの都合から独立させる。

第4章　ドメインモデルの考え方で設定する

• 業務の関心ごとはヒト／モノ／コトで整理できる。
• コトの整理を軸にする。
• ドメインモデル設計のインプットは、業務の言葉の正しい理解。

第5章　アプリケーション機能を組み立てる

• 業務的な判断、加工、計算の詳細はドメインモデルに集約する。
• データベース操作はリポジトリクラスに持っていく。
• サービスクラスは小さく分ける。
• 小さく分ける基本は、まず登録系のサービスと参照系のサービスを分ける。
• 小さく分けたサービスを組み立てる。
• 必要に応じて、基本的なサービスクラスを組み合わせた複合サービスを提供するシナリオクラスを作る。

第6章　データベースの設計とドメインオブジェクト

• カラム名は省略形にしない。
• 全てのカラムに NOT NULL 制約を付ける。
• NULL を入れる必要があるカラムが出てきたら、別テーブルに分けるサイン。
• 一意性制約でデータの重複を防ぐ。
• 外部キー制約でテーブル間の関係を明確にする。
• 記録のタイミングが異なるデータはテーブルを分ける（NULLを防ぐ）。
• UPDATE を使わずに、DELETE, INSERT を使う（訂正の記録を残せる）。
• データベースの設計変更でカラムを追加する場合は、テーブルを追加して、そこに入れる。
• 元のテーブルがそのまま利用できる。
• 追加したカラムに NULL を入れなくて済む。
• 基本は「コト」を記録するテーブルを作る。
• 「コト」によって変化する「状態」などの派生的なでデータは別テーブルに記録する。
• 銀行口座で例えるなら、「コト」は入金、出勤、「状態」は残高。
• ただし、この方法では厳密な即時性には対応できない。
• オブジェクトとテーブルは似てくるが、兼用させないで、違うものとして明示的にマッピングする。

第7章　画面とドメインオブジェクトの設計を連動させる

• タスクごとに画面を分ける。
• 画面表示ロジックに業務ロジックを書かない。
• 画面表示で if 文を使っている場合は、その条件判断をドメインオブジェクトに移動する（特定の条件で赤字で表示、0件の場合の特別表示、など）。

第8章　アプリケーション間の連携

• POST と PUT の違い。POST は識別子を指定しないで登録し、レスポンスで識別子を返す。PUT は識別子を指定して登録する。
• Web API は、修正を繰り返すうちに何でも出来る肥大化した API になりがちだが、それだど修正や拡張が難しくなる。
• 修正や拡張を重視する場合、組み合わせて使用するような適度な大きさの API に分割する（ただし、あまり細かくすると組み合わせるのが大変になる）。
• 初期段階では単純な API だけを提供し、フィードバックを得ながら追加、変更して行く。
• 単純な API は、登録と参照を分ける、リソースの単位を分ける、ことに気をつける。

第9章　オブジェクト指向の開発プロセス

• 更新すべきドキュメント：利用者向けのドキュメント、画面や帳票、データベース仕様
• 個人的にはAPI仕様も加えた方が良いかも

第10章　オブジェクト指向設計の学び方と教え方

• 過激なコーディング規則
1. 1つのメソッドにつきインデントは1段階までにすること（good）
2. else 句を利用しないこと（good）
3. 全てのプリミティブ型と文字列をラップすること
4. 1行につきドットは1つまでにすること（too much）
5. 名前を省略しないこと（good）
6. 全てのエンティティを小さくすること
7. 1つのクラスにつきインスタンス変数は2つまでにすること（too much）
8. ファーストクラスコレクションを使用すること（good）
9. getter、setter、ブロパティを使用しないこと（too much）
• ↑ 「過激」と銘打っているだけあって、さすがにやり過ぎだと思う項目が・・・

参考文献の中で読んでみたいと思ったもの