Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[Jjug]java small object programming

3,377 views

Published on

Published in: Technology
  • Be the first to comment

[Jjug]java small object programming

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

×