3

私のプログラミングには何かが現れ続けています. 同様に、列車で接続された鉄道駅のグラフを作成すると想像してください。クラス Vertex と RailStation は同じ場合もあれば、そうでない場合もあります。

では、鉄道駅と列車を非常によく表しているグラフがあるとします。次に、このグラフを別のオブジェクトに渡し、いくつかの頂点を削除してから、対応する鉄道駅を削除します。

鉄道駅を頂点の「プロパティ」にしたくありません。そうではありません。また、問題は対称的です。鉄道駅を消去すると、対応する頂点が消えてしまいます。モデル化または通信の適切な OO の方法は何ですか。最終的に全体的な使用法が単純で簡単であれば、いくつかのサポート メソッドまたはクラスを作成することによって、さらに数マイル進んでいきます。

私は現在 Smalltalk プログラミング言語を使用していますが、質問は実際には smalltalk 固有のものではないと思います。Smalltalk では、コール スタックを調べるなどのクールなトリックを実行できるため、このコンテキストで役立つ可能性があります。

更新: まあ、RailStations は頂点ではありません! 彼らは？

わかりました、答えで要求されているように、実際のコードを考えてみましょう。子供がいる人をモデルにしましょう。それが一番簡単ですよね？子供も親を知っている必要があるため、二重にリンクされたツリーのようになっています。子から親を簡単に分離できるようにするために、親と子の間のリンクを、親と子のプロパティを持つリレーションシップとしてモデル化します。

だから、私はparent>>removeChildを実装することができました：おそらくこのように

removeChild: aChild
    (parent relationshipWith: aChild) disband.

したがって、親には、子ではなく関係のコレクションがあります。しかし、それぞれの関係は子供に対応しています。今、私はこのようなことをしたい:

parent children removeAllSuchThat: [:e | e age < 12]

関係と子供を削除する必要があります。

ここでは、人間関係と子供はある意味で対応しています。それで、私は今何をしますか？誤解しないでください。Relationship クラスを導入しなくても問題を解決できることは十分承知しています。しかし、確かに、親と子は実際に関係を共有しているので、それをモデル化し、それを使用して、二重リンクを無理なく解消するのに役立ててみませんか?

4

5 に答える 5

3

あなたの問題領域では、ステーションは一種の頂点ではありませんか? その場合、ステーションを頂点から派生させてみませんか?

「問題のドメインで」というフレーズの使用に注意してください。あなたの問題は、グラフに表示される鉄道駅としての使用に関するようです。そうです、そのドメインでは、ステーションは頂点です。それが別の問題領域、たとえば鉄道駅の建築に関するデータベースであった場合、そうではない可能性があります。最新の言語のほとんどは、名前空間の概念をサポートしており、異なるドメインで同じ名前を持つさまざまな種類のエンティティを使用できます。

あなたの親子の問題については、またしても一般的すぎます。数式と部分式をモデル化している場合、親を削除すると、すべての部分式を削除/解放する必要があります。OTOH, ff 私は英国の人口における法的責任関係をモデル化していましたが、責任が解消された場合 (たとえば離婚のために)、関係を削除したいだけで、独自の独立した存在を持つ子供を削除/解放したくはありません。 .

于 2009-05-22T07:24:54.363 に答える
2

RailStation が Vertex から継承したいだけのようです (is-a リレーションシップ)。継承に関するこのsmalltalk チュートリアルを参照してください。そうすれば、RailStations のグラフがある場合、頂点のグラフを (一般的に) 処理することに慣れているオブジェクトは、物事を自然に正しく処理します。

このアプローチが機能しない場合は、より具体的に (できれば実際のコードを使用して) ください。

于 2009-05-22T07:25:03.037 に答える
2

問題の説明から、ステーションと頂点は 1 対 1 で対応しており、ステーションを削除すると、対応する頂点が自動的に削除されます (逆も同様です)。また、「列車で接続された鉄道駅のグラフ」の作成についても言及しましたが、これは、駅が頂点で列車が辺であるグラフを意味しているようです。

では、ステーションがどのように頂点ではないのでしょうか? ステーションが頂点としてしか存在せず、頂点がステーションとしてしか存在しない場合、それらを 2 つの別個のリンクされたエンティティとして維持することにはどのような利点がありますか?

あなたの状況を理解しているように、station-isa-vertex と継承がそれをモデル化する方法です。

于 2009-05-22T08:14:00.490 に答える
1

Relationship オブジェクトを持つことは良い考えです。

ここでの適切な質問は、「それをどのように使用する必要があるか」であると思います。

おそらく、親クラスと子クラスは同じ Person スーパークラスを拡張しているため、年齢などの共通の属性がいくつかあります。

私の考えでは、次のことがわかります: 親オブジェクトと子オブジェクトはお互いを認識している必要があるため、両方のクラスが同じリレーションシップへのリンクを維持する必要があります。Relationship オブジェクトは、1 人の親と特定の数の子の間の 1 対多の関係を保持し、各 Person オブジェクトへの参照を保持します。

このようにして、必要に応じて多かれ少なかれ洗練された、Relationshiphp オブジェクト内に解散ロジック全体を実装できます。Relationship オブジェクトをクエリして、家族のどのメンバーが要件に一致しているかを知ることができます。リレーションシップを安全に解散 (および破棄) することができます。これは、すべてのメンバーを認識し、参照を解除するように要求するため、破棄する準備ができているか、リレーションシップ オブジェクトを保持したまま、一部のメンバーに家族を離れるように要求するためです。生きている。

しかし、それだけではありません。Relationship は実際には、HierarchicalRelationship および PeerRelationship (または FriendRelationship) によって拡張されたスーパークラスである必要があります。

この特殊化により、Parent(s) と Child(ren) を他の階層間で完全にトラバーサルな方法でリンクできます。

この背後にある真の概念は、リレーションシップ オブジェクトが、多数の Person オブジェクト (または Vertex オブジェクト) をスケーラブルで構造化された方法でクエリおよび整理するための鍵であるため、最終的に得られるデータ ドメイン全体があらゆる意味で使用可能であるということです。グループを解散したいのか、グループ間の特定の道（または鉄道）を歩きたいのか。

比喩が多くてすみません。

于 2009-05-22T08:40:14.057 に答える
1

名声を見てみましょう。 http://www.squeaksource.com/Fame.htmlを参照してください。

Collection要素を追加または削除するときに反対側を更新する特殊なサブクラスを使用します。また、リレーションに注釈を付けるプラグマでクラスに注釈を付けることができます。これらのプラグマは、あらゆる種類の優れた処理を行うために Fame フレームワークによって使用されます。

于 2009-06-03T11:54:20.297 に答える