Designing and refactoring of payment logic

Posted by jokklan on Programmers See other posts from Programmers or by jokklan
Published on 2013-09-18T12:12:24Z Indexed on 2013/10/25 22:10 UTC
Read the original article Hit count: 257

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)...

© Programmers or respective owner

Related posts about refactoring

Related posts about ruby