« Scalars as Implicit Collections - Removing an Edge | Main | Avoid Null Checks by Replacing Finders with Tellers »

June 06, 2013



Hi Mike,

I find it interesting that TDD helps to decide when to apply the various principles. For example a problem dependency may make the code you want to write untestable in a unit test. That could lead to applying dependency inversion. When a test case obviously is concerned unrelated ideas, maybe its time to split a class do achieve single responsibility.


Instead of guiding principles, what if we asked guiding questions? I like it.

Rachel Davies

Nice post. Asking questions is a classic approach when coaching to engage another person. Describing the challenge as the motivation of the design principle is neat too, especially as some design principles can be framed into multiple what-if challenges. Being open-ended, challenges should avoid problems with over-zealous application. However, a the biggest challenge to be faced when attempting this approach is many developers are opinionated and already steeped in design principles. I think they'd likely respond to a challenge with stock answers of what worked on their last project. Any thoughts on how to handle someone dismissing design challenges because they already know the answer?

Johan Martinsson

I sure dealt with several codebases where "every single concrete class has an associated interface" made a mess. In particular because they had consistently had I and Iimpl.

However I'm not so sure that "every single concrete class has an associated interface" is a bad idea. Indeed Nat Pryce and Steeve Freeman in GOOS makes a point of using interfaces (for almost every interaction between two objects) as a way of naming the nature of the conversation taking place. I haven't had the opportunity to try it out full scale on a project, but I sure would like to. Do you believe it would work, given a reasonably mature team?

The comments to this entry are closed.