豆ナイト「ドメイン居酒屋」の講演資料。

1. Small-­‐Object
Programming
とコードの自動生成
オブジェクトが小さくなったら、コード
が自動生成できちゃった!?
2012/10/26
豆ナイト
(c)2012
Starlight&Storm
1

2. 発表者：長谷川 裕一
• 合同会社Starlight&Storm
代表社員
– 1986年、イリノイ州警察指紋システムのアセンブリ言語プ
ログラマからスタートして、PL，PMと経験し、アーキテクト、
コンサルタントへ
– 現在はオブジェクト指向を中心に、コンサルティング（IT戦
略、技術、プロセス、マネージメント...etc）や教育で活動
• 書籍
– プログラムの育てかた（ソフトバンク）、Spring入門（技術評
論社）、Spring2.0入門（技術評論社）、間違いだらけのソフ
トウェア・アーキテクチャ（技術評論社）
• その他
– 日本Springユーザ会会長、SQuBOK開発領域策定メンバ、
株式会社フルネス取締役
2

3. お話の前提 こんな仕事があった…
• 課題が色々あった
– どうすれば、コードの重複をなくせるか
– どうすれば、属性の仕様をまとめることができるか
– どうすれば、コードの自動生成ができるか
– どうすれば、DDDと自動生成の両方を活かせるか
– どうすれば、ユーザが積極的に自動生成に関われるか
– どうすれば、自動生成後のコードメンテナンスを簡単にで
きるようになるか
• 解決策として
– S-­‐OP（Small-­‐Object
Programming）なら課題の解決が可能
ということに行き着いた
(c)2012
Starlight&Storm
3

4. お断り
• ThoughtWorksアンソロジーのオブジェクト指向エク
ササイズのような、如何に正しいオブジェクト「思考」
でコーディングするかという話ではありません
– もちろん、それは大事です。それは承知の上で…
• 目指したのは、正しいオブジェクト「思考」でコーディ
ングできない人達が多い中でも、システムを簡単に
安く、かつ平均以上の品質で、開発し、メンテナンス
し続けることです
– もちろん、そうは言っても、全員がオブジェクト「思考はダ
メ」では話にならないのですし、ThoughtWorksアンソロ
ジーのオブジェクト指向エクササイズも意識してますが…
(c)2012
Starlight&Storm
4

5. フィールドをクラスにする
(c)2012
Starlight&Storm
5

6. 普通のEmployeeクラス
(c)2012
Starlight&Storm
6

7. 普通の（散らばる検証）処理
(c)2012
Starlight&Storm
7

8. 処理をどこに置くか？
• メソッドを、ドメインクラスに置いても処理の重
複は排除できない
– フィールドクラスの採用
例えば、nameやcodeは、
単独でも検証される
(c)2012
Starlight&Storm
8

9. フィールドをクラスにする
• フィールド（nameとcode）をクラスにする
• フィールドの処理は、フィールドでおこなう
• フィールドクラスは単体でも利用可能
(c)2012
Starlight&Storm
9

10. Employeeと周辺クラス
• NameやCodeの処理が変更になった場合も、
利用側のコードには影響がない
(c)2012
Starlight&Storm
10

11. フィールドをクラスにしないデメリット
• 通常Stringやリテラルの属性として記述される商品
コードetcがどのように利用されているか、どのような
仕様かは、コードから読取ることは（なかなか）でき
ない
– 例：以下はシステムに散らばった商品コードの例。これで
は検索もできない
• String
shohinCode
• String
sc
• String
shohinCd
– 例：ValidaYon（ex:
if(sc.equals("")){...}）が様々なクラスに
分散（修正が複数カ所に及ぶ）
– 例：仕様書がないと、商品コードの仕様がわからない
• 検証処理は分散しているし、商品コードの変数名は不統一
(c)2012
Starlight&Storm
11

12. フィールドをクラスにするメリット
• 利用方法と仕様がひとめで分かる
– 商品コードクラスが、利用方法と仕様を表している
• 検索が楽
– 商品コードは常に商品コードの型
– 例：ShohinCode
sc;
• 修正は常に1カ所
– 商品コードの検証処理は商品コードがもつので、処理が分散しない
• 仕様書は不要（もしくは後述する自動生成用のExcelが仕様
書）
– 商品コードの仕様は、商品コードクラスがもっている
• システムを再構築する場合も、フィールドクラスは再利用可
能（なものが多い）
(c)2012
Starlight&Storm
12

13. Javaの冗長性を排除
(c)2012
Starlight&Storm
13

14. 普通の（冗長な）Employeeクラス
(c)2012
Starlight&Storm
14

15. Employeeの冗長性排除
• Java
言語の欠点は構文の冗長性
– Seder-­‐Geder
ほぼ、Seder-­‐Geder
だけなのに、やけ
– toString()
に長いEmployee
– equals()
– ローカル変数の宣言
– コンストラクタ
– close()
– try-­‐catch
– Log
Spring等のフレームワーク
– ・・・
でカバーする範囲
(c)2012
Starlight&Storm
15

16. 広 告
• COMMING
SOON!
(c)2012
Starlight&Storm
16

17. Lombokの利用法
• @Dataアノテーション
– Geder-­‐Sederが不要
– toString()が不要
– equals()が不要
(c)2012
Starlight&Storm
17

18. Employeeと周辺クラス（Lombok適用）
(c)2012
Starlight&Storm
18

19. 自動生成を考える
(c)2012
Starlight&Storm
19

20. DDDのパターンを利用する
• FactoriesやRepositoriesパターンを利用して、
フィールド・クラスをもった、ドメイン・クラスを
作成する
Factory
Repository
(c)2012
Starlight&Storm
20

21. 自動生成への道
• DDDの実施後、ユーザがクラスの設計をおこ
ない、設計からクラスを自動生成する
• フィールドクラスやLombokを利用すれば、
コード生成はより簡単に可能
変
換
(c)2012
Starlight&Storm
21

22. 自動生成と開発（例）
入力
自動生成
ユーザ
・補完
Test
Java
・テスト
Code
Doc
・アーカイブ化
・提供...etc
開発
jarとして提供
×
ソースコードは直接
修正できない
Eclipse
(c)2012
Starlight&Storm
22

23. 広 告
• Java
Small-­‐Object
Programming
– 研修
– システムへの導入
– 自動生成ツールの作成
info@starlight-storm.com
(c)2012
Starlight&Storm
23

24. http://www.starlight-storm.com/
info@starlight-storm.com
(c)2012
Starlight&Storm
24

25. 付録：インスタンス生成時間の検証
• S-­‐OP
vs
OP
:
MyBaYs2,
HSQLDB
MEMORY
クラスのプロパティ数＊クラスのインスタンス数