Expense Calculator - Session 2
At the end of session 1, I had mentioned that Transaction class is a place where we can use State pattern. The two scenarios we saw deal with an equitable (payer shares the expenses) and non-equitable (payer doesnt share the expenses).
Analyze further and you can see that this characteristic about transactions is characterisitc of Party Heirarchy. Even party heirarchy is a bit confusing. Now if I create Distribution heirarchy and attach it to Transaction , then isParticipant method becomes redundant on Party heirarchy.
That in turn lets me do away with ParticipantPayer and NonParticipantPayer. Because that is now controlled by Distribution heirarchy. So I end up with Party and Receiver. Then I trun Party Heirarchy into Payer and Receiver which makes it a lot simpler.
Session 3
See the class diagram below and compare it with the class diagram on session 1. This shows that its 'difficult' to come up with simple solutions but with agile techniques you can ;-)
Analyze further and you can see that this characteristic about transactions is characterisitc of Party Heirarchy. Even party heirarchy is a bit confusing. Now if I create Distribution heirarchy and attach it to Transaction , then isParticipant method becomes redundant on Party heirarchy.
That in turn lets me do away with ParticipantPayer and NonParticipantPayer. Because that is now controlled by Distribution heirarchy. So I end up with Party and Receiver. Then I trun Party Heirarchy into Payer and Receiver which makes it a lot simpler.
Session 3
See the class diagram below and compare it with the class diagram on session 1. This shows that its 'difficult' to come up with simple solutions but with agile techniques you can ;-)
Post a Comment