Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à [Jjug]java small object programming
Similaire à [Jjug]java small object programming (20)
Plus de Yuichi Hasegawa
Dernier
Dernier (9)
[Jjug]java small object programming
- 2. 2 自己紹介 • 長谷川 裕一 • Starlight&Storm 代表 – 1986年、イリノイ州警察指紋システムのアセンブリ言語プログラマか らスタートして、PL／PMと経験し、アーキテクト、コンサルタントへ – 現在はオブジェクト指向を中心に、コンサルティング（IT戦略、技術、 プロセスetc）や教育で活動 • 書籍 – プログラムの育てかた（ソフトバンク）、Spring入門、Spring2.0入門、 間違いだらけのソフトウェア・アーキテクチャ、Spring3入門（以上は 技術評論社） • その他 – 日本Springユーザ会会長、SQuBOK策定メンバ（アーキテクチャ構 築／評価担当）、株式会社フルネス取締役、チェンジビジョン・コンサ ルティング・パートナー
- 3. はじめに • 本日、もって帰って頂くもの – S-OPとはどのようなもので、何に有効なのか • アジェンダ 1. S-OPとは何か？ 2. アプリケーションの現状 3. Javaの抱える問題 4. S-OPの具体例 5. 9つのルールとDDD 6. 自動生成への道 3
- 5. S-OP • Java Small-Object Programming – 小さい（Small） 部品（Object）で、アプリケーショ ンを作ろう • 背景 – テストや変更の容易性、可読性の悪いアプリケー ションの多さ – フレームワーク（UIやORM、DIxAOP）の定番化 – Javaの冗長さと、様々なオブジェクト指向言語の 流行(!?) – DDD（ドメイン駆動設計）や、9つのルールなどの 出現 5
- 6. S-OPの実現 • オブジェクトを小さく作る – DDDや9つのルールなどを利用する • Frameworkなどを有効活用する – DIxAOP • Spring Framework – ORM • MyBatis、Hibernate、JPA...etc – その他 • Lombok 6 アプリケーション （フレームワーク ） アプリケーション （ビジネスロジック...） DDD 9つのルール Framework アプリケーションを大きく2分割した図
- 8. アプリケーションの現状（1） • フレームワークなど、基盤となる部分の選択や組合 せなどのミスが、アプリケーション全体の見通しを悪 くすることがあった • 最近は、フレームワークなどは定番化し、比較的安 定している（特にJavaの場合） – SpringFramework、SpringMVC、MyBatis...etc 8 アプリケーション （フレームワーク ） アプリケーション （ビジネスロジック...） ぐらぐら ぐらぐら
- 9. アプリケーションの現状（2） • ビジネスロジックが、理解しづらく、変更容易性やテストのしや すさに耐えられない作りになっている – 1000行を越えるメソッド、意味不明なクラス名… • ビジネスの変更がシステムに与える影響とは、ビジネスロジッ クの変更である – システムをスクラッチで作る理由は、ビジネスロジックが独自であるか ら（ユーザはフレームワークが欲しい訳ではない） 9 アプリケーション （フレームワーク ） アプリケーション （ビジネスロジック...） ぐらぐら ぐらぐら
- 10. S-OPは何を解決するか? • 障害、変更・拡張はビジネスロジックの部分に多く、そこが不 安定であることは、障害を生んだり、変更・拡張に多大なコス トがかかる – システムの寿命は、開発よりも保守の期間の方が長い – システムは開発後、一瞬たりとも安定することはない（恒に障害、変 更・拡張にさらされる） • S-OPは、ビジネスロジックの可読性の向上とそれに伴う変 更・拡張、テストを容易にすることで、障害の削減と保守コス トの削減をもたらす 10 ぐらぐら ぐらぐら
- 11. 3. Javaの抱える問題 11
- 12. 前提: Javaはオブジェクト指向言語か？ • C言語に似た制御構文や演算子をもつことで、オブ ジェクト指向（的）ではないプログラミングが容易にで きてしまう • オブジェクトではないプリミティブ型（intやlong…）を もつ • Smalltalkよりも、Cに近い準オブジェクト指向言語!? – オブジェクト指向を意識したプログラミング（S-OP）が必要 12 純粋な OO言語 非純粋な OO言語 Smal ltalk Ruby Java
- 15. 4. S-OPの具体例 15
- 16. プリミティブ・文字型をラップしてクラスにする • プリミティブ・文字型（int、longやString）をそのまま 利用すると、処理や知識（仕様）が散らばる可能性 が大きい – double price • 消費税（外）を計算するのはどこか？ – String code • codeが三桁の数字であることを知っているのは誰か？ • プリミティブ・文字型をクラスにする – Priceクラス • 消費税（外）を計算する役割をもつ – Codeクラス • codeが三桁の数字であることを知っている 16 アプリケーション （フレームワーク ） アプリケーション （ビジネスロジック...）
- 18. フィールドをクラスにする • フィールド（nameとcode）をラップしてクラスに する • フィールドの処理は、フィールドでおこなう • フィールドクラスは単体でも利用可能 18
- 21. フィールドクラスを利用しないデメリット • 通常プリミティブ・文字型の属性として記述される商 品コードetcがどのように利用されているか、どのよ うな仕様かは、コードから読取ることは（なかなか）で きない – 例：以下はシステムに散らばった商品コードの例。これで は検索もできない • String shohinCode • String sc • String shohinCd – 例：Validation（ex: if(sc.equals("")){...}）が様々なクラス に分散（修正が複数カ所に及ぶ） – 例：仕様書がないと、商品コードの仕様がわからない • 検証処理は分散しているし、商品コードの変数名は不統一 21
- 22. フィールドクラスを利用するメリット • 利用方法と仕様がひとめで分かる – 商品コードクラスが、利用方法と仕様を表している • 検索が楽 – 商品コードは常に商品コードの型 – 例：ShohinCode sc; • 修正は常に1カ所 – 商品コードの検証処理は商品コードがもつので、処理が分散しない • 仕様書がない場合も保守が楽 – 商品コードの仕様は、商品コードクラスがもっている • システムを再構築する場合も、フィールドクラスは再利用可能 （なものが多い） • [デメリット]全てのプリミティブ・文字型をクラスにすると、インスタンスが増 えてメモりを圧迫したり、getValueメソッドて可読性が落ちる可能性もある ため注意すること 22
- 23. 不必要なSetter-Getterは記述しない • 不必要なSetter – 本当に値の変更が必要か？ – コンストラクタで値を設定し、値は変えない（不変）ことを考 慮する • 不必要なGetter – 値を渡すだけで、処理を他のクラスに委ねていないか？ – 本来の処理を考慮し、処理を施した値を渡すべきかを考 慮する • 例 – 倉庫クラスに在庫属性があった時に、set在庫は不要 – 倉庫の在庫はSETするものか？減らすものではないか？ 23
- 24. Frameworkを利用する • Lombok – アノテーションを利用して冗長な処理（Setter- Getter、equals、toString）を削除する • Ex: @Dataアノテーション – Getter-Setterが不要 – toString()が不要 – equals()が不要 24
- 25. その他のFWの適用領域 • 例外やログのような、本質的ではない処理はSpringな どのFWを用いて隠す – close() – try-catch – Log出力 – …etc • 本質的ではない処理が多いと – 本質的な処理が何かが理解しずらくなる – テストの量が多くなる – 変更が容易ではなくなる – …etc 25 アプリケーション （フレームワーク ） アプリケーション （ビジネスロジック...）
- 26. 5. 9つのルールとDDD 26
- 27. 設計と実装を見直す9つのルール • ドメインモデルを上手く設計／実装できない初心者／初級者 向けのエクササイズとして、Thought Works社のコンサルタ ントが提唱したコーディングルール（一部Java用に変更） • S-OPのコーディングルールとしても採用可能 27 • 1メソッドにつきインデントは1段階（1メソッド3行程度を目標） • else句は使用しない • すべてのプリミティブ型と文字列型をラップすること • 1行につき「.(ドット)」は1つとすること • 名前を省略しないこと • すべてのエンティティを小さくすること（1クラス50行程度） • 1クラスにつきインスタンス変数は2つまでにすること • ファーストクラスコレクションを使用すること • Getter-Setterを使用しないこと
- 28. DDD（ドメイン駆動設計） • エリック・エバンス氏により提唱された、モデル駆動な設計と、 ユビキタスな言語を中心とした開発手法（や哲学） – モデル駆動な設計 • コードの前に、モデリング – ユビキタスな言語を中心 • コードにも、業務の言葉を使う 28 代表的なパターン
- 31. Repositoriesパターン インスタンス生成時間の検証 • S-OP vs OP : MyBatis2, HSQLDB MEMORY 31 クラスのプロパティ数＊クラスのインスタンス数
- 33. S-OPはトランザクションスクリプトに不向き!? • 所謂、入れポン-出しポンのビジネスロジック がないアプリケーションにも最適 – 少ないフィールドクラスで実現できることが多い – フィールドクラスを用意しておけば、以下のことが 実現できる • Validationしか処理らしい処理がないので、 Validationが散らばらない • 一旦、フィールドクラスを作ってしまえば、多く のクラスがそれを利用できる – 表示のためのクラスは、フィールドクラスをまとめる だけで良い – 入力された値は、フィールドクラスでValidation 33
- 34. 6. 自動生成への道 34
- 35. DDDからDSLへ • DDDのモデルを自動生成できないか？ – ユーザがコードの生成に参加する • DSL（Domain-Specific Language：ドメイン 固有言語） – ある特定の領域（ドメイン）の問題を解決するため に作られた言語 35 DSL 実行形式 変 換
- 36. 外部と内部のDSL • 外部DSL – 新しい言語(テキストベースUML、XMLやExcelな ど)を開発し利用する • 内部DSL – 一般に利用されるプログラミング言語（のアノテー ションなど）を利用する 36 Product -code:String ・・・ +getCode():String ・・・ 変 換 Class: Product { code 文字列 … Relation: Product ... 外部DSL
- 37. 自動生成への道 • ドメインモデルの作成後、クラスを自動生成 する – 単純な参照系でドメインにロジックがない場合は、 もっと簡単 • フィールドクラスやLombokを利用すれば、 コード生成はより簡単に可能 37 変 換 変 換 Class: Name ... Code ... Employee ... Relation: Employee ... テキストベース UML
- 38. 仕組みの部分も自動生成 • プレゼンテーション – パターン化して自動生成 • 検索と一覧などの画面方式を統一 • 画面遷移を統一（参照-更新-確定など） • …etc – Spring MVCやSpring WebFlowなどを利用する • DBアクセス – O-Rマッピング • 入れポン-出しポンのシステムであれば、上手くすると テーブル設計と同時にフィールドクラスも生成可能(!?) – Spring+MyBatisやSpringJDBCなどを利用する 38
- 39. 自動生成と開発（例） 39 入力 自動生成 Test Code Java Doc Eclipse プレゼンとDBアクセス を自動生成 jarとして提供 ・補完 ・テスト ・アーカイブ化 ・提供...etc × ソースコードは直接 修正できない ユーザ Class: Name ... Code ... Employee ... Relation: Employee ... ドキュメント （UML）
- 40. おわりに 40
- 41. おわりに • 景気が回復しているという噂もありますので • 是非、S-OP適用事例の3件目になってみた いという方、お声掛け下さい – S-OPの2日間研修（演習6割程度）もやってます • お問い合わせはこちら☟☟☟ 41 http://www.starlight-storm.com/ info@starlight-storm.com
- 42. Bon Voyage! 42