Expense Calculator - Session 6
Till session 5, we implemented all 6 requirements. Time to take a look at the code keeping in mind the observations of the last session.
First up I add more test coverage for other scenarios. Everythign works fine.
But i had pointed out about making parellel class heirarchies of expense sheet and expense statement. I try doing it but when i realize the Factory Method signatures would be different I revert back to old desing. I prefer factory method only when method signatures are same and if different then its not 'so difficult' to make a guess about redundnant parameters. In my case the method signature of factory method becomes too long and confusing.
Further I have kept Expense related classes package private. They wont be published to the outer world. So ensuring the right usage of two printStatement methods is possible. Thus no Introduce Polymorphic creation with factory method is used. :-). A case where refactoring doesnt make sense.
Next I see my ExpenseSheet Test case and the test methods which test statement generation.The questoin that begs to be asked here is what should I create a Party as: Payer or Receiver. This question popped up only after adding more test scenarios. It becomes evident that Payer or Receiver is not 'really' a Party Type, but a role played a Party. So Party bhavdeep may be a payer in one transaction and receiver in another. Another advantage of using good test coverage. I refactor to form a Role heirarchy which is used by Party. I update my test cases. Now they look more sensible. My test methods have a common feel: Create parties, set up their roles, add transaction and test 'whatever aspect' you want to.
Also I see that when I create a transaction I must process it. That is I need not call process. I make that method private , update my test cases and I call process in transaction constructor!Also in my test cases I did away with facade, dao classes. I will add these classes and packages only when required. In my test case I supply the Party with the list of transactions that it needs.
Finally my Domain and Test Class Diagrams look like this:
Domain:
Test:
Lessons Learnt:
First up I add more test coverage for other scenarios. Everythign works fine.
But i had pointed out about making parellel class heirarchies of expense sheet and expense statement. I try doing it but when i realize the Factory Method signatures would be different I revert back to old desing. I prefer factory method only when method signatures are same and if different then its not 'so difficult' to make a guess about redundnant parameters. In my case the method signature of factory method becomes too long and confusing.
Further I have kept Expense related classes package private. They wont be published to the outer world. So ensuring the right usage of two printStatement methods is possible. Thus no Introduce Polymorphic creation with factory method is used. :-). A case where refactoring doesnt make sense.
Next I see my ExpenseSheet Test case and the test methods which test statement generation.The questoin that begs to be asked here is what should I create a Party as: Payer or Receiver. This question popped up only after adding more test scenarios. It becomes evident that Payer or Receiver is not 'really' a Party Type, but a role played a Party. So Party bhavdeep may be a payer in one transaction and receiver in another. Another advantage of using good test coverage. I refactor to form a Role heirarchy which is used by Party. I update my test cases. Now they look more sensible. My test methods have a common feel: Create parties, set up their roles, add transaction and test 'whatever aspect' you want to.
Also I see that when I create a transaction I must process it. That is I need not call process. I make that method private , update my test cases and I call process in transaction constructor!Also in my test cases I did away with facade, dao classes. I will add these classes and packages only when required. In my test case I supply the Party with the list of transactions that it needs.
Finally my Domain and Test Class Diagrams look like this:
Domain:
Test:
Lessons Learnt:
- I need to practice Refactorings a lot. I am still not natural at it.
- After that is done, come and add automated functional test cases for this project. I will use FIT
- Then attached UI and persistence and publish this desktop app.
- Then Claps. :-)
Post a Comment