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メソッド禁止」の中で詳細に説明しているので参照して下さい。

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

次の二つのケースではユーティリティクラスを例外的に許します。

1. メイン関数(メソッド)を持つクラス
2. 別メモリ空間で稼働するシステムとの間でオブジェクトが持つデータを受け渡す場合

例外的にとは書きましたが、これらの事例は割と多く存在します。

メイン関数を(メソッド)持つクラス#

OSがアプリケーションを起動する場合、メイン関数が起点となります。OSは、起動パラメータをデータとしてメイン関数に渡します。この起動パラメータ(データ)とメイン関数(処理)は分離されざるを得ません。そのため例外となります。
メイン関数の中には必要最低限の処理のみを記述するようにし、業務用クラスのインスタンスに処理を早く委譲すべきです。

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

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

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

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

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

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

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

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

Javaの場合、RDBユーティリティクラスの最下層には「JDBCドライバ」(Java Database Connecftion Driver)が配置されます。O/Rマッパ(Object Relation Mapper)がその上位に配置されることが多いのですが、受注伝票や発注伝票などの業務データと切り離されたこれらはすべてユーティリティクラス(関数)となります。
しかし、受注伝票や発注伝票の中に「RDBに書き込む」「RDBから読み込む」ようなメソッドを持ち、その中からRDBユーティリティクラス(群)を利用することによって、受注伝票や発注伝票を扱うアプリケーション側からはデータ構造と処理が一体化されている正しいクラスとして扱えます。次のような形です。

RDBユーティリティクラスとしてO/Rマッパをもし利用すると次のようになります。

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

前項で説明したように、外部のメモリ空間で稼働しているシステムとのやりとりが発生する境界ではデータ構造を持たないユーティリティクラス(関数)が必要になります。これは言い方を換えると、「RDB層」「アプリケーション層」などのような層(Layer)があればその境界線でユーティリティクラスが必要になるということです。次の図を見て下さい。
上の図は、一般的な3層構造アプリケーションの動きのうち、画面の情報をRDBに格納するまでの流れを表しています。層と層の間はオブジェクトをそのまま渡せないため、電文という形でデータを渡しています。電文を受け取るプロセスは各層での処理の起点の役割、つまりメイン関数と同等の機能を負います。そのため関数にならざるを得ないのです。例外の1番目で書いたのとほとんど同じ理由です。
例えばアプリケーション層の起点ではHTTP電文を受け取ってオブジェクトへと変換します。この動きをメイン関数と比較すれば、起動パラメータがHTTP電文と替わるだけであることが解ります。
結果として、上記のような層分けを出来るだけ行わない方が本来のオブジェクト指向に近づけます。「データと処理の分離」の発生頻度が減るからです。