Object oriented design for an investment/stock and options portfolio in Python

Question

I'm a beginner/intermediate Python programmer but I haven't written an application, just scripts. I don't currently use a lot of object oriented design, so I would like this project to help build my OOD skills. The problem is, I don't know where to start from a design perspective (I know how to create the objects and all that stuff). For what it's worth, I'm also self taught, no formal CS education.

I'd like to try writing a program to keep track of a portfolio stock/options positions.

I have a rough idea about what would make good object candidates (Portfolio, Stock, Option, etc.) and methods (Buy, Sell, UpdateData, etc.).

A long position would buy-to-open, and sell-to-close while a short position has a sell-to-open and buy-to-close.

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)

Then, once this method is called how do I store the information? At first I thought I would have a Position object with attributes like Symbol, OpenDate, OpenPrice, etc. but thinking about updating the position to account for sales becomes tricky because buys and sells happen at different times and amounts.

• Buy 100 shares to open, 1 time, 1 price. Sell 4 different times, 4 different prices.
• Buy 100 shares. Sell 1 share per day, for 100 days.
• Buy 4 different times, 4 different prices. Sell entire position at 1 time, 1 price.

A possible solution would be to create an object for each share of stock, this way each share would have a different dates and prices. Would this be too much overhead? The portfolio could have thousands or millions of little Share objects. If you wanted to find out the total market value of a position you'd need something like:

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

If you had a position object the calculation would be simple:

position.last * position.qty

Thanks in advance for the help. Looking at other posts it's apparent SO is for "help" not to "write your program for you". I feel that I just need some direction, pointing down the right path.

ADDITIONAL INFO UPON REFLECTION The Purpose The program would keep track of all positions, both open and closed; with the ability to see a detailed profit and loss.

When I think about detailed P&L I want to see... - all the open dates (and closed dates) - time held - open price (closed date) - P&L since open - P&L per day

@Senderle

I think perhaps you're taking the "object" metaphor too literally, and so are trying to make a share, which seems very object-like in some ways, into an object in the programming sense of the word. If so, that's a mistake, which is what I take to be juxtapose's point.

This is my mistake. Thinking about "objects" a share object seems natural candidate. It's only until there may be millions that the idea seems crazy. I'll have some free coding time this weekend and will try creating an object with a quantity.

Answer 1

There are two basic precepts you should keep in mind when designing such a system:

1. Eliminate redundancy from your data. No redundancy insures integrity.
2. Keep all the data you need to answer any inquiry, at the lowest level of detail.

Based on these precepts, my suggestion is to maintain a Transaction Log file. Each transaction represents a change of state of some kind, and all the pertinent facts about it: when, what, buy/sell, how many, how much, etc. Each transaction would be represented by a record (a namedtuple is useful here) in a flat file. A years worth (or even 5 or 10 years) of transactions should easily fit in a memory resident list. You can then create functions to select, sort and summarize whatever information you need from this list, and being memory resident, it will be amazingly fast, much faster than a SQL database.

When and if the Transaction Log becomes too large or too slow, you can compute the state of all your positions as of a particular date (like year-end), use that for the initial state for the following period, and archive your old log file to disc.

You may want some auxiliary information about your holdings such as value/price on any particular date, so you can plot value vs. time for any or all holdings (There are on-line sources for this type of information, yahoo finance for one.) A master database containing static information about each of your holdings would also be useful.

I know this doesn't sound very "object oriented", but OO design could be useful to hide the detailed workings of the system in a TransLog object with methods to save/restore the data to/from disc (save/open methods), enter/change/delete a transaction; and additional methods to process the data into meaningful information displays.

First write the API with a command line interface. When this is working to your satisfaction, then you can go on to creating a GUI front end if you wish.

Good luck and have fun!

Answer 2

Avoid objects. Object oriented design is flawed. Think about your program as a collection of behaviors that operate on data (lists and dictionaries). Then group your related behaviors as functions in a module. Each function should have clear input and outputs. Store your data globally in each module. Why do it without objects? Because it maps closer to the problem space. Object oriented programming creates too much indirection to solve a problem. Unnecessary indirection causes software bloat and bugs.

A possible solution would be to create an object for each share of stock, this way each share would have a different dates and prices. Would this be too much overhead? The portfolio could have thousands or millions of little Share objects. If you wanted to find out the total market value of a position you'd need something like:

Yes it would be too much overhead. The solution here is you would store the data in a database. Finding the total market value of a position would be done in SQL unless you use a NOSQL scheme.

Don't try to design for all possible future outcomes. Just make your program work that way it needs to work now.

Answer 3

I think I'd separate it into

• holdings (what you currently own or owe of each symbol)
• orders (simple demands to buy or sell a single symbol at a single time)
• trades (collections of orders)

This makes it really easy to get a current value, queue orders, and build more complex orders, and maps easily into data objects with a database behind them.