Common関数の問題点
共通化するのであれば、Common関数だったりCommonのConstなどを作ってそこに共通処理を記述すればいけます。
ただ、これには問題点があります。
チームで開発していたら「本当にみんなその関数を呼ぶか」、「本当に統一できるか（同じ作法で使うか）」という話です。
この方法だと開発者によって実装方法がバラバラになる可能性が高いです。
例えば、以下のようなことがおきます。実装がバラバラになり統一感がなくなりバグが混入しやすくなります。
- みんな勝手にクラスを作る。
- 画面に勝手に固定値を定義する。
データクラス
結論から言えばこれは現代ではあまり使わない方が良いと言われています。データクラスは以下のような呼び方をします。
| 名前 | 説明 |
|---|---|
| DTO | サブシステム間でデータをやり取りするための設計パターン |
| Entityクラス | データベースとデータをやり取りするための入れ物 |
| Formクラス | 画面とデータをやり取りするためのデータの入れ物 |
| JavaBeans | 開発ツールやフレームワークなどでデータアクセスする際に使用するクラス |
データクラスの特徴
- getter、setterというメソッドのみを持つ。
- ロジックは機能クラス（ロジッククラス）で記述する。
データクラスと機能クラスを分けることでの問題点
データクラスと機能クラスを分けるのは手続型の設計と言われます。それには以下のような問題点があります。
同じ業務ロジックがあちこちに重複して書かれる。
データクラスを参照できる場所であれば、どこにでもロジックが書けてしまうのでロジックが重複する形となってしまいます。
具体的に言えば、画面のプレゼンテーション層からも、業務ロジックを書くアプリケーション層からも、DBを扱うデータソース層からもどの層からも参照できてしまいます。
では共通ライブラリクラスを作る設計はどうか
それでも、UtilとかCommonとかで共通ライブラリで防ぐ方法もあるでしょう。
汎用化した共通関数の落とし穴
ただ、汎用化しすぎると引数を増やしたり条件分岐を増やすことになることでしょう。そういうのは誰も使わないことになります。その結果、同じようなロジックがあちこちに書かれることになります。
用途ごとに細分化した共通関数の落とし穴
これも、どれを使えば良いかわからなくなり結局使われなくなります。
では、なぜデータクラスがここまで広まったのか？
従来COBOLやC言語など手続型で書かれたプログラムが基本でした。
それを95年以降オブジェクト指向のJavaで置き換える際に都合が良かったためひろまりました。
J2EEや、StrutsとかのWebアプリフレームワークでもそういう思想が採用されています。
コードには２種類ある。
呼ぶ側
画面のコードなど呼ぶ側のコードのことです。こちらに知識を持たせてはいけないです。
呼ばれる側
共通化されたコードのことです。知識はここに持たせるようにしましょう。
オブジェクト指向を使った改善
基本的には「呼ばれる側」をオブジェクト化して実装するのが昔から良いとされています。
値とロジックは分離しない
もし、分離するとプログラマーが別々の場所にあるcommonConstとcommonFunc、データクラスと機能クラスをセットで使うことをずっと覚えておかなければならなくなる。以下のものを使って実装すると良い。
ValueObject
加工処理やエラー制御などはこれを使えば済むようにする。
この記事へのコメントはありません。