【リファクタリング】「データクラス」について

データクラスは以下のような呼び方をします。

データクラスの特徴

• getter、setterというメソッドのみを持つ。
• ロジックは機能クラス（ロジッククラス）で記述する。

データクラスと機能クラスを分けることでの問題点

データクラスと機能クラスを分けるのは手続型の設計と言われます。それには以下のような問題点があります。

同じ業務ロジックがあちこちに重複して書かれる。

データクラスを参照できる場所であれば、どこにでもロジックが書けてしまうのでロジックが重複する形となってしまいます。

具体的に言えば、画面のプレゼンテーション層からも、業務ロジックを書くアプリケーション層からも、DBを扱うデータソース層からもどの層からも参照できてしまいます。

では共通ライブラリクラスを作る設計はどうか

それでも、UtilとかCommonとかで共通ライブラリで防ぐ方法もあるでしょう。

汎用化した共通関数の落とし穴

ただ、汎用化しすぎると引数を増やしたり条件分岐を増やすことになることでしょう。そういうのは誰も使わないことになります。その結果、同じようなロジックがあちこちに書かれることになります。

用途ごとに細分化した共通関数の落とし穴

これも、どれを使えば良いかわからなくなり結局使われなくなります。

では、なぜデータクラスがここまで広まったのか？

従来COBOLやC言語など手続型で書かれたプログラムが基本でした。

それを95年以降オブジェクト指向のJavaで置き換える際に都合が良かったためひろまりました。

J2EEや、StrutsとかのWebアプリフレームワークでもそういう思想が採用されています。