第三者図書館で間違いなく設計上の決定が間違っているのを修正する必要がありますか？

Question

私のプロジェクトにはQt plusと無名の第三者の物理シミュレーションライブラリが含まれています。物理ライブラリが動作する仕組みは、物理的なボディがそれを作ることができないということです。 「世界」はそれらをインスタンス化して、すぐに世界に追加できるようにする必要があります。

私のプロジェクトでは、これらの物理的なボディの周りにいくつかの機能を追加するためのラッパーを作成しますが、これらの物理的なボディを格納するため、インスタンス化することもできません。最初の質問は、これらの身体を自分たちの上に立たせることがより理にかなっているかということです。私が厄介なことに気づいた部分は、オブジェクトを世界に渡すより意味があるときに、それを作成できるように、オブジェクトへの参照をオブジェクトに渡さなければならないということです。

これを修正するには、ワールドラッパーに追加されるまでサードパーティの本体の作成を遅らせることができます。しかし、それは私の世界ラッパーが身体を正しく初期化することを担当することを意味します。それはまた、私が実際にオブジェクトに追加されるまで、オブジェクトのプロパティにアクセスすることができないということです。なぜなら、それらはすべて、サードパーティのボディに依存しているからです...私は、そのデータをすべて複製してから、ライブラリが追加されたときにライブラリに追加します。

私のボディラッパーを作成できるように、私はワールドラッパーにポインタを渡し続けるだけですか？

Qtグラフィックスフレームワークの仕組みは、いつでもQGraphicsItemsを作成できるということです。それらは自分の上に立つことになりますが、シーンに追加するまで表示されません。ここでの類推は、GraphicsItem == Body、Scene == Worldです。

Answer 1

ファサードパターン（ラッパー）は、ファサードのユーザーから実装の根本的な詳細を隠す必要があります。これは、データ転送オブジェクトを使用してデータを保持することを意味します。ファサードは実装するのが面倒かもしれませんが、エンドユーザーに影響を与えずに基礎となる実装を変更することができます。

sudoのコード：

Rock rock = new Rock(100); //simple data container for now. 

PhysicsFacade f = new PhysicsFacade(); //internally creates world. 

f.DoSomething(rock); //internally rock's data used by world to create an equivalent object which is attached to the rock data container for future use. 

Answer 2

はすべての私のゲッターとセッターは基本的にチェックする必要がある「体がまだ初期化されました？」

Qtを使用している場合は、C++を使用しているとします。

私はQtを知らないのですが、なぜあなたは既存のメカニズムを変更したいのか分かりませんが、とにかく：C++で行うことができる便利なことは、->オペレータがアクセスするためにオーバーロードされていることですあなたのオブジェクト。

World& getWorld(); 

class Body; 

class MyWrapper 
{ 
    Body* m_body; 

public: 

    MyWrapper() : m_body(0) {} 

    Body* operator->() 
    { 
    if (!m_body) 
    { 
     m_body = new Body(getWorld()); 
    } 
    return m_body; 
    } 

    ... etc ... 
}; 

---

編集

：誰かが->オペレーターを呼び出すと、それは既にインスタンス、何かなどをbeeinていない場合、オペレータは、ジャストインタイムオブジェクトを作成することができます「既存の仕組みを変えよう」という意味ですか？物理学ライブラリがレイアウトしたもの？私は私の理由を述べたと思う。

はい。

あなたの解決策では... getWorld（）は何をしますか？それはグローバルな機能ですか？世界がグローバル空間に浮かんでいる場合、実際には問題はありません。MyWrapperがインスタンス化されると同時にボディをインスタンス化できます。

はい、物理ライブラリ内にボディを作成するために必要な、ワールドへの参照を返します。それは一例です、私はどこからあなたの世界の参照を取得しているか分からない。

しかし、 - >演算子が使用される時点でまだ世界が存在しない場合はどうなりますか？私は本当にこれが何かを解決するかどうかは分かりません。一つの方法または別のは、あなたはまだそれは早すぎると呼ばれていた場合多分getWorldが例外をスローします

体を世界に渡していることは言うまでもありません。とにかく、何これはあなたを買うことになっていたました：世界が作成される前に、おそらく世界の参照せずにMyWrapperインスタンスを作成し、する

• 能力。

• ボディインスタンスジャストインタイムクライアントは、ボディのpropetiesまたはメソッド

のいずれかにアクセスするためにtryied作成する機能は - >演算子は、クライアントがで取得するために使用してしまうものですあなたが包み込んでいる物理的なボディ： "スマートポインタ"のように。

擬似コードで問題を説明すると、問題の解決方法を理解しやすくすることができます。一つの方法または別のは、あなたはまだ

体を世界に渡しているあなたはそれが根底にあるライブラリーの要件と述べたことは言うまでもありません

。 「修正する必要がありますか」と言いましたが、「ラッパーに別のAPIを実装し、私の実装で既存のAPIを隠す必要がありますか？既存の実装を変更する（ラップだけでなく）ことを試みるかもしれないということは私には起こりませんでした。

Answer 3

私の回答を共有する前に、いくつかの名前を変更してください。 "オブジェクト"は、 "物理学のボディ"を保持するものです。 「世界」は「物理世界」を保有するものです。ここでも、「物理学の世界」だけが「物理学の本文」を作成できます（そのコンストラクタは非公開です）。

ここに私が行ったことがあります。 Objectは、単に物理ボディへのポインタを保持しています。あなたが望むときにいつでもオブジェクトを作成し、世界を必要とせずにすべてのデータを再生することができます...物理学のボディに直接関連するプロパティに触れることはできません（私はこれをASSERTにします）。

世界は、世界に追加されるとすぐにオブジェクト（すなわち物理学のボディ）をインスタンス化します。これはおそらく世界がいくつかのオブジェクトバリバリを操作しなければならないので（私はそれを友人にしました）、OOPのちょっとした問題を壊してしまいますが、私はそれが悪事だと思っています。