Ceci n'est pas une interface

Likewise, extracting all the public functions from a class and surrounding them with

public interface ISomeClassName { 
 
}

Does not make an interface.

One of the terrible failings of Resharper is the Extract Interface dialog has a button for All Public functions.
This encourages this frankly misguided behaviour.


IEnumerable is an interface. It defines one thing and it defines it will. Wander into any code base and if you have a decent environment, you should be able to do some form of "Find Usages" which will show classes that implement IEnumerable. There will be quite a few. That's because it's REALLY useful.

If I take a Binary Tree, there may be many different functions, allowing me to add Ranges, delete Ranges, create Views, Find Items, Get Counts, etc etc. How do I benefit from extracting the entire public interface to create an IBinaryTree. It would likely turn out that the interface has so much in it that the only thing which can implement it is another Binary Tree.

Maybe I have a lump of code which wants a Binary Tree, but in fact it really only cares about a collection which has been sorted into a given order. SortedCollection (or if you must ISortedCollection) might be a perfectly reasonable interface.


When we look at the members that my code uses, it comes down to iterating through the list...


public interface ISortedCollection { 
   IEnumerator GetEnumerator();
}


So in fact my code just needs an IEnumerable. It does not need an IBinaryTree at all.*


If I pass in an IEumerable then I can actually use a List for my code after calling List.Sort().


Now we are down to what an interface is. An interface specifies some functionality that I want to use. Ideally the minimal functionality. It is so much less than a list of public functions in an existing class, and in being less, it is more.


Now my Unit Tests can be far simpler, I no longer need to have test which depend on the binary tree. I can use a simple Array which I define in sorted order. 


Small interfaces reduce unnecessary binding. 


* You could argue that a specific interface for Sorted data would allow me to catch, at compile time, the problem of passing unsorted data down here. This is true, but that's a whole other post.

Open/Closed Principle

With so many things interrelating, it's hard to explain the importance of one thing without relying on many other bits of knowledge.

Open/Closed is on of those things.

How can software be Open for Addition and Closed for Modification.

Surely I need to change code? And change it all the time.

Well, maybe.

If I write smaller functions, and smaller classes. If they do one thing, and do it correctly, then they probably don't need to change. Ever.

My larger blocks of functionality, which are made of the smaller blocks, will change more often, but if, for example I create a class or function to do a bilinear interpolation of a surface, then as long as it does a bilinear interpolation, I may need to optimize it, but it will only ever do a bilinear interpolation. If I want to do some other interpolation, I create a new class.

My higher level class may change to use the new interpolation, but I have not CHANGED the bilinear one.

I may wrap the General Bilinear interpolation in a class which is better named from the point of view of the problem domain, and takes domain named parameters. Rather than have an Bilinear.Interpolate(double x, double y)->double  my wrapper may be myChemicalMix.ApproximateReactionRate(double tempInCelcius, Acidity ph) -> ReactionRate.

Now my domain class does nothing but map my domain problem onto an interpolation. I no longer have to remember is x the Acidity or the Temperature.

So now when I change from a Bilinear Interpolation to a Triangular Interpolation, my Bilinear Class remains untouched, I write my Triangular Interpolation and Unit Tests, and if it turns out that they can each implement a Surface Interpolation interface, happy days.

Nothing in designing software stands on it's own. That's why it's easy to write a program, but it's hard to engineer one.

Without Single Responsibility and Dependency Inversion, Unit testing is staggeringly difficult.
Without The Open/Closed Principle, you will spend all your time changing tests.
Without Interface segregation, you won't understand what you need to mock out for a given test, and the test will be overly complex.

Good design can only come from understanding why.



* yes, I did make those up from thin air