[豆ナイト]Java small object programming

Small-‐Object Programming とコードの自動生成

オブジェクトが小さくなったら、コードが自動生成できちゃった!?

2012/10/26 豆ナイト

(c)2012 Starlight&Storm 1

2

発表者：長谷川裕一 •  合同会社Starlight&Storm 代表社員

–  1986年、イリノイ州警察指紋システムのアセンブリ言語プログラマからスタートして、PL，PMと経験し、アーキテクト、コンサルタントへ

– 現在はオブジェクト指向を中心に、コンサルティング（IT戦略、技術、プロセス、マネージメント...etc）や教育で活動

•  書籍 – プログラムの育てかた（ソフトバンク）、Spring入門（技術評論社）、Spring2.0入門（技術評論社）、間違いだらけのソフトウェア・アーキテクチャ（技術評論社）

•  その他 – 日本Springユーザ会会長、SQuBOK開発領域策定メンバ、株式会社フルネス取締役

お話の前提~こんな仕事があった… •  課題が色々あった

– どうすれば、コードの重複をなくせるか – どうすれば、属性の仕様をまとめることができるか

– どうすれば、コードの自動生成ができるか – どうすれば、DDDと自動生成の両方を活かせるか

– どうすれば、ユーザが積極的に自動生成に関われるか – どうすれば、自動生成後のコードメンテナンスを簡単にできるようになるか

•  解決策として –  S-‐OP（Small-‐Object Programming）なら課題の解決が可能ということに行き着いた


お断り

•  ThoughtWorksアンソロジーのオブジェクト指向エクササイズのような、如何に正しいオブジェクト「思考」でコーディングするかという話ではありません –  もちろん、それは大事です。それは承知の上で…

•  目指したのは、正しいオブジェクト「思考」でコーディングできない人達が多い中でも、システムを簡単に安く、かつ平均以上の品質で、開発し、メンテナンスし続けることです –  もちろん、そうは言っても、全員がオブジェクト「思考はダメ」では話にならないのですし、ThoughtWorksアンソロジーのオブジェクト指向エクササイズも意識してますが…


フィールドをクラスにする


普通のEmployeeクラス

6 (c)2012 Starlight&Storm

普通の（散らばる検証）処理


処理をどこに置くか？

•  メソッドを、ドメインクラスに置いても処理の重複は排除できない – フィールドクラスの採用


例えば、nameやcodeは、単独でも検証される

フィールドをクラスにする

•  フィールド（nameとcode）をクラスにする

•  フィールドの処理は、フィールドでおこなう •  フィールドクラスは単体でも利用可能


Employeeと周辺クラス •  NameやCodeの処理が変更になった場合も、利用側のコードには影響がない


フィールドをクラスにしないデメリット

•  通常Stringやリテラルの属性として記述される商品コードetcがどのように利用されているか、どのような仕様かは、コードから読取ることは（なかなか）できない – 例：以下はシステムに散らばった商品コードの例。これでは検索もできない

•  String shohinCode •  String sc •  String shohinCd

– 例：ValidaYon（ex: if(sc.equals("")){...}）が様々なクラスに分散（修正が複数カ所に及ぶ）

– 例：仕様書がないと、商品コードの仕様がわからない •  検証処理は分散しているし、商品コードの変数名は不統一


フィールドをクラスにするメリット •  利用方法と仕様がひとめで分かる

–  商品コードクラスが、利用方法と仕様を表している •  検索が楽

–  商品コードは常に商品コードの型

–  例：ShohinCode sc; •  修正は常に1カ所

–  商品コードの検証処理は商品コードがもつので、処理が分散しない

•  仕様書は不要（もしくは後述する自動生成用のExcelが仕様書） –  商品コードの仕様は、商品コードクラスがもっている

•  システムを再構築する場合も、フィールドクラスは再利用可能（なものが多い）


Javaの冗長性を排除


普通の（冗長な）Employeeクラス


Employeeの冗長性排除 •  Java 言語の欠点は構文の冗長性

– Seder-‐Geder –  toString() – equals() – ローカル変数の宣言

– コンストラクタ – close() –  try-‐catch – Log – ・・・

Spring等のフレームワークでカバーする範囲


ほぼ、Seder-‐Gederだけなのに、やけに長いEmployee

広告

•  COMMING SOON!


Lombokの利用法

•  @Dataアノテーション – Geder-‐Sederが不要

–  toString()が不要 – equals()が不要


Employeeと周辺クラス（Lombok適用）


自動生成を考える


DDDのパターンを利用する •  FactoriesやRepositoriesパターンを利用して、フィールド・クラスをもった、ドメイン・クラスを作成する

20

Factory Repository

(c)2012 Starlight&Storm

自動生成への道

•  DDDの実施後、ユーザがクラスの設計をおこない、設計からクラスを自動生成する

•  フィールドクラスやLombokを利用すれば、コード生成はより簡単に可能

変換


自動生成と開発（例）

入力自動生成

Test Code

Java Doc

Eclipse

開発

jarとして提供

・補完・テスト・アーカイブ化・提供...etc

× ソースコードは直接修正できない

22

ユーザ

(c)2012 Starlight&Storm

広告

•  Java Small-‐Object Programming – 研修

– システムへの導入 – 自動生成ツールの作成


[email protected]


[email protected]

http://www.starlight-storm.com/

付録：インスタンス生成時間の検証 •  S-‐OP vs OP : MyBaYs2, HSQLDB MEMORY

クラスのプロパティ数＊クラスのインスタンス数

Education

[豆ナイト]Java small object programming