This is version 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

ユーティリティクラスを作ってはいけない#

ユーティリティクラスと世間で言われるクラスを作ってはいけません。ユーティリティクラスというのは単なる関数やサブルーチンの集まりであり、データ構造を持たないクラスだからです。
ユーティリティクラスというのをもう少し詳しく言うと、「クラス変数にもインスタンス変数にも一切アクセスしないメソッドを集めたクラス」のことです。クラス変数にもインスタンス変数にも一切アクセスしないということは、データ構造を内部に持たないということです。
「クラスとはデータ構造」という原則に、これは明らかに反します。このようなユーティリティクラスを作ってしまうとデータ構造と処理が分離されてしまい、保守性が下がってしまいます。

ユーティリティクラスの弊害については「privateメソッド禁止」の中で詳細に説明しているので参照して下さい。

例外的にユーティリティクラスを許す場合#

例外的にとは書きましたが、このケースは割と多く存在します。一言で言うと、

別メモリ空間で稼働するシステムとの間でオブジェクトが持つデータを受け渡す場合#

です。抽象的な言葉過ぎて解りにくいと思うので例を使って説明します。
上記のように「受注伝票」と「発注伝票」の2つのクラスがあるとします。それぞれのクラスにはメソッドがあります(実際の開発では上記以外のメソッドも必要になります)。
この時、実装すべきクラスは次のように2つです。 ところが良く考えると、

• クラスの属性をRDBに書き込む
• クラスの属性をネットワークに出力する
• クラスの属性をテキストファイルに書き込む

というメソッドは他のクラスにも共通して必要です。システム規模によりますが、最低でも数十、大きい場合は数百のクラスに実装する必要が出てきます。
この3つのメソッドに共通しているのは、データを書き込む先が全て、これらのオブジェクトが稼働しているのとは別のメモリ空間で動いているシステムです。別のメディアと言ってもいいでしょう。

メディア	メモリ空間
RDB	RDBMS
ネットワーク	OS
テキストファイル	OS

このように、別のメモリ空間で稼働しているシステムに対してはオブジェクトの状態で渡すことが出来ません。そのため一旦データ(属性)のみの状態にして相手側のシステムに渡す必要が出てきます。次の図のように、稼働中のアプリケーションと、外部のメモリ空間で動いているシステムとの間でデータのみを投げ合う形です。 この時、

• オブジェクトが持っているデータ構造
• 相手側のシステムとの間で受け渡す処理

の2つが分離されます。この「相手側のシステムとの間で受け渡す処理」をユーティリティクラス(関数)として実装する必要が出てきます。相手に渡せるのはデータのみであるため、そのデータをオブジェクトから受け取って渡す処理、つまり関数が別に必要だからです。
これをクラス図に描くと次のようになります。RDBユーティリティクラスが、受注伝票や発注伝票のデータのみを使ってRDBMSとの間で受け渡しを実施します。RDBMSは、アプリケーションが稼働しているメモリ空間の外にあります。

「層」が増えるほどユーティリティクラスが必要となる#

前項で説明したように、外部のメモリ空間で稼働しているシステムとのやりとりが発生する境界ではデータ構造を持たないユーティリティクラス(関数)が必要になります。これは言い方を換えると、「RDB層」「アプリケーション層」などのような層(Layer)があればその境界線でユーティリティクラスが必要になるということです。
つまりオブジェクト指向的実装を徹底しようとするならば、層は出来るだけ作らない方が良いということになります。次の図を見て下さい。
上の図は、一般的な3層構造アプリケーションの動きを書いています。