From: Stefan F. <ste...@we...> - 2012-09-02 21:45:56
|
General remark first: To understand my approach it is important that I try to construct robust and simple core elements, which do not take into account all special rules, but provide a few hooks to allow the creation of special rules without changing the core mechanisms. It often might seem simpler to drop some restrictions of the core engine and add the special rules inside the core engine. However this makes the core engine less robust and might fail at some other places. So I usually prefer to allow a little bit more complexity at the outer layers if I can keep the core simple and unchanged. Specific remark here: In the current definition there is a one-to-one relationship between (owner,type) <-> portfolio<type> and wallet<type> Buy your question below is a good one: Would it be possible to for a n:1 relationship? For the core mechanism it is possible, as currently we only ask for the wallet/portfolio given the owner and type. However there is at least one use case with a disadvantage: A general correction mechanism, which shows all portfolios containing one type of items and allow moving back and forward between them. For this use case a n:1 relationship complicates things a bit, but it is not impossible to solve the issues. The code would be different however: bankWallet = Wallet.create(bank, "wallet", Currency.class) bankWallet.addOtherOwner(bank.getIpo()); bankWallet.addOtherOwner(bank.getPool()); I am undecided, as it is possible to achieve the same result with a slightly more complicated solution for the (special) Bank case. Stefan On 09/02/2012 11:19 PM, Erik Vos wrote: > Then I don't see why this WalletManager could not, when asked for the IPO > wallet, return the Bank wallet. > Perhaps it's just me, but I don't see any benefit, just problems, with > splitting up the Bank cash this way. > > public BankMoneyModel(Bank bank) { > bankWallet = Wallet.create(bank, "wallet", Currency.class); > ipoWallet = bankWallet; // redundant code, of course, but I hope you > get the point. > poolWallet = bankWallet; > bankWallet.addModel(this); > } > > Erik. > >> -----Original Message----- >> From: Stefan Frey [mailto:ste...@we...] >> Sent: Sunday, September 02, 2012 11:06 PM >> To: Development list for Rails: an 18xx game >> Subject: Re: [Rails-devel] Rails2.0: Further Changes >> >> It might sound more complicated, but it is a consequence of the indirect >> access to Wallets and Portfolios. >> >> The link between the Wallet and the Owner is defined once and forever by >> creating a Wallet with the Owner as the parent. >> >> It does not matter where the Wallet lives (e.g. inside a variable of the > owner >> itself, inside a PortfolioModel or stored at a completely different > object). >> >> At the time of adding money the Owner is NOT asked for its wallet, but the >> wallet for the according owner is provided by the WalletManager by asking >> for the correct Wallet for the (Owner, Type) combination. >> >> A potential code snippet for an aggregate BankMoneyModel class: >> >> private Wallet<Currency> bankWallet; >> private Wallet<Currency> ipoWallet; >> private Wallet<Currency> poolWallet; >> >> public BankMoneyModel(Bank bank) { >> bankWallet = Wallet.create(bank, "wallet", Currency.class); >> ipoWallet = Wallet.create(bank.getIpo(), "wallet", Currency.class); >> poolWallet = Wallet.create(bank.getPool(), "wallet", > Currency.class); >> bankWallet.addModel(this); >> ipoWallet.addModel(this); >> poolWallet.addModel(this); >> } >> >> public int getCash() { >> return bankWallet.value() + ipoWallet.value() + poolWallet.value(); > } >> >> In the example above you could wire money to Bank, Pool or Ipo and it has >> the same net effect to the BankMoneyModel. >> >> The MoneyOwner interface is only a helper/legacy interface to allow an > easy >> access the cash value. >> >> On 09/02/2012 10:30 PM, Erik Vos wrote: >>>> However it might make the code easier to assume that IPO/Pool etc. >>>> have their own cash wallet to make the item buying code easier: >>>> Then the counterparty of the item transaction is identical to the >>> counterparty >>>> of the accompanying cash transaction. >>> >>> To me, that sounds like making life more complicated rather than >>> making it simpler. >>> Why then not have the Bank portfolios contain a reference to the Bank >>> Wallet? >>> Or indeed, include into every Portfolio a reference to its owner's > Wallet. >>> >>> Erik. >>> >>> >>> ---------------------------------------------------------------------- >>> -------- >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. >>> Discussions will include endpoint security, mobile security and the >>> latest in malware threats. >>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Rails-devel mailing list >>> Rai...@li... >>> https://lists.sourceforge.net/lists/listinfo/rails-devel >>> >> >> >> > ---------------------------------------------------------------------------- > -- >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and threat >> landscape has changed and how IT managers can respond. Discussions will >> include endpoint security, mobile security and the latest in malware > threats. >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |