ctodx posted a blog entry of a discussion on teaching a team about design, specifically interface inheritance over implementation inheritance. I have to comments.

I am sure that judgement can be easy to teach, maybe even in some cases objective not subjective. I think the key here is to bring unit testing into the discussion. If a criteria of good design is testability then things get a bit easier. Well almost, that statement assumes that you value unit testing and are practicing it. Well designed test subjects are much easier to test than poorly designed test subjects. To take the example of Single Responsibility Principle (SRP), a test subject with many responsibilities is much harder to test than one with fewer. This is something that the developers with out much design experience or good design judgement can feel. If they are responsible for the testing then they are likely to be more interested in learning how to make things easier to test. Ahh motivation. Now you have instilled motivation and can use that as a fulcrum marinate your team in the design principles.

Interface inheritance is much easier to mock. The point of implementation inheritance is to share code. <sidenote>Every time I have used inheritance to share code I have wished later on that I had used aggregation and composition instead of implementation inheritance.</sidenote> There is no good reason not to always use interface inheritance with implementation inheritance. On your types public members always know a derivative by an interface not an implementation. This way mocking and extending are much easier.

Another release for Doubler. Download

Change Log:

• Added MSTest as a supported framework
• Changed Interapper Namespace output to Wrapped
• Corrected creation of default constructor on Interapper
• Corrected passthrough creation to not include those implemented by Object
• Added Import addition of wrappies namespace
• Basic array square brackets are translated into the word Array for Type and Member Recorder Names
• Recorders now override or implement member defined on super types of subject

Next I will be adding plugin support for Recording Test Stubs.  You will be able to configure Doubler to use a plugin to write more recording features into the test stub.  For example say you want a call count, the number of times a method has been called.  You could write a plugin to add the functionality into the recorder.

I published a few articles on my site in the last few days.

Introduction to Unit Testing

A Recipe for Build Maintainability and Reusability

Using Junctions to Manage a Development Environment

They had been hanging out on my old sites Works in Progress.  I will trying to finish up a few more on unit testing, design, and testability in the coming week.  The first of which will be Shrinking the Edge and Expanding the Creamy Center.