C # Best Practice: using a delegate or interface as a class dependency

Question

I have a class that needs a way to get the value of a random integer with a maximum value. I do not want this class to depend on a specific way to get this random value (e.g. system.random). Would be better:

(A) Use a public delegate (or func)

public delegate int NextRandomInt(int maxValue); public class MyClass { public NextRandomInt NextRandomInt { get; set; } public MyClass(NextRandomInt nextRandomInt) { NextRandomInt = nextRandomInt; } } 

(B) Use the public interface

 public interface IRandomIntProvider { int NextInt(int maxValue); } public class MyClass { public IRandomIntProvider RandomIntProvider { get; set; } public MyClass(IRandomIntProvider randomIntProvider) { RandomIntProvider = randomIntProvider; } } 

(C) Something else together.

Both methods work. I feel that using a delegate will be easier and faster to implement, but the interface is more readable and might be easier when dependency injection happens.

Answer 1

It depends on how much work you want to implement using the delegate or interface.

If your interface will have only one or even two methods, you can use Func to force the same behavior. Otherwise, I would use interface s.

Mark Seemann here explains it pretty nicely: link

Summing up, he states the following:

Whenever possible, I prefer to model my APIs using delegates instead of one-dimensional interfaces, as it gives me more flexibility and less infrastructure code.

Obviously, this method only works as long as you only need to abstract from one method. As soon as your abstraction needs the second method, you need to enter the correct interface or, preferably, an abstract base class.

Answer 2

To my point of view (I'm sure) the second option with an interface is the best. This situation is a typical example of a Strategy pattern.

Answer 3

• Use the interface if you think that another NextRandomInt() implementation may exist on the system.
• Select a delegate if you think it should be executed as the reason for the event or callback.
  Otherwise, just use the method as a member of the class. It is up to you if you want the method to be available as an instance or static method.

Answer 4

It splits the hair slightly, as the interface or the delegate works.

One reason to prefer the delegate in this case is that you are really only dependent on the method, so it should be a little redundant in order to declare both the interface and the method. If your process is similar to mine, the method name was obvious, but the interface name was not, because it does not mean anything. This is the container for the method. (And I would get almost the same name as you.)

In addition, the delegate gives you the option to use a static method. Your class is still dependent on abstraction, so you can go as a mocking method if necessary for unit unit testing. I'm usually not a big fan of static methods, but mainly because they interfere with testability. But if you depend on the delegate and not directly on the function, it does not matter.