Søren Pedersen

@vincpa Nice to know - thanks!

I agree - this is a team decision, but it is also nice to get input from outside the team :)

@stevenbey Thanks for getting back to me :)

That sounds like an interesting approach. I don't suffer from the same OCD as you though, so I don't have a problem with the classes being there. However, I am open for trying other approaches, so I might give your approach a try in my next project - thanks!

@jameshancock10 I respect your opinion, but I do not agree with you. I think code that adheres to the SOLID principles is MUCH easier to maintain than code that doesn't. I have worked with both as well. If you do not split up your classes and functions, then you end up with very large functions and very large classes. This makes it difficult to keep your code DRY, and it makes it difficult to see what is going on.

You argue that it is difficult to find the classes that implement an interface - I do not agree, Visual Studio or ReSharper can do that for you. With the approach I have described in this blog post it should be very simple to find the implementation for an interface since it is nested under the interface in the solution explorer.

You argue that mocks and stubs are not for unit tests - again I do not agree. Mocks and stubs are made exactly for unit tests. In a unit test you are only interested to test a very small part of your code - one function, or possibly only part of a function. You do not want to test your dependencies in a unit test, so you mock them.

So, using dependency injection is a no brainer for me, but that was actually not the topic of this blog post :)

@jameshancock10 I respectfully disagree. It is true that most of the interfaces I make only ever get one implementation for production code, however they get mocked or stubbed for unit testing. Splitting up the code into small reusable parts makes it much easier to write unit tests, and I would argue that it also makes the code much easier to maintain. This adheres to the SOLID principles: http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

@stevenbey, I completely understand your viewpoint, and that is also why I am hesitant to use it everywhere. However there is nothing in the code that makes them tightly coupled, it is only the appearance in the solution explorer. In that respect, my previous way of structuring, using folders, looks just as bad I guess?

What structuring do you use? - I think it is often overkill to put interfaces in their own assembly, especially when you, like me, use interfaces everywhere. But, I am very interested to hear about other approaches :)