tag:blogger.com,1999:blog-32609450.post115538060020845211..comments2023-09-15T13:14:58.827+01:00Comments on Colin Jack's Blog: TypeMock - Helps Improve Your Designs?Colin Jackhttp://www.blogger.com/profile/01403166737046938219noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-32609450.post-7615653352793665632007-05-01T18:41:00.000+01:002007-05-01T18:41:00.000+01:00I completely agree, we've been using this approach...I completely agree, we've been using this approach for quite a while now and so far it has worked a treat. <BR/><BR/>Another advantage is that in the places where we have used interfaces/abstract base classes it stands out to the reader.Colin Jackhttps://www.blogger.com/profile/01403166737046938219noreply@blogger.comtag:blogger.com,1999:blog-32609450.post-73574357541453050742007-04-24T17:06:00.000+01:002007-04-24T17:06:00.000+01:00Looking at TDD, I've been struggling with the same...Looking at TDD, I've been struggling with the same question. I think the tradeoff is readability vs. extensability<BR/><BR/>If you expect the code to be extended with "plugins" the extra level of indirection is great. For infrastructure-type projects such as log4net this works really well.<BR/><BR/>However, in enterprise applications I've found that "extensability by plugin" is not often required in the domain or presentation layers. So the application does not change in ways that the extra interfaces/DI help - in fact they reduce readability becoming a hinderance. <BR/><BR/>My feeling right now is, if we build unit tests with something like TypeMock, we have an application that supports change (via the unit test safety net) while at the same time not sacrificing readability.Anonymousnoreply@blogger.com