Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><strong>To answer your question</strong>: You appear to have a fairly clear idea of your data model already. But it looks to me like you need to think more about what you want this program to do. Will it keep track of changes in stock prices? Place orders, or suggest orders to be placed? Or will it simply keep track of the orders you've placed? Each of these uses may call for different strategies.</p> <p>That said, I don't see why you would ever need to have an object for <em>every share</em>; I don't understand the reasoning behind that strategy. Even if you want to be able to track your order history in great detail, you could just store aggregate data, as in "<code>x</code> shares at <code>y</code> dollars per share, on date <code>z</code>".</p> <p>It would make more sense to have a <code>position</code> object (or <code>holding</code> object, in Hugh's terminology) -- one per stock, perhaps with an <code>.order_history</code> attribute, if you really need a detailed history of your holdings in that stock. And yes, a database would definitely be useful for this kind of thing.</p> <p><strong>To wax philosophical for a moment</strong>: 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. </p> <p>I disagree with him that object oriented design is flawed -- that's a pretty bold pronouncement! -- but his answer is right insofar as an "object" (a.k.a. a class instance) is almost identical to a module**. It's a collection of related functions linked to some shared state. In a class instance, the state is shared via <code>self</code> or <code>this</code>, while in a module, it's shared through the global namespace.</p> <p>For most purposes, the only major difference between a class instance and a module is that there can be many class instances, each one with its own independent state, while there can be only one module instance. (There are other differences, of course, but most of the time they involve technical matters that aren't very important for learning OOD.) That means that you can think about objects in a way similar to the way you think about modules, and that's a useful approach here. </p> <p>**In many compiled languages, the file that results when you compile a module is called an "object" file. I think <em>that's</em> where the "object" metaphor actually comes from. (I don't have any real evidence of that! So anyone who knows better, feel free to correct me.) The ubiquitous toy examples of OOD that one sees -- <code>car.drive(mph=50); car.stop(); car.refuel(unleaded, regular)</code> -- I believe are back-formations that can confuse the concept a bit.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload