MongoDBドキュメントを表現する最良の方法は何ですか? Product
のサブドキュメントとして を配置しましたClient
。
まず、それらを集約として配置しました。Client
が壊れている場合は、Product
も壊れています。そのモデルを使用しますか、それとも Nesting に切り替えますか。
ネストされたダイアグラムの例:
MongoDBドキュメントを表現する最良の方法は何ですか? Product
のサブドキュメントとして を配置しましたClient
。
まず、それらを集約として配置しました。Client
が壊れている場合は、Product
も壊れています。そのモデルを使用しますか、それとも Nesting に切り替えますか。
ネストされたダイアグラムの例:
プログラミングの観点から (Java など):
参照: http://docs.oracle.com/javase/tutorial/java/javaOO/nested.html
ネストされたクラスは、静的クラスと非静的クラスの 2 つのカテゴリに分類されます。静的と宣言された入れ子になったクラスは、単に静的な入れ子になったクラスと呼ばれます。ネストされた非静的クラスは内部クラスと呼ばれます。
class OuterClass {
...
static class StaticNestedClass {
...
}
class InnerClass {
...
}
InnerClass innerObject = new InnerClass();
}
OuterClass.StaticNestedClass nestedObject = new OuterClass.StaticNestedClass();
UML の観点から:
名前空間からのクラスの一般化
Class--|>EncapsulatedClassifier--|>StructuredClassifier--|>Classifier--|>名前空間
名前空間には「member」と「ownedMember」があります。
/member : NamedElement [0..*]
/ownedMember : NamedElement [0..*]
「member」は「StaticNestedClass + InnerClass」を表し、「ownedMember」は「InnerClass」のみを表します
一般的な提案:
作図はどうする?
協会または構成
それは本当にあなたの要件に依存します。
ほとんどの人は、「破壊」プロセスから「構成」を説明するのが好きです。「全体」が破壊され、「部分」も破壊されました。
ただし、「構築」プロセスから記述することは常に有効です。その過程で「全体を新しくする」、「部分を新しくする」。「構築」と「破棄」を一貫させることをお勧めします。
例: 車と車輪。
誰かが次のクレイジーなコードを書いた場合、WOW..
class Car{
public:
Wheel* w1;
Wheel* w2;
Car(Wheel* w1_, Wheel* w2_)
{
w1 = w1_;
w2 = w2_;
}
~Car()
{
delete w1;
delete w2;
}
}
Wheel* l1 = new Wheel();
Wheel* l2 = new Wheel();
Car* myCar = new Car(l1, l2);
delete myCar;
l1->Operation1(); //Crash!
したがって、構築と破棄が一貫していないため、これは実際の「構成」ではありません。デストラクタから「delete w1;delete w2」を削除すると、Car と Wheel の関係は「Association」になります。
コンポジション版のコードは次のようになります。
class Car{
public:
Wheel* w1;
Wheel* w2;
Car()
{
w1 = new Wheel();
w2 = new Wheel();
}
~Car()
{
delete w1;
delete w2;
}
}