From: Brett L. <wak...@ea...> - 2005-12-13 20:55:21
|
>> Looking a bit more at the code... ok, I see how you're >> implementing it. Now it makes a bit more sense. >> >> So, what's the difference between Cash and Money? >Nothing. We should probably keep one and delete the other. ;-) >> Worth doesn't seem to make a whole lot of sense to me. It's >> not storing any information of its own, but is instead >> calling methods in Player. So, if this information isn't >> something that we can abstract out, why should we make things >> more complicated by making a new Class? >To fit into the generic way that the new Field class updates itself: >via the toString() method of any ModelObject subclass. Ah ha. That makes lots of sense. Very good. >> In the end, Cash and Trains make sense to me. Price seems >> like it could extend from Cash, because a Price is just an >> amount of Cash. The others don't really look like we need them. >No, Price embeds a StockSpace, Cash embeds an int. >I could probably find a way to merge these classes, >by representing price by an int as well as a StockSpace. >But that would require extra update code in PublicCompany, >so it does not really reduce complexity to me. Would it make sense for Price to extend from Cash instead of from ModelObject? Would the inherited methods add any value? ---Brett. |