7

私は初心者/中級のPythonプログラマーですが、アプリケーションは作成しておらず、スクリプトのみを作成しています。私は現在、オブジェクト指向のデザインをあまり使用していないので、このプロジェクトが私のOODスキルの構築に役立つことを望んでいます。問題は、デザインの観点からどこから始めればよいかわからないことです（オブジェクトなどを作成する方法を知っています）。その価値については、私も独学で、正式なCS教育は受けていません。

ポートフォリオの株式/オプションのポジションを追跡するプログラムを書いてみたいと思います。

何が良いオブジェクト候補（ポートフォリオ、ストック、オプションなど）とメソッド（購入、販売、更新データなど）になるかについて大まかな考えがあります。

ロングポジションは買いからオープン、売りからクローズになり、ショートポジションには売りからオープン、買いからクローズになります。

portfolio.PlaceOrder(type="BUY", symbol="ABC", date="01/02/2009", price=50.00, qty=100)
portfolio.PlaceOrder(type="SELL", symbol="ABC", date="12/31/2009", price=100.00, qty=25)
portfolio.PlaceOrder(type="SELLSHORT", symbol="XYZ", date="1/2/2009", price=30.00, qty=50)
portfolio.PlaceOrder(type="BUY", symbol="XYZ", date="2/1/2009", price=10.00, qty=50)

次に、このメソッドが呼び出されたら、どのように情報を保存しますか？最初は、Symbol、OpenDate、OpenPriceなどの属性を持つPositionオブジェクトがあると思いましたが、売りと売りが異なる時間と金額で発生するため、売り上げを考慮して位置を更新することを考えるのは難しいです。

  • 100株を購入して、1回、1つの価格でオープンします。4つの異なる時間、4つの異なる価格を販売します。
  • 100株を購入します。100日間、1日1株を売ります。
  • 4つの異なる時間、4つの異なる価格を購入します。ポジション全体を一度に1つの価格で売ります。

考えられる解決策は、株式の各株のオブジェクトを作成することです。この方法では、各株の日付と価格が異なります。これはオーバーヘッドが大きすぎるでしょうか？ポートフォリオには、数千または数百万の小さな共有オブジェクトが含まれる可能性があります。ポジションの総市場価値を知りたい場合は、次のようなものが必要になります。

sum([trade.last_price for trade in portfolio.positions if trade.symbol == "ABC"])

位置オブジェクトがある場合、計算は簡単になります。

position.last * position.qty

助けてくれてありがとう。他の投稿を見ると、SOは「あなたのためにプログラムを書く」のではなく「助け」のためであることが明らかです。正しい道を指して、方向性が必要だと感じています。

反射に関する追加情報 目的 プログラムは、開いている状態と閉じている状態の両方のすべての位置を追跡します。詳細な損益を確認する機能を備えています。

私が見たい詳細なP＆Lについて考えるとき...-すべてのオープン日（およびクローズ日）-開催時間-オープン価格（クローズ日）-オープン以来のP＆L-1日あたりのP＆L

@Senderle

おそらく、あなたは「オブジェクト」のメタファーを文字通りに解釈しすぎていると思います。そのため、プログラミングの意味で、ある意味で非常にオブジェクトに似ているように見える共有をオブジェクトにしようとしています。もしそうなら、それは間違いです、それは私が並置のポイントであると思うものです。

これは私の間違いです。「オブジェクト」について考えると、shareオブジェクトは当然の候補のようです。アイデアがおかしいと思われるのは、数百万人になるまでです。今週末は無料のコーディング時間を設けて、数量のあるオブジェクトを作成してみます。

4

5 に答える 5

2

このようなシステムを設計する際に心に留めておくべき 2 つの基本的な教訓があります。

  1. データから冗長性を排除します。冗長性は完全性を保証しません。
  2. 問い合わせに答えるために必要なすべてのデータを、最小限の詳細レベルで保持します。

これらの教訓に基づいて、トランザクション ログ ファイルを維持することをお勧めします。各トランザクションは、ある種の状態の変化と、それに関連するすべての事実を表します: いつ、何を、売買するか、何個、いくらかなどです。各トランザクションはレコードで表されます (ここでは名前付きタプルが役立ちます)。フラットファイルで。1 年分 (または 5 年または 10 年分) のトランザクションは、メモリ常駐リストに簡単に収まるはずです。次に、このリストから必要な情報を選択、並べ替え、要約する関数を作成できます。メモリ常駐であるため、SQL データベースよりもはるかに高速です。

トランザクション ログが大きくなりすぎたり遅くなったりした場合は、特定の日付 (年末など) のすべてのポジションの状態を計算し、それを次の期間の初期状態に使用して、古いログをアーカイブできます。ファイルからディスクへ。

特定の日付の価値/価格など、所有物に関する補助的な情報が必要になる場合があります。これにより、任意またはすべての所有物の価値と時間をプロットできます (この種の情報についてはオンライン ソースがあり、yahoo ファイナンスがその 1 つです。 ) 所有している各資産に関する静的情報を含むマスター データベースも役立ちます。

これはあまり「オブジェクト指向」に聞こえないことはわかっていますが、オブジェクト指向の設計はTransLog、データをディスクに保存/ディスクから復元するメソッド (save/open メソッド) を使用して、システムの詳細な動作をオブジェクトに隠すのに役立ちます。トランザクションの/変更/削除; データを処理して意味のある情報表示にする追加の方法。

最初に、コマンド ライン インターフェイスを使用して API を記述します。これで満足のいく結果が得られたら、必要に応じて GUI フロント エンドの作成に進むことができます。

頑張って楽しんでね！

于 2011-03-25T07:22:20.917 に答える
1

に分ければいいと思います

  • 保有物（各シンボルの現在所有または借りているもの）
  • 注文 (一度に 1 つのシンボルを売買するという単純な要求)
  • 取引（注文の集まり）

これにより、現在の値を取得したり、注文をキューに入れたり、より複雑な注文を作成したり、背後にあるデータベースを使用してデータ オブジェクトに簡単にマップしたりすることが非常に簡単になります。

于 2011-03-23T03:01:27.773 に答える
1

あなたの質問に答えるには: あなたはすでにデータ モデルについてかなり明確な考えを持っているようです。しかし、このプログラムで何をしたいのかをもっと考える必要があるように思えます。株価の変動を追跡しますか？注文するか、注文を提案しますか? それとも、単にあなたが行った注文を追跡しますか? これらの用途ごとに、異なる戦略が必要になる場合があります。

そうは言っても、すべての shareに対してオブジェクトが必要な理由がわかりません。その戦略の背後にある理由がわかりません。注文履歴を非常に詳細に追跡できるようにしたい場合でも、「日付の1株あたりのドルでのx株」のように、集計データを保存するだけで済みます.yz

positionオブジェクト ( holdingHugh の用語ではオブジェクト)を持つ方がより理にかなってい.order_historyます。その株の保有に関する詳細な履歴が本当に必要な場合は、1 つの株に 1 つ、おそらく属性を付けて作成します。そして、そうです、データベースは間違いなくこの種のことに役立ちます。

ちょっと哲学的な話をしよう：おそらくあなたは「オブジェクト」の比喩を文字通りに捉えすぎているのではないかと思います。語。もしそうなら、それは間違いです。

オブジェクト指向設計に欠陥があるという彼の意見には同意しません。これはかなり大胆な発言です。--しかし、「オブジェクト」（別名クラスインスタンス）がモジュールとほぼ同じである限り、彼の答えは正しいです**。これは、いくつかの共有状態にリンクされた関連関数のコレクションです。クラス インスタンスでは、状態はselfまたはを介し​​て共有thisされますが、モジュールでは、グローバル名前空間を介して共有されます。

ほとんどの場合、クラス インスタンスとモジュールの唯一の主な違いは、それぞれが独自の独立した状態を持つ多くのクラス インスタンスが存在できるのに対し、モジュール インスタンスは 1 つしか存在できないことです。(もちろん他にも違いはありますが、ほとんどの場合、それらは OOD の学習にはあまり重要ではない技術的な問題に関係しています。) つまり、モジュールについて考えるのと同様の方法でオブジェクトについて考えることができます。これはここで役立つアプローチです。

**多くのコンパイル済み言語では、モジュールをコンパイルしたときに生成されるファイルを「オブジェクト」ファイルと呼びます。「オブジェクト」の比喩は実際にはそこから来ていると思います。(私はその本当の証拠を持っていません!よりよく知っている人は、遠慮なく私を訂正してください。) 人が目にするどこにでもある OOD のおもちゃの例 -- car.drive(mph=50); car.stop(); car.refuel(unleaded, regular)-- 私は、概念を混乱させる可能性のある逆形成であると信じています。少し。

于 2011-03-24T00:16:26.807 に答える
1

オブジェクトを避けてください。オブジェクト指向設計には欠陥があります。プログラムを、データ (リストと辞書) を操作する動作の集合と考えてください。次に、関連する動作をモジュール内の関数としてグループ化します。各関数には明確な入力と出力が必要です。データを各モジュールにグローバルに保存します。なぜオブジェクトなしでそれを行うのですか？問題空間により近くマッピングされるためです。オブジェクト指向プログラミングは、問題を解決するにはあまりにも多くの間接性を生み出します。不必要な間接化は、ソフトウェアの肥大化とバグを引き起こします。

考えられる解決策は、株ごとにオブジェクトを作成することです。このようにして、株ごとに異なる日付と価格が設定されます。これはオーバーヘッドが大きすぎますか? ポートフォリオには、数千または数百万の小さな Share オブジェクトを含めることができます。ポジションの合計市場価値を知りたい場合は、次のようなものが必要です。

はい、オーバーヘッドが多すぎます。ここでの解決策は、データをデータベースに保存することです。NOSQL スキームを使用しない限り、ポジションの合計市場価値を見つけることは SQL で行われます。

将来起こり得るすべての結果を想定して設計しようとしないでください。プログラムが今必要な方法で機能するようにするだけです。

于 2011-03-23T02:36:37.693 に答える