場合によっては他の複雑なクラスで構成される、多くのプロパティを持つクラスがあります。この完全なスキーマを常に使用するわけではありませんが、使用することもあります。オブジェクトを作成して処理し、オンデマンドで情報を取得するためのベスト プラクティスは何ですか?
明確にするために非常に簡単な例を挙げています。
classstudentに関連する class があるとしprofessorます。このクラスは 、 などの他のクラスに関連してclassesいschedulesます。常にこの情報をすべて使用する必要があるわけではありません。
教授の ID をオブジェクトstudentで管理し、必要なときに情報をロードする必要がありますか? 教授IDを格納するためだけにプロパティを作成する必要がありnew professorますIDか? それともどちらでもない？ベストプラクティスは何ですか?
ありがとう。
遅延読み込みパターンを使用します。
提案 1
あなたのアプリケーションは、オブジェクトとプロパティの値を保存してロードする必要がありますか (「シリアライズする」または「永続化する」とも呼ばれます)。
あなたのアプリケーションは、同じクラスの複数のインスタンスを持つ必要がありますか?
この質問に対する答えが正しい場合、@larsmans が提案するように、データを DB に保存する必要があるようです。
提案 2
別物。使用しているプログラミング言語については言及していません。C++、Delphi (Object Pascal)、D などのプログラミング言語では、別のオブジェクト内のオブジェクトは、オブジェクトの一部として、またはサブオブジェクトへのポインターとして、2 つの方法で処理できます。
あなたのシナリオでは、オブジェクトアプローチへのポインタを使用することをお勧めします。
Java、PHP、C#、VB.NET などのプログラミング言語には、参照と呼ばれるこの概念があり、実際にはオブジェクトへのポインターと同じであるため、他に何もする必要はありません。
非ポインターの例:
class SubClass
{
public:
int X;
int Y;
}; // class SubClass
class MainClass
{
public:
int Color;
SubClass SubObject;
public:
/* constructor */ MainClass()
{
this.Color = 7;
this.SubObject();
} // /* constructor */ MainClass(...)
/* destructor */ ~MainClass()
{
this.~SubObject();
this.Color = 0;
} // /* destructor */ MainClass(...)
}; // class MainClass
void main()
{
MainClass* MainObject = new MainClass();
MainObject->Color = 5;
MainObject->SubObject.X = 19;
MainObject->SubObject.Y = 32;
delete MainObject();
} // void main(...)
オブジェクトへのポインターの例:
class SubClass
{
public:
int X;
int Y;
}; // class SubClass
class MainClass
{
public:
int Color;
SubClass* SubObject;
public:
/* constructor */ MainClass()
{
this.Color = 7;
this.SubObject = new SubClass();
} // /* constructor */ MainClass(...)
/* destructor */ ~MainClass()
{
delete this.SubObject();
this.Color = 0;
} // /* destructor */ MainClass(...)
}; // class MainClass
void main()
{
MainClass* MainObject = new MainClass();
MainObject->Color = 5;
MainObject->SubObject->X = 19;
MainObject->SubObject->Y = 32;
delete MainObject();
} // void main(...)
乾杯。
一般的なケースでは、ドメインからエンティティに参加するいくつかのエンティティが必要になります。たとえば、StudentRegistry学生とその教授/講師の間の通信を保持するがあります。これは確かにRDBMSスキーマ設計に似ているため、ER DB設計メソッドを参照できます（明らかに、テーブルの代わりにクラスがあります）。
lazy loadingについて説明しているようです。