I want to write a php web-app to manage an investment portfolio of stocks and options. I have written a few OO Classes but I have never designed an app to be OO from scratch. I’m trying to figure out what Objects I’ll need. I made an initial list of Classes and their main properties that I think I’ll need:
Portfolio Design
Stock
- Ticker
- Company
- Industry index
- Story
- Price
- Splits
- History
Option
- Ticker
- Price
- Strike
- Exp date
Option chain
- Ticker
- Options
Cash???
Position
- Ticker
- Transactions ()
Transaction
- Ticker
- Security (Stock, Option)
- Transaction (Buy, Sell, Income, Expense, Check, Deposit)
- Date
- Amount
- Shares
- Price
- Commission
- Tax
- Notes
Am I on the right track? Thanks for any advice you might have!
Assuming you have all your basic investments’ information in a database, you might be able to get away with only 1 class for each investment type that does all the number crunching/analysis for each investment in that type.
for example - you could have a single class called something like Stock_Analyser to handle company shares.
Stock_Analyser could have properties like
company_code
purchase price
current price
dividend (cps)
etc, etc, etc
and methods to calculate
current nett value of holding
current profit/loss
return on investment (ROI)
current dividend yield
etc, etc,etc
After you retrieve all the stock info from the database, you create a single instance of the class and then loop through the retrieved records and pass the info in each record of the result set to the class, one at a time, to analyse each stock and output the results to the screen.
You would probably need other classes to handle other investment types like options, cash, managed funds etc
Thanks for your reply. A class per investment type is not enough because often a position, for analysis purposes, includes stock, options and dividends.
Why would that be better than creating investment “objects” and destroying them when done with then?
I’m having trouble visualizing the structure of the application.
I don’t know if it would be better. I am making the assumption that your application will retrieve basic data from the database and then use a class(es) to analyse that data and display the results on the screen. Depending on how you structure your application it could be done with a single class.
This quote is the key point.
I think you are putting the cart before the horse. Imho a better approach would be to
create a website “story board” and make a list of the user functionality, features, outputs you want in your application.
design a data model for the website to suit the requirements in 1)
create a few key mockups of pages (outputs), either hand drawn or with some graphics application, to get a feel of what the user will see.
decide on what coding structure and/or classes you will need to achieve 1-3 above
create your database as per data model in 2)
start coding.
I think if you follow the above steps, planning and building your application will be much easier. If you need more help, please post back.
PHP OO applications are generally very similar to ordinary OO applications in many regards (as far as data, etc.)
The key difference is the fact that every page load creates all of the objects you use, does it’s processing, destroys the objects, and returns the generated code, so you don’t have those persistent objects that you’re used to with normal OO applications.
Kalon’s process isn’t half bad.
Generally when I create the files for my PHP OO applications, each class falls into one of two general categories:
data
display
For simpler sites, each display class will represent a single page. If I want to make them skinnable or something, I may break it into something like a content class and a skin class.
The data classes are just like the any data class you’d have in any other OO project.
Thanks for your reply. My problem is that I have not done “ordinary OO applications.” I stopped programming about 20 years ago (yes, I’m an old timer) and only picked up php seriously about 5 years ago. I only started writing OOP seriously about 2 years ago when I wrote a cart web-app. But only the cart is a class, the rest is procedural. Now I want to write a fully OO web app.
The key difference is the fact that every page load creates all of the objects you use, does it’s processing, destroys the objects, and returns the generated code, so you don’t have those persistent objects that you’re used to with normal OO applications.
The cart objects are stored – serialized – in MySQL tables. There are about 3.500 cart objects in various stages of use at any one time.
Kalon’s process isn’t half bad.
Generally when I create the files for my PHP OO applications, each class falls into one of two general categories:
data
display
For simpler sites, each display class will represent a single page. If I want to make them skinnable or something, I may break it into something like a content class and a skin class.
The data classes are just like the any data class you’d have in any other OO project.
That sounds like a good idea. I’ve been reading Tony Marston’s [I]Object-Oriented Programming for Heretics[/I] where he suggests using a class per database table. Since I’m comfortable with normalizing tables that sounds appealing to me. If he is to be believed, his method has a lot of detractors.
Yesterday I was toying with the idea and I won’t be implementing it his way but I will use a class per database table and, as per your suggestion, a class per browser page. The project is rather large but I think I can build it piece by piece which should keep it manageable.
There are about 3.500 cart objects in various stages of use at any one time.
