0

私のプログラムのメインクラスはOrderBook在庫があります。

  • 私のプログラムの一部、それを呼びましょう、いくつかの株NYSE Connectorからデータを読み取り、いくつかの株NYSEを構成しますOrderBook
  • LSE Connector私のプログラムの2番目の部分では、他の株の構成OrderBookでもありますが、異なる取引所からのものであり、完全に異なるアルゴリズムによるものと呼びましょう。
  • 私のプログラムの3番目の部分は、すべてのセットを管理し、OrderBookさまざまなコネクタにさまざまな信号を生成します（LSEでそのような株を購入し、NYSEで別の株を販売するなど）

私のプログラムのすべての部分は、の同じインスタンスを共有していますOrderBook。しかし、パーツ自体はかなり独立しています。たとえば、NYSE Connector他に何も実行せずに実行できます。それなら集めOrderBookます。あまり意味がありませんが、可能です。

また、1ミリ秒でも非常に重要なので、できるだけ早く動作するためにすべてが必要です。

だから今はすべてを1つのプロジェクトに（ただし異なるフォルダーに）配置しただけですが、あまり良くないと思います。別のコネクタが必要な場合は、別のフォルダを作成します。

どうすれば部品をより適切に分離できますか？OrderBookただし、同じインスタンスを共有する必要があることを忘れないでください。

4

1 に答える 1

2

これは漠然とした質問なので、これは漠然とした答えになります。あなたの名前（javapowered）に基づいて、私はあなたがJavaのバックグラウンドから来ていると仮定します。そのため、Javaの同等性の観点から私の答えを説明しようとします。

.NETでは、コンパイルされたコードの単位はアセンブリです。ソリューション内の各プロジェクトの出力は、通常、正確に1つのアセンブリです（常にではありませんが、説明のために、1つだけであるとしましょう）。アセンブリは、コンパイルされたクラスのバイトコードが含まれているという点で、Javajarファイルとほぼ同じです。それらは実際にはjarファイルよりもかなり洗練されていますが、それは多かれ少なかれこの答えとは無関係です。

アセンブリには、他のアセンブリへの参照（読み取り：依存関係）を含めることができます。Javaの暗黙的なクラスごとの依存関係とは異なり、.NETアセンブリの依存関係は明示的であり、アセンブリレベルです。たとえば、アセンブリfoo.barはアセンブリfoo.batに依存します。.NETアセンブリ参照は、有向非巡回グラフである必要があります。つまり、アセンブリAがBに依存し、BがAに依存するループを作成することはできません。ランタイムは、アセンブリのすべての依存関係をロードできる必要があります。

あなたの場合、私が期待するのは4つ以上のプロジェクトです。

  1. メインプロジェクト。おそらくあなたの実行可能ファイル。これには、他のすべてのプロジェクトへの参照が含まれます（依存します）。
  2. 図書館プロジェクト。これには、ソリューション内の他のプロジェクトへの参照はありません。
  3. ライブラリプロジェクトを参照するNYSEのコネクタプロジェクト。
  4. ライブラリプロジェクトを参照するLSEのコネクタプロジェクト。

すべてのプロジェクト（OrderBook、その他のデータ構造など）に共通するすべてのクラスはライブラリに格納され、必要な場所からどこからでも参照できます。

すべての取引所固有の実装は、独自の取引所固有のアセンブリに組み込まれます。これには、Exchange固有の、のサブクラスなどのプロトコルハンドラが含まれる場合がありますOrderBook。交換に固有の場合は、上記の3または4になります。

最後に、すべてのユーザーインタラクションロジック、制御フローなどがメインの実行可能ファイルに入ります。

于 2012-05-23T18:35:19.407 に答える