<< 複雑さと戦う : ソースコードの破綻の兆候 | main | 複雑さと戦う : 基本データ型 vs 小さなオブジェクト >>

複雑さと戦う : データに注目したリファクタリング

ドメインの知識・ノウハウをソフトウェアに盛り込み始めると、ソフトウェアは複雑になってきて、ソースコードが破綻しそうになる。

破綻する前に、日々設計を改良しようというのがリファクタリング。

リファクタリングにもいろいろありますが、まずデータに注目したリファクタリングの例。

ドメインの知識が増えてくると、扱うべき情報・状態・区分が膨らんでくる。
ソースコード中に、String , int , Date など基本的なデータ型がずらっと並びはじめたら、さっそくリファクタリングしよう。

適用できる主なリファクタリングのパターン。

クラスの抽出

ひとつのクラスにたくさんの基本データ型が宣言されていたら、ある部分を別のクラスとして定義する。
私の感覚では、5つもデータフィールドが並んでいたら、十分リファクタリングの対象です。

ひとつのクラスで5つのデータフィールドを扱うのは、恐ろしく複雑な状態の組み合わせを扱う必要がある、ということ。

ファウラー本では、 Person クラスから TelephoneNumber クラスを抽出する例で説明している。

オブジェクトによる配列の置き換え

String の配列で、第1要素が氏名で第2要素が住所、というような約束事。
name フィールド と address フィールドを持ったクラスに設計を改良する(リファクタリングする)

ファウラー本では、配列で「チーム名、勝、負」をあらわしているのを、Performance クラスにリファクタリングする例で説明している。

コレクションのカプセル化

コレクションをそのまま返すのではなく、クラスにカプセル化して、コレクションに対する操作を限定する。
コレクションという汎用的なデータ構造ではいろいろなことができるけど、本来は、ある意味を持った操作以外でやる必要がない。
そういう用途が明確なクラス(のインタフェース)を用意することで、コレクションをあちこちからいじりまくる、プログラムの複雑化を防ぐ。

ファウラー本では、講座( Course ) を、Set として返すのでは、 Courses クラスとしてカプセル化したオブジェクトを新規に設計している。

データクラスによるレコードの置き換え

レコード形式(構造体形式)の情報を扱うために、データ項目をそのまま並べたクラスを設計する。データのかたまりを見つけたら、とりあえずクラスにしておきましょうシリーズのその1です。

ファウラー本では例はありませんが、意図は明確。 このようなデータだけのオブジェクトが、次のリファクタリングの足がかりになる点がポイント。

引数オブジェクトの導入

複数の引数が一組で使われることを発見したら、クラスにする。
データのかたまりを見つけたら、とりあえずクラスにしておきましょうシリーズのその2です。

ファウラー本では、引数に ( Date start, Date end ) が繰り返しでてきたら、DateRange クラスを作る例で説明している。

・データのかたまりを見つけたら、とりあえずクラスにまとめることを考える
・基本型がならんだら、クラスとしてカプセル化することを考える

コメント
コメントする









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