オブジェクト指向で入力値チェック

質問

Webサービスの会員登録とか、CSVを手入力したものをインポートする場合について教えてください。
入力について一定のルールを満たす必要があります。
その場合に入力値チェックをするためにどのようにクラスを作ればいいか悩んでいます。

例えば
・氏名
・メールアドレス
・パスワード
・年齢

のような情報をチェックするとして、初めて登録する際と一度保存したデータを再利用する際はチェック項目が違うように思えます。
そもそも一度チェックした値なので再利用の際はチェックの必要はかなり限定的でいいと考えています。

となると、作成するクラスは一時的な保持クラスを作って、そこでデータ型とかルールをチェックするようにすればいいのでしょうか。
それともデータクラスに入れる前に正規表現などでチェックしてそのまま放り込めばいいのでしょうか。
UserCreate ←これに一時的に入力データを入れる
User ←チェックしたらこっちに入れて保存する
Validator ←これがチェック用クラス

ただこういう一時的な保持クラスは無駄な感じもして悩んでいます。
ちょっとうまく質問も書けないのですが、なんとかヒントを頂けないでしょうか。
よろしくお願いします。

回答No.3

weavaest

部分的に抜粋して、こんなクラス、あんなクラスって話をしても、それでもいいけど違うやり方もできる程度の答えしか得られないと思います。

「UserCreate」「User」「Validator」の役割を書かれてますが、他にどんなクラスがあって、どう関わってくるのかが重要だと思います。Webサービスの全体像や他のクラスの粒度も考慮して、ユーザーを管理する部分を設計すす必要がると思いますから、こういったサイトでの質問は難しいと思います。

例えば、Varidationを行う方法をValidatorクラスという独立したクラスにするのか、　Userクラスの新規登録メソッドでチェック処理を行うのかって選択肢があると思います。User以外にも入力チェックがありValidatorを他でも使いたい場合や、Validatorのスーパークラスがある場合であれば、Validatorクラスを作りますが、そうでもなければ登録メソッド内で入力チェックを行う設計を選ぶかもしれませんよね。こういった場合の設計の決め手は、クラスを取り巻く他の要素だと思います。

回答No.2

noname#247307

漠然としすぎていてかなり抽象的な回答しか書けませんが……。これは、CSVのデータファイルがデータの元本となる、と考えればいいんでしょうか。とすると、一般的には、おそらくこんな感じでは。

・エンティティクラス
「氏名、メールアドレス、パスワード、年齢」といったフィールドを持つクラスを用意し、これを利用してデータを扱います。コンストラクタにはバリデーションの処理を用意し、インスタンスを作成する際に全値をチェックしてインスタンスが作成される、というようにします。

あるいは更に確実にするなら、インスタンス生成のクラスメソッドを定義し、その中でバリデーション処理をする。そしてコンストラクタをprivateにし、newできないようにする、というやり方もあります。そうすることで、必ずインスタンス生成メソッドを呼び出さなければインスタンスが作れないようにし、「すべてのインスタンスがルールをクリアしている」ということを保証できるようにします。

・マネージャクラス（O/Rマッピング）
これとは別に、CSVなりの元データ（元本となるもの）とエンティティクラスのインスタンスの間の橋渡しを摺るクラスを作成し、すべてのデータ処理はこれを介して行います。例えば、「エンティティの内容を書き換えたらCSVの該当するデータを書き換える」「エンティティを破棄したら該当するCSVのデータを削除する」というようなメソッドを定義していくわけですね。データの更新処理では、インスタンス生成と同様にバリデーションします。

あるいは、エンティティクラス自身にマネージ処理のメソッドを実装してしまってもいいですが、個人的にはエンティティが膨れるのはキライなので私なら切り分けるでしょう。

この２つのクラスを基本として、全てのデータは「エンティティのインスタンスを作成して利用する」「データ改変はマネージャクラスを介して行う」というようにすれば、データの整合性も取れます。作成したエンティティのインスタンスは、コレクションなどでまとめて扱えばいいでしょう。

ただ、個人的な意見を言わせてもらうなら、CSVデータをSQLデータベースに移して、一般的なO/Rマッパーのフレームワークを利用したほうが楽かな？という気もします。

回答No.1

catpow

「オブジェクト指向」、あるいは「クラス」というのは、「銀の弾丸」「黄金の金槌」ではありません。

一時期は、Ｊａｖａの流行とともに「オブジェクト指向で作れば、プログラミングの問題がすべて解決し、開発時間が短くなり、バグも出にくく、修正も楽になる！」なんてデマが飛び交い、あまつさえ「ＪａｖａがＣ＋＋を駆逐する！！」なんてことを主張する方までいました。

まあ、オブジェクト指向とかクラスがあれば！っていうのは、「宗教」に近いものかもしれません。

オブジェクト指向って、システムの概念設計、基本設計というか、ラフスケッチなどには役にたちますが、質問者さんが作成されたいと望むような具体的なプログラムを設計する場合には、あまり役にたちません。
実際に、「オブジェクト指向でやれば、開発が楽になる！」と信じて始めたけど、現実には開発工数が肥大化し、開発期間が増大したケースが多かったですし、数億円のプロジェクトが完成したシステムを「使えねー！修正もできない！」として破棄したことさえあります。

それよりも、「アルゴリズムとデータ構造」というタイトルの本があるように、どういうアルゴリズムで作るか？ロジックをどう組み立てるか？という古典的な「構造化プログラミング」（ＩＦやＣＡＳＥ文とＷＨＩＬＥなどのループ文）と、サブルーチンや関数などのルーチンの階層構造（段階的詳細化）と、データ構造をどう作るかということを考えましょう。

誤解を恐れずに例えれば、犬小屋を日曜大工で作るとき、小屋のデザイン的なところにだけ注目しているのがオブジェクト指向。
でも、実際に犬小屋を作るのに必要な技術は、それぞれの部材の寸法を記載した設計図であり、木をまっすぐに切る技術、釘やネジで板を接合する技術であり、板が雨に耐えるようにする塗装の技術であり、これらを学ばない限り、いくらオブジェクト指向を勉強しても、犬小屋は完成しません。

正しい宗教・信仰であれば、「この教えさえ信じれば、貴方は幸福になります！」という教えに従ってもいいかもしれません。
でも、第三者からみて「あの人、幸せそうじゃあないね」という信者が多ければ、それは正しい宗教とはいえません。

自分の信じる信仰を破棄したほうが、楽になれることも多いものですよ。