Python中投资/股票和期权组合的面向对象设计

我是一名初级/中级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)

那么，一旦调用此方法，我如何存储信息？起初，我以为我会有一个Position对象，该对象具有诸如Symbol、OpenDate、OpenPrice等属性。但考虑更新Position以说明销售变得很棘手，因为买卖发生在不同的时间和金额

• 买100股开盘，一次，一个价格。销售4种不同的时间，4种不同的价格
• 买100股。每天卖出1股，持续100天
• 购买4种不同的时间，4种不同的价格。一次以一个价格卖出全部头寸

一个可能的解决方案是为每一份股票创建一个对象，这样每一份股票都有不同的日期和价格。这会不会太贵？投资组合可能有数千或数百万个小型共享对象。如果你想了解某个职位的总市值，你需要：

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

如果您有一个位置对象，计算将很简单：

position.last * position.qty

提前谢谢你的帮助。看看其他帖子，“帮助”显然不是“为你编写程序”。我觉得我只是需要一些方向，指向正确的方向

思考后的附加信息 目的 该程序将跟踪所有位置，包括打开和关闭位置；能够看到详细的损益

当我想到详细的损益表时，我想看看。。。 -所有开放日期（和关闭日期） -持有时间 -开盘价（截止日期） -开放以来的损益表 -每日损益表

@森德勒

我想也许你把“对象”这个比喻理解得太字面了，所以你试图把一个在某种程度上看起来很像对象的东西分享到一个编程意义上的对象中。如果是这样，那就是一个错误，这就是我认为并列的观点

---

这是我的错误。思考“对象”一个

共享
对象似乎是自然的候选者。直到可能有数百万人，这个想法才显得疯狂。这个周末我将有一些免费的编码时间，并将尝试创建一个具有数量的对象
 避开物体。面向对象的设计是有缺陷的。将您的程序视为对数据（列表和字典）进行操作的行为集合。然后将相关行为分组为模块中的函数。
每个功能应具有明确的输入和输出。在每个模块中全局存储数据。
为什么它没有对象？因为它更接近问题空间。面向对象编程产生了太多的间接性，无法解决问题。不必要的间接操作会导致软件膨胀和错误

一个可能的解决方案是为每一份股票创建一个对象，这样每一份股票都有不同的日期和价格。这会不会太贵？投资组合可能有数千或数百万个小型共享对象。如果你想了解某个职位的总市值，你需要：

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

是的，这将是太多的开销。这里的解决方案是将数据存储在数据库中。除非您使用NOSQL方案，否则将使用SQL来查找职位的总市场价值

不要试图设计所有可能的未来结果。只要让你的程序按现在需要的方式运行就行了
 我想我应该把它分成


持有量（您目前拥有或欠每个符号的金额）
订单（一次性购买或出售单个符号的简单要求）
交易（订单集合）

这使得获取当前值、队列订单和构建更复杂的订单变得非常容易，并且可以轻松地映射到具有数据库的数据对象中。
要回答您的问题，您似乎已经对数据模型有了相当清晰的概念。但在我看来，你需要更多地思考你想要这个程序做什么。它会跟踪股价的变化吗？下订单，还是建议下订单？或者它只是跟踪你下的订单？每种用途都可能需要不同的策略

也就是说，我不明白为什么你需要为每一份都有一个对象；我不明白这个策略背后的原因。即使您希望能够非常详细地跟踪订单历史记录，您也可以只存储聚合数据，如“
x
股票在
y
美元/股，日期
z
”

如果你真的需要一份你在该股票中持有的详细历史记录，那么最好有一个
位置
对象（或者用休的术语来说是
持有
对象）--每只股票一个，可能带有
.order\u history
属性。是的，一个数据库肯定会对这类事情有用

让我们来谈一谈哲学吧：我想也许你把“对象”这个比喻理解得太过字面化了，因此你试图在编程这个词的意义上把一个在某些方面看起来很像对象的对象分成一个对象。如果是这样，那就是一个错误，这就是我认为并列的观点

我不同意他的观点