5 responses so far ↓

• decoder's me2DAY // Mar 10, 2009 at 1:53 am

  decoder의 생각…

  Guide: Writing Testable Code. 테스트 용이한 코드를 작성하기 위한 지침(pdf)…

• Fred // Mar 10, 2009 at 6:27 am

  Great! Thanks for sharing. I am looking forward to reading it.

• igorbrejc.net » Fresh Catch For March 11th // Mar 11, 2009 at 9:03 am

  [...] Guide to testability is now downloadable [...]

• Touko // Mar 12, 2009 at 3:16 am

  Nice!One thing to mention: on the “Contents” page the flaws “Flaw: Constructor does Real Work (page 3)” and “Flaw: Brittle Global State & Singletons (page 23)” seem to be forgotten.

• Sridhar Visvanath // Mar 27, 2009 at 6:56 pm

  I loved the following lines. Very true ”I have always let Hibernate deal with these issues. I fees strongly that CreditCard should be unaware about transactions, locks, etc. Look in your wallet, does your CreditCard know about any of these? Yet our financial system works just fine, (well maybe not if you read the news, but it is not for lack of transactions.) Hibernate solves your problem very simply. It creates two copies of the CreditCards. One for itself (private) and one for you (public). The CreditCard has an additional field version which Hibernate uses for locks. When hibernate commits it compares public and private versions to see if anything is dirty, if it is it than compares the version number with the one in the database. If versions match, than the version is incremented and data is committed, your public copy becomes stale (versions don’t match) and you need nod worry about someone keeping a reference to it accidently across the transactions. If versions do not match the database is rolledback and exception is thrown.If you place all of these responsibilities onto the CreditCard, the system will be hard to test, not because you violated some injectable vs new rule, but because you violated single responsibility principle and you will be in mocking hell trying to instantiate it.” In my opinion, Service, Entity and Valueobject are abused a lot and hence might not convey the same sense. I think we might need to improve/increase our vocabulary to include the actual objects and how problems are naturally solved. This is the difference I see in Dave email and Misko’s. Misko is specific about how the thing has to naturally evolve. TDD aids us in this regard. it forces us to think as a client first and foremost and then we can use that approach to refactor. note: There are multiple schools of thought in OO world, one which want to keep it very close to real world, for instance in a real world Employee will not pay himself/herself and the other group wants to have all logic in domain objects as Dave gave in CreditCard example. I would say that we go to OO principles of SingleResponsibility, Open-Closed principle etc…and apply that and observe how the solution evolves naturally

Leave a Comment