... is interface overloading. Or Overriding. I kinda toggle between the terms. Right now I'm favoring Interface Overloading; so that's what the title is.

Interface Overloading

Interface overloading is the process I've found in C# and JAVA to allow TDD when using Libraries and OS Systems.

This should clearly not be the ONLY way. It's a mechanism I stumbled across while TDDing up an android app.
I wrote this post while I first found it. It was part of a long and twisted path... Which I think resulted in an excellent tool.

Simple Definition

Extending a class and implementing an interface of a base class method allowing passing around as an interface.


The basic idea really comes into a mix-in style that gives functionality as required to classes you don't control.

Where I discovered this, and I'm confident it will have significant impact is the UI. It can be utilized against Library and OS classes as easily, but I haven't encountered any cases yet that scream "WIN" as loudly as UI does.


Let's go for a simple example that was TDD'd. The code link is available at the end of the post.

The base class
public class BaseClass  
     public string TheMethod(int intVal, bool boolVal) => $"StringVal {intVal} {boolVal}";

A simple example with just one method. TheMethod. It builds a string and returns it.

TheMethod is not a virtual method so it's unable to be mocked. We need a way to pass this around. Really; this example is overly simplified. A MAJOR reason it works so well for UI, is that those often tie themselves to the UI thread, which makes calling textBox.Text = "example"; in a unit test will throw an exception. In Android, it's due to the OS not actually being there.
For C#, I'm working in UWP; and it's a "Ui Changed on non-ui thread" exception.
I suspect very similar if working in WinForms. In general; the UI is thread restricted which forces what I've seen from some frameworks; the ability to force a specific thread.

Now that we have a method we want to use in a method; we need to create the interface to hook into it.

public interface ITheInterface {  
   string TheMethod(int intVal, bool boolVal);

Yep; same signature. Not a lot to go over here. It's an interface with the same definition... yeah.

OK; next up!

public class WrapperClass : BaseClass, ITheInterface { }  

And here we have our Wrapper class. It's the object we'll use in our UI.
In android it'll look like

  android:layout_height="match_parent" />

that can be seen here
and in XAML it'll look like

<userControls:WrapperClass x:Name="TxtTitle" Canvas.Top="1" Canvas.Left="1" HorizontalAlignment="Left" HorizontalContentAlignment="Left"/>  

and can be seen here
The base class of these are have been TextBox in actual implementation; and did the Interface Overload for setting text.

Both of the above repo's can be explored to see how I've done used it.


The available simple examples are available in my InterfaceOverride git repo.


This isn't a complex way to abstract classes you don't control. It's just a really useful one... at least very useful in the UI... for me. I hope it can help others TDD more of the application. Other tricks may be required for other things; but that's a post for another day.