前職では、プログラム処理のほとんどは DB に保存された永続データに依存していました。
そのため、DB データ モデルがランタイム プログラムのデータ構造をリードしました。したがって、主キーの値を他のオブジェクトへの参照として使用することは非常に便利でした。
例えば :
1 - 本などの商品をインターネット経由で顧客に販売する会社があるとします。Book、Order、Customer の 3 つのクラスがあります。
Book クラスには、書籍に関するさまざまな情報と、ISBN 番号などの一意の識別子が含まれています。
Customer クラスには、電子メール アドレスなど、本を顧客に発送するために会社が知る必要があるすべてのデータ (および通常はさらに多くのデータ) が含まれます。顧客オブジェクトには、それらを識別する一意の永続 ID もあります。
したがって、Order クラスには 2 つのリレーショナル参照
int isbn;
(本の ID) とint customer_id;
この例の場合、注文クラスのメソッドは顧客データや書籍データにアクセスする必要がないため、注文クラスはそれらに依存する必要はありません。
2 - 注文の確認メールを作成して送信するために使用される別のクラスを考えてみます。
class OrderMailer
{
// Customer index
std::map<int, Customer *> customers;
...
// we have a function that send email with low level parameters
void sendEmail(const std::string& mailAddress, const std::string& body);
// and we have another method that simply sends the email for a given order
void sendEmail(const Order& order);
};
sendEmail(const Order& order) メソッドは、顧客の電子メール アドレスを取得する必要があるため、その識別子からオブジェクトを取得する必要があります。
そのため、マップがあり、アドレスはそのようにアクセスされます
const std::string& target = customers[order.customer_id]->emailAddress; // not found test omitted for reading.
それがアイデアです。
質問部分:
私は数年間、「それは本当に良い考えなのか」と自問せずに、この参照方法を使用しました。理由は次のとおりです。
オブジェクト/レコード ID は、会社内のオブジェクトを識別する方法でした
どこでも使用されるそのような永続的な ID (コード、ログ、他の IT との議論)
ランタイム データ構造は常に DB データ モデルを反映していました (確固たる議論ではないかもしれませんが、DB の世界とランタイムの世界 (c++、python、js) を切り替えるときに非常に役立ちました)。
私はもうこの会社にはいませんが、永続的な記録を扱うときはこのプログラミング方法を続けていました。
私たちは何をしましたか?
言語によって提供されるものを使用する代わりに、オブジェクトを参照する論理的な方法を使用しました: ポインターまたは c++ 参照。そう言われると、すごく気持ち悪いです。
私の観点から、この「方法」を使用することの長所と短所のリストを次に示します。
長所:
- 基礎となるリレーショナル データ モデルがある場合、実行時のデータ構造はデータ モデルを反映し、理解しやすくなります。
- これにより、クラスの無用な結合が回避されます (例では、Order は Customer および Book クラスに依存しません)。
- 一意の識別子は、非常に読みやすい文字列にすることができます
短所:
- これを行うためのポインターと参照である言語の基本的な基本機能を使用しないのはなぜですか? それは悪いアプローチに聞こえます。
- 論理的に参照されるオブジェクトのデータにアクセスするたびに、辞書/インデックス (マップ) を使用する必要があります
前述のように、これが論理/リレーショナル参照を使用するのが良いことかどうかはわかりません。このアプローチを使用するかどうかを決定するために適用できるルールはありますか? これについてご意見をお聞かせいただければ幸いです。