オブジェクト指向のCRUDプログラム - オブジェクト指向設計の理由は何ですか？

Question

まず第一に、誰も私の任務を遂行したくありません。私は、実装を依頼されたデザインのポイントを理解できません。方法の1つが私に重複しているように見えます。誰かがそれに光を当てることができるのだろうかと思います。

私は、追加、削除、更新、およびクエリの4つのメソッドを持つStudentクラス（およびサブクラス）を作成する必要があります。これらのメソッドを使用してデータベースを更新できる必要があります。たとえば、add（）メソッドの仕様は次のようになります。

このメソッドを呼び出すと、その学生のデータベースエントリが作成されます。

GUIに入力された情報が正しくない場合、私はStudentクラスにいくつかのセッターメソッドを持たせることができます。 GUIとこれらを表示することができます。したがって、クラスは情報を検証するのに便利です。更新メソッドと削除メソッドも同様です。このメソッドが呼び出されると

は、クエリが情報を取得するためにデータベースに対して行われた後、画面に出力されます。私は本当に迷惑です

事がquery（）メソッドです。

Studentクラスにはquery（）メソッドがあります（また、これを継承するサブクラスもあります）。しかし、データベースを照会するには、すでにインスタンスを作成しておく必要があります。そのため、クラスを作成するための情報を取得するためにデータベースを照会しているので、toString（）メソッドを呼び出すだけで私はクラスのデータを表示するためにオーバーライドしました。

私は、各Studentインスタンスがquery（）メソッドを持っている点が、使用するために冗長になることはありません。なぜこれが役に立つのか誰にでも教えてもらえますか？

おかげ

更新答えみんなに

感謝。私は、通常、データを保持するオブジェクトと、そのデータを使用または使用するオブジェクトとの間に懸念があるはずであるという事実を乗り越えます。

私の割り当てでは、クエリメソッドはデータベースにクエリを実行し、その情報を画面に表示する必要があることを示しています。私はこれを静的メソッドにして、学生の名前や何かを引数に渡すと、実際にデータベースにクエリを行い、その情報でStudentインスタンスを作成して表示できると思います。それは一度だけ呼び出されるという点で少なくとも私には意味があるので、冗長性はありません。

Answer 1

まずオフ：Studentクラスは両方値ホルダーと読み込み/保存を処理するクラスであれば、私はそれが非常に悪いデザインを検討したいです。 single responsibility principleに違反しています。私はこれが宿題であると仮定して、この部分を今見落としています。同じ問題がquery()メソッドに存在します。明らかな理由がないために2つの責任があるようです。

（あなたは親切-のここでやっている）オブジェクトリレーショナルマッパーを書くとき、それは多くの場合、あなたは「半復元された」オブジェクトを持っている場合である：あなたがを知ってオブジェクトは、データベース内に存在しなければなりません主キーを知っている（たとえば、別のオブジェクトにそのオブジェクトへの参照があるため）。

この場合、実際のデータをロードする方法が有用な場合があります。

Answer 2

これは有用ではなく、誰もそのようにすることはできません。 A Studentは持続可能なエンティティですが、他の一部のコンポーネントは、それらのエンティティの作成、読み取り、更新、または削除を担当します。

多くの場合、我々は、CRUDの事業を行うデータ転送オブジェクト（値ホルダー、*エンティティBean、あなたのStudent）と工場で構成されてデザインを参照してください。

のqueryメソッドから何を期待していますか？私は、学生が自分の研究のためのより多くの情報を得るために実行する何らかのクエリを期待しています。

Answer 3

この目的は、Studentオブジェクトを学生レコードと密接に関連付けるべきではないということです。私は空であり、一意のIDをまだ持っていない新しいStudentオブジェクトを作成することができるはずです。

システムにまだ存在しない新しい生徒を作成したい場合は、必要なデータを提供してadd()またはinsert()というメソッドを呼び出してから、これを永続化します。同様にStudentオブジェクトを作成してquery()を呼び出すと、オブジェクト値はすべてフェッチされたStudentレコードの結果に置き換えられると想像します。

ここで他の人が指摘したように、エンティティ自身が内部にCRUD機能を持たせるバリューホルダーの普及した慣行とは考えられていません。これは必ずしもこれが本質的に間違っていることを意味するわけではありません。 OOPでは、オブジェクトはそれ自身に関連するすべての機能を持つ必要があり、現在普及している典型的なORM/Persistence Framewok Beanと比べてEJB EntityBeanに似ています。

他の回答が述べたORM/Persistence Frameworkは、Martin Fowlerのような特定のOOPエバンジェリストが告知する貧血データモデルと呼ばれています。 http://martinfowler.com/bliki/AnemicDomainModel.html