From: Erik V. <eri...@hc...> - 2005-12-13 21:23:01
|
> >> 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. ;-) Ah, now I understand the confusion. I had renamed MoneyModel to CashModel, but I see that the removal of MoneyModel was not committed. Done now. > >> 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. I agree with you that the number of ModelObject classes is growing a bit large, and more will come. I will certainly consider all this again when I'm revisiting this subject. > >> 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? No, but coming to think of it: if we let StockSpace extend from ModelObject, we would probably not need the extra PriceModel. Sounds good. Erik. |