<< ファウラーも、ケントベックも、 Value Object | main | Value Object は不変にする >>

Value Object : シンプルで小型のオブジェクトに目覚めた経緯

Value Objects パターンが出てくる本。

・ドメイン駆動設計(DDD) by エバンス
・PoEAA by ファウラー
・実装パターン by ベック。

三人とも、Value Object 、つまり、シンプルで小型で不変型の値オブジェクトを使うのが、設計・実装の良い習慣だといっている。

自分たちのプロジェクトでも、だいぶ Value Object パターンを普通に実践するようになった。
良い習慣になってきている感じ。

そこにいたるまでの経緯を簡単にまとめてみます。

出発点


こんな感じだった。

class Cstmr
{
private int id;
private String nm1 ;
private String nm2 ;
private String zcd ;
private String tdfk ;
private String cty ;

// こんな感じで、フィールドが20個くらい並ぶ

// そして、たくさんの setter と getter
}

コメント書こうぜ


これじゃわからんだろ、ということで、「コメント書こう運動」。

class Cstmr
{
// 顧客クラス

private int id; // ID
private String nm1 ; // 名前1
private String nm2 ; // 名前2
private String zcd ; // 郵便番号
private String tdfk ; // 都道府県
private String cty ; // 市区町村
...
}

コメントよりは名前が大切


コメントよりも、クラス名やフィールド名を分かりやすくする方針に転換。

class Customer
{
private int id ;
private String familyName ;
private String givenName ;
private String postalCode ;
private String prefecture ;
private String city ;
...
}

コメントなしにコードを読めるのが一番良い。
これは、ちょっとした発想の転換だった。

・フルスペルで(省略しないで)、意味のある名前をつける。
・コメントはできるだけ書かないで、理解できるようにする。

可読性、保守性の点でこっちがよさそうだということで、全面的に、この方針に転換。
この方針は、ネット上で

・コメントより良い名前
・コメントが多いのはアンチパターン(悪い習慣)

という主張を見かけたのがきっかけ。(出典不明)

小さなリファクタリング:空行


ずらっと、フィールドを並べるのではなく、意味のある単位にグルーピングするように改善。
改行の挿入という、小さなリファクタリングを実施。

class Customer
{
private int id ;

private String familyName ;
private String givenName ;

private String postalCode ;
private String prefecture ;
private String city ;
...
}

関連が強いフィールドのグループを「改行」で表現するようにした。

リファクタリング:クラスの抽出


ここで、大きな発想の転換がおきる。

きっかけは、Eclipse のリファクタリング機能をいろいろ試していたとき。
「クラスの抽出」が簡単にできることを発見(?)。

Eclipse が、フィールドのリストのチェックボックスを出してくれるので、密接に関連するフィールドにチェックボックスを入れて、クラス名を書くと、一丁あがり。

・familyName と givenName にチェック
・クラス名 PersonName を入力
・抽出実行

そうすると、元のクラス内の参照関係とかも、 Eclipse が全部書き換えてくれる。
こりゃ便利。

本末転倒かもしれないけど、ツールのクラスの抽出機能が面白くて(?)小さなオブジェクトを作ることに目覚めた。 

まあ、ノリは「リファクタリングごっこ」ですね。

フィールドのグループ単位にせっせと、小さなクラスを抽出。

class Customer
{
private int id ;

private PersonName personName;
private DeliveryAddress deliveryAddress ;
...
}

class PersonName
{
private String familyName ;
private String givenName ;
}

class DeliveryAddress
{
private String postalCode ;
private String prefecture ;
private String city ;
...
}

こうやってデータの入れ物として分割すると、それぞれのフィールドのバリデーションロジックとかも、抽出したクラスに移動する。

ケント・ベックのクラスの定義:

"This data goes together and this logic goes with it."

これを手軽に実践できる、Eclipse のリファクタリングは、使っていて楽しい機能です。

小型のオブジェクトにはなったけど


こんな感じで、大きなクラスから、

・名前の変更
・改行によるグルーピング
・クラスの抽出リファクタリング

を経て、シンプルで小型のオブジェクトを作ることが、習慣になってきた。

それぞれのオブジェクトがシンプルな役割に単純化され、データやロジックがどこにあるかもわかりやすくなった。

・コードが読みやすい
・変更箇所を特定しやすい
・変更の影響範囲が局所的(副作用の心配が少ない)
・テストコードも単純になり、簡単に書ける。メンテナンスも簡単。
・最初はちょっと面倒くさいけど、一度作れば、あちこちで利用でき、楽ができる。
...

という感じで、「シンプルで小型のオブジェクト」のメリットを具体的に実感できた。
そして、しだいに、自分たちの設計の習慣になっていった。

しかし、「不変(imutable)」、という Value Object パターンのもう一つの論点は、この時点でもぴんときていなかった。

不変オブジェクトという発想の転換が起きたのは、日付を扱うコードと格闘していた時。
このエピソードは、次の記事で書きます。

コメント
いつも参考にさせて頂いています。
DDD/RDRA/ICONIX等こちらのサイトで知って以来、勉強させて頂いてます。
銀の弾というのはないですが、DDDを知ってからシステムの設計がよく見えるようになった気がします。
しかし、私の会社は二次請け、三次請けがほとんどで仕事でDDDを採用している案件は出会った事がなく(利口なUIパターンな案件が多いです。)、弊社内も技術に関心はあれど上流工程に興味がある社員はいないため、ぽつんと一人で勉強し、現状趣味で作成しているソフトウェアに勉強のため、採用しているだけという状況です。
DDDについてもまだまだ、理解できない点、疑問点が多いのでこれからも参考にさせて下さい。
こちらの記事でDDD採用に至った経緯等を読ませて頂いていると、御社ではよく、プロジェクトの振り返りができているのだなと感心させられます。
失敗したプロジェクトでも、即解散してしまい、振り返りがないチームは多いです。
しかし、DDDを採用しようという意識は振り返りから芽生えるものだと思います。日本でなかなかDDDが浸透しないのはこのような状況(振り返りがないチームが多い状況)から来るものではないかなと勝手ながら思っています。

これからも勉強させて頂きます。
  • kime
  • 2009/11/22 9:46 PM
kime さん

コメントありがとうございます。
何かのお役に立てれば、ほんとうれしいです。

おっしゃる通り、振り返りが大切だと思います。
このブログも、振り返りや自戒のために書いている気がします。

私もまだまだ勉強中の身です。

これからもよろしくお願いいたします。
  • masuda220
  • 2009/11/22 11:35 PM
コメントする









この記事のトラックバックURL
トラックバック
calendar
   1234
567891011
12131415161718
19202122232425
2627282930  
<< April 2020 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM