Designing and refactoring of payment logic
- by jokklan
Im currently working on an application that helps users to coordinate dinner clubs and all related accounting. (A dinner club is where people in a group, take turns to cook for the rest and then you pay a small amount to participate. This is pretty normal in dorms and colleges where im from).
However there is some different models that all have a price and the accounting aspect is therefore a little spread. We both have DinnerClub, ShoppingItem and are about to implement the third Payment when users pay their debts (or get refunded for expenses).
Each of these have a "price" attribute and a users expense (that he or she needs refunded) is calculated by the total of these "prices" minus what other users have bought and he or she have used/participated in.
My question is then if someone have some hints to refactor this bring all this behavior together in one place? For now have i thought about a Transaction class that are responsible for this behaviour, but I'm a little worried about the performance impact on having to query for another polymorphic record each time i want to show the price on dinner clubs and shopping items (i have a standard index page with a list for both so it's a lot of extra records being queried)...
