[豆ナイト]Java small object programming
Post on 28-Nov-2014
2632 Views
Preview:
DESCRIPTION
Transcript
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)なら課題の解決が可能ということに行き着いた
(c)2012 Starlight&Storm 3
お断り
• ThoughtWorksアンソロジーのオブジェクト指向エクササイズのような、如何に正しいオブジェクト「思考」でコーディングするかという話ではありません – もちろん、それは大事です。それは承知の上で…
• 目指したのは、正しいオブジェクト「思考」でコーディングできない人達が多い中でも、システムを簡単に安く、かつ平均以上の品質で、開発し、メンテナンスし続けることです – もちろん、そうは言っても、全員がオブジェクト「思考はダメ」では話にならないのですし、ThoughtWorksアンソロジーのオブジェクト指向エクササイズも意識してますが…
(c)2012 Starlight&Storm 4
フィールドをクラスにする
(c)2012 Starlight&Storm 5
普通のEmployeeクラス
6 (c)2012 Starlight&Storm
普通の(散らばる検証)処理
(c)2012 Starlight&Storm 7
処理をどこに置くか?
• メソッドを、ドメインクラスに置いても処理の重複は排除できない – フィールドクラスの採用
8 (c)2012 Starlight&Storm
例えば、nameやcodeは、単独でも検証される
フィールドをクラスにする
• フィールド(nameとcode)をクラスにする
• フィールドの処理は、フィールドでおこなう • フィールドクラスは単体でも利用可能
(c)2012 Starlight&Storm 9
Employeeと周辺クラス • NameやCodeの処理が変更になった場合も、利用側のコードには影響がない
(c)2012 Starlight&Storm 10
フィールドをクラスにしないデメリット
• 通常Stringやリテラルの属性として記述される商品コードetcがどのように利用されているか、どのような仕様かは、コードから読取ることは(なかなか)できない – 例:以下はシステムに散らばった商品コードの例。これでは検索もできない
• String shohinCode • String sc • String shohinCd
– 例:ValidaYon(ex: if(sc.equals("")){...})が様々なクラスに分散(修正が複数カ所に及ぶ)
– 例:仕様書がないと、商品コードの仕様がわからない • 検証処理は分散しているし、商品コードの変数名は不統一
(c)2012 Starlight&Storm 11
フィールドをクラスにするメリット • 利用方法と仕様がひとめで分かる
– 商品コードクラスが、利用方法と仕様を表している • 検索が楽
– 商品コードは常に商品コードの型
– 例:ShohinCode sc; • 修正は常に1カ所
– 商品コードの検証処理は商品コードがもつので、処理が分散しない
• 仕様書は不要(もしくは後述する自動生成用のExcelが仕様書) – 商品コードの仕様は、商品コードクラスがもっている
• システムを再構築する場合も、フィールドクラスは再利用可能(なものが多い)
12 (c)2012 Starlight&Storm
Javaの冗長性を排除
(c)2012 Starlight&Storm 13
普通の(冗長な)Employeeクラス
14 (c)2012 Starlight&Storm
Employeeの冗長性排除 • Java 言語の欠点は構文の冗長性
– Seder-‐Geder – toString() – equals() – ローカル変数の宣言
– コンストラクタ – close() – try-‐catch – Log – ・・・
Spring等のフレームワーク でカバーする範囲
15 (c)2012 Starlight&Storm
ほぼ、Seder-‐Gederだけなのに、やけに長いEmployee
広 告
• COMMING SOON!
(c)2012 Starlight&Storm 16
Lombokの利用法
• @Dataアノテーション – Geder-‐Sederが不要
– toString()が不要 – equals()が不要
17 (c)2012 Starlight&Storm
Employeeと周辺クラス(Lombok適用)
18 (c)2012 Starlight&Storm
自動生成を考える
(c)2012 Starlight&Storm 19
DDDのパターンを利用する • FactoriesやRepositoriesパターンを利用して、フィールド・クラスをもった、ドメイン・クラスを作成する
20
Factory Repository
(c)2012 Starlight&Storm
自動生成への道
• DDDの実施後、ユーザがクラスの設計をおこない、設計からクラスを自動生成する
• フィールドクラスやLombokを利用すれば、コード生成はより簡単に可能
変換
21 (c)2012 Starlight&Storm
自動生成と開発(例)
入力 自動生成
Test Code
Java Doc
Eclipse
開発
jarとして提供
・補完 ・テスト ・アーカイブ化 ・提供...etc
× ソースコードは直接修正できない
22
ユーザ
(c)2012 Starlight&Storm
広 告
• Java Small-‐Object Programming – 研修
– システムへの導入 – 自動生成ツールの作成
(c)2012 Starlight&Storm 23
info@starlight-storm.com
(c)2012 Starlight&Storm 24
info@starlight-storm.com
http://www.starlight-storm.com/
付録:インスタンス生成時間の検証 • S-‐OP vs OP : MyBaYs2, HSQLDB MEMORY
クラスのプロパティ数*クラスのインスタンス数
top related