Expense Calculator - Session 3
The tools I am using are:
Till now the implementation looks good enough and more importantly simple. Now when I look at the expense sheet generated for the transaction it looks somehting like this for req 1: (see session 1)
bhavdeep 10 usd, deepak -5 usd, surender -5usd. Are these expense lines correct.yes but are they going to help me in my next req: that is generating an expense sheet for a party. say for bhavdeep across n transactions.
just trying to add transaction expense sheets for reqs 1 and 2 I see a glaring hole: expense line doesnt say whome the money comes from or goes to. to implement that i see bhavdeep 10usd and deepak, surender -5usd are credit and debit lines respectively. Hmm..i see an expense line heirarchy. So i add these classes. *design hat.
But while implementing i see that for credit lines there are multiple receivers who pay the amt. so for bhavdeep 10 usd, deepak and surender pay 5 usd each. essentially this is complicating matters. i think composite might come to rescue. but i always am wary of straight away jumping to patterns. they are complex beasts and u have to pay a price for using them. i try using compoiste and i see the design getting only complex. so i wait and do a relook.
I relook at the expense sheet basically credit line. and after some scratching it strikes me:
credit line 10usd is nothing but 2 credit lines of 5 usd. so my redone expense sheet now looks:
bhavdeep 5 usd from deepak, bhavdeep 5 usd from surender, deepak 5usd to bhavdeep, surender 5 usd to bhavdeep. this clears up things. first every credit line has a debit line and vice versa. bidirectional association. also as of now my thinking is helped by having all 4 though in realiyt only 2 exist..both debit lines or credit lines. but then i can always wear my refactoring hat and remove them if reqd.
i wear my refactoring hat/desing hat alternately and bring code into shape which looks now has simplifed transaction , payer classes and added an expense line heirarchy.
Session 4
the class diagram looks like this: compare with session 2 class diagram
- Intellij Idea 4.5.3
- CVS for source control *its a local repository on my laptop
- Argo UML for class diagrams. I just used visual paradigm for session 1 but argo is what i m more comfortable with.
Till now the implementation looks good enough and more importantly simple. Now when I look at the expense sheet generated for the transaction it looks somehting like this for req 1: (see session 1)
bhavdeep 10 usd, deepak -5 usd, surender -5usd. Are these expense lines correct.yes but are they going to help me in my next req: that is generating an expense sheet for a party. say for bhavdeep across n transactions.
just trying to add transaction expense sheets for reqs 1 and 2 I see a glaring hole: expense line doesnt say whome the money comes from or goes to. to implement that i see bhavdeep 10usd and deepak, surender -5usd are credit and debit lines respectively. Hmm..i see an expense line heirarchy. So i add these classes. *design hat.
But while implementing i see that for credit lines there are multiple receivers who pay the amt. so for bhavdeep 10 usd, deepak and surender pay 5 usd each. essentially this is complicating matters. i think composite might come to rescue. but i always am wary of straight away jumping to patterns. they are complex beasts and u have to pay a price for using them. i try using compoiste and i see the design getting only complex. so i wait and do a relook.
I relook at the expense sheet basically credit line. and after some scratching it strikes me:
credit line 10usd is nothing but 2 credit lines of 5 usd. so my redone expense sheet now looks:
bhavdeep 5 usd from deepak, bhavdeep 5 usd from surender, deepak 5usd to bhavdeep, surender 5 usd to bhavdeep. this clears up things. first every credit line has a debit line and vice versa. bidirectional association. also as of now my thinking is helped by having all 4 though in realiyt only 2 exist..both debit lines or credit lines. but then i can always wear my refactoring hat and remove them if reqd.
i wear my refactoring hat/desing hat alternately and bring code into shape which looks now has simplifed transaction , payer classes and added an expense line heirarchy.
Session 4
the class diagram looks like this: compare with session 2 class diagram
Post a Comment