Strategies to extend an existing interface in .NET

Let’s say you have the following interface in production code:

public interface IPrintable
{
	void PrintMe();
}

…and you’d like to extend it in some way: add one or more parameters to the PrintMe method or add another method to the interface.

This will be difficult as it breaks all existing implementations of the IPrintable interface. If you own the whole code base then you may take the time and update all places where the interface is used.

If, however, this is not the case then you’ll need to follow another strategy.

One option is to create another interface and let it derive from the existing one:

public interface IPrintableExtended : IPrintable
{
	void PrintMeExtended(string argument);
	void PrintMe(int howManyTimes);
}

You can then start programming to the extended interface in all future code.

Another, more long term option is using the obsolete keyword in .NET and thereby discourage the usage of IPrintable. You can replace the existing interface with a brand new one and start programming to that instead. Note that this process can take years for all clients to update their code to the new interface instead.

One last option I can think of can be used for brand new interfaces so that they’ll be more forward-looking. Instead of a set of primitive arguments to a method you can let an object hold the parameters like here:

public class PrintArguments
{
	public int HowManyTimes { get; set; }
	public string Format { get; set; }
	public bool Pretty { get; set; }
}

public interface IPrintable
{
	void PrintMe(PrintArguments printArgs);
}

You can then add new properties to the PrintArguments object if you need new arguments to the PrintMe method. You’ll probably need to adjust your code for default and missing values but existing code won’t break at least.

View all various C# language feature related posts here.

Explicit interface implementation in .NET Part 4

In the previous post we finally solved the mystery of how the Add method was “hidden” in the ConcurrentDictionary object. We now know how explicit interface implementation works in code.

However why would you implement an interface explicitly?

Read more of this post

Explicit interface implementation in .NET Part 3

In the previous post we started looking into how explicit interface implementation is done in code. Visual Studio makes it a breeze and you can easily produce code like we saw previously:

int IMultipliable.Calculate(int a, int b)
{
	...
}

So now we can reach the Calculate methods as follows:

Read more of this post

Explicit interface implementation in .NET Part 2

In the previous post we introduced the idea of explicit interface implementation in .NET. We also saw two examples from .NET with explicit implementation in action.

Let’s first see how this language structure works in C#. Suppose we have the following interface:

public interface ISummable
{
	int Calculate(int a, int b);
}

We can then implement this interface implicitly as follows:

public class Calculator : ISummable
{
	public int Calculate(int a, int b)
	{
		return a + b;
	}
}

This should be straightforward for all programmers.

Let’s have another interface:

public interface IMultipliable
{
	int Calculate(int a, int b);
}

We then want our calculator to implement the above interface as well:

public class Calculator : ISummable, IMultipliable
{
	public int Calculate(int a, int b)
	{
		return a + b;
	}
}

As Calculator already has a Calculate method with two integer parameters it also satisfies IMultipliable without changing the Calculator object implementation.

This is problematic as we have no straightforward way to provide a multiplication for our calculator:

Calculator calculator = new Calculator();
int res = calculator.Calculate(2, 5);

“res” will be 7 of course.

We assume here that we cannot change the method names of ISummable and IMultipliable. They may be part of a third party library. One way out of this situation is to implement IMultipliable explicitly. If you right-click “IMultipliable” in Calculator.cs in Visual Studio you can select “Implement Interface”, “Implement Interface Explicitly” in the context menu. You’ll get the following stub:

public class Calculator : ISummable, IMultipliable
{
	public int Calculate(int a, int b)
	{
		return a + b;
	}

	int IMultipliable.Calculate(int a, int b)
	{
		throw new NotImplementedException();
	}
}

The structure of the new Calculate method looks very much like the non-generic GetEnumerator method of the second example of the previous post.

Explicitly implemented interface methods must not have any access modifiers. They are public by default.

Let’s implement the new method:

int IMultipliable.Calculate(int a, int b)
{
	return a * b;
}

How can we call this method? We have to declare Calculator as an interface type:

public void ShowSample()
{
	IMultipliable calculator = new Calculator();
	int res = calculator.Calculate(2, 5);
}

“res” will now be 10.

We’ll investigate this further in the next post.

View all various C# language feature related posts here.

Explicit interface implementation in .NET Part 1

The generic and well-known Dictionary object and its generic and thread-safe counterpart, i.e. the ConcurrentDictionary object both implement the generic IDictionary interface. The IDictionary interface has an Add method where you can insert a new key-value pair into a dictionary:

Dictionary<string, string> singleThreadedDictionary = new Dictionary<string, string>();
singleThreadedDictionary.Add("Key", "Value");

I can even rewrite the above code as follows:

IDictionary<string, string> singleThreadedDictionary = new Dictionary<string, string>();
singleThreadedDictionary.Add("Key", "Value");

However, what if we try to do the same with the concurrent dictionary?

Read more of this post

ultimatemindsettoday

A great WordPress.com site

Elliot Balynn's Blog

A directory of wonderful thoughts

Softwarearchitektur in der Praxis

Wissenswertes zu Webentwicklung, Domain-Driven Design und Microservices

Technology Talks

on Microsoft technologies, Web, Android and others

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog

WEB APPLICATION DEVELOPMENT TUTORIALS WITH OPEN-SOURCE PROJECTS

Guru N Guns's

OneSolution To dOTnET.

Johnny Zraiby

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

%d bloggers like this: