In C#, is there a way to enforce behavior coupling in interface methods or is the fact that I am trying to do that a design smell?

Question

Many times I want to define an interface with some methods that maintain a behavior relationship between them.

However, I feel that many times this relationship is implicit. With that in mind, I asked myself: Is there any way to enforce a behavior relationship between interface methods?

I thought about defining this behavior via inheritance (by defining a common implementation). But since C# does not allow multiple inheritance, I believe that many times an interface would be more advisable and that inheritance is not flexible enough.

---

For example:

public interface IComponent
{
    void Enable();
    void Disable();
    bool IsEnabled();
}

For this interface, I wanted the following relationship to be fulfilled:

• If Enable() is called, IsEnabled() should return true.
• If Disable() is called, IsEnabled() should return false.

---

In that example, the behavior constraint that I would want to enforce is:

• When implementing Enable(), the implementer should ensure that IsEnabled() returns true
• When implementing Disable(), the implementer should ensure that IsEnabled() returns false

---

Is there a way to enforce this implementation constraint? Or, the fact that I am thinking about enforcing this kind of constraint is itself a sign that there is a flaw in the design?

Answer 1

Well, first of all, let's tweak your interface a bit.

public interface IComponent
{
    void Enable();
    void Disable();
    bool IsEnabled { get; }
}

Now then. What could potentially go wrong here? For example, could an exception be thrown in the Enable() or Disable() methods? What state would IsEnabled be in then?

Even if you use Code Contracts, I don't see how IsEnabled can be correlated to the use of your Enable or Disable methods unless those methods are guaranteed to succeed. IsEnabled should represent the actual state your object is in, not some hypothetical state.

---

That said, all you really need is

public interface IComponent
{
    bool IsEnabled { get; set; }
}

Clear it, and the component disables itself.

Answer 2

What you are looking for is a well-known approach called Design by Contract. It was supported directly in the framework in version 4.0.

DISCLOSURE: Be careful when adding code contracts to a new project in 2019. Current status of further maintenance by Microsoft is not fully clear, see this SO post, maybe because of missing popularity.

DBC allows to specify preconditions, post-conditions and invariants for functions as well as for interfaces, so you simply have to write a contract which enforces IsEnabled to be true after a call of Enabled().

As other answers have pointed out, there may be alternative designs where these constraints are not necessary, but for the sake of this example, let us assume these requirements are justified for some reason. Then using Code Contracts on Robert Harvey's variant of the example interface may look like this:

using System.Diagnostics.Contracts;

[ContractClass(typeof(ComponentContract))]
public interface IComponent
{
    void Enable();
    void Disable();
    bool IsEnabled { get; } 
}

[ContractClassFor(typeof(IComponent))]
sealed class ComponentContract : IComponent
{
    [Pure]
    public bool IsEnabled => Contract.Result<bool>();

    public void Disable()
    {
        Contract.Ensures(IsEnabled == false);
    }

    public void Enable()
    {
        Contract.Ensures(IsEnabled == true);
    }
}

See here for a short tutorial on code contracts.

Also have a look into my second answer to this question, which offers a solution not depending on libs which may become deprecated in the future.

Answer 3

You're asking too much of C# Interfaces.

C# Interfaces are contracts. They say what pack of methods a given class implements, and they guarantee that those methods will be there if someone calls them.

That said, that is also the only thing C# Interfaces do.

They are completely oblivious to what the implemented methods do. They are free to do whatever they want.

A given class can implement "isEnabled" to always return true. Another one can tie "Disable" to a database call, and refuse to disable if something specific happens.

You can't control any of that. That's not the job of your C# Interface.

---

How do I enforce this behavior, then?

Use tests.

Make a group of unit tests that can accept an object of the type in question, and tests the behavior.

If the test passes, you're good to go. If they fail, something is amiss and you should check your code.

That said, you have no elegant way of forcing this to a third party if you're developing an API, nor should you have. That's not what C# Interfaces are for.

Answer 4

State transitions can be represented by separate interfaces per state:

public interface IEnabledComponent
{
    IDisabledComponent ToDisabled();
}

public interface IDisabledComponent
{
    IEnabledComponent ToEnabled();
}

This is much more powerful and safe, since you can expose different methods depending on the current state. In particular you wouldn't even need the IsEnabled property.

Alternatively you could have a single really simple interface:

public interface IComponent
{
    bool IsEnabled {get;set;}
}

Here the state is represented in a single member, so no need to coordinate multiple related members.

You would chose the first options if the different states cause different behavior, the second if the enabled-state doesn't affect other behavior.

The fact that you can define a behavioral relationship between different members of an interface indicates that they are expressing the same information and therefore are redundant. To take a simpler example:

interface IComponent 
{
  bool IsEnabled {get;set;}
  bool IsDisabled {get;set;}
}

Here you could define the relationship that if IsEnabled is true, then IsDisabled is false. But this just shows that one of them could be eliminated since it doesn't represent any independent information or behavior.

Answer 5

One more option when you want usage pattern to look "traditional"^* but can limit the interface so it does not require methods to be tied together you can use extension methods to "add" missing methods.

In your example interface can just contain IsEnabled {get;set;} and Enable and Disable can be extensions coming as part of your library defining the interface:

public interface IComponent
{
    bool IsEnabled {get;set;}
}

public static class IComponentExtensions
{
    public static void Enable(this IComponent component)
    {
         component.IsEnabled = true;
    } 
    public static void Disable(this IComponent component)
    {
         component.IsEnabled = false;
    } 
}

Note that since instance methods have priority over extensions and concrete classes may implement methods with same signature to force compiler to pick the class specific implementation possibly causing some confusion. On other hand pretty much everyone has significant experience with this pattern in LINQ - so worth considering if your interface can be narrowed down to allow it.

---

_{^* "traditional" interface in sense of people expecting to have some particular methods on particular types - for example Stream classes in Framework - one expects file to have "Open" and "Close" when regular streams just "new"/"Dispose".}

Answer 6

Here is another idea to solve this using a completely different approach than the one shown in my other answer (hence I post it separately): utilize the template method pattern. Again, let us - for the sake of the example, assume the requirement to make IsEnabled work as described is justified for some reason, and you want to make sure it's state is updated correctly.

Then you could replace the interface by an abstract class, make IsEnabled a boolean property which is switched unconditionally (even in case of an exception), and let a user of that abstract class implement two template methods instead of the original ones:

public abstract class Component  // replacement for IComponent 
{
    public bool IsEnabled{get;private set;}

    public void Enable()
    {
       try
       {
          EnableImpl();
       }
       finally
       {
          IsEnabled=true;
       }
    }
    public void Disable()
    {
       try
       {
          DisableImpl();
       }
       finally
       {
          IsEnabled=false;
       }
    }

    protected virtual void EnableImpl();
    protected virtual void DisableImpl();
}

Now, users can override EnableImpl and DisableImpl by their own implementations, whilst the state tracking is guaranteed to be done.

This approach is definitely more standard than my first suggestion and I would not expect it to become deprecated by Microsoft soon.

Answer 7

An alternative solution (which I would not generally recommend, but accomplishes what you are after) would be this.

public class Switch //make sealed if you really want to enforce behaviour
{  

    public bool IsEnabled {get; private set;}

    public void Enable() //make virtual if you don't want to enforce this behaviour
    { 
        IsEnabled = true;
    }

    public void Disable() //make virtual if you don't want to enforce this behaviour
    {
        IsEnabled = false;
    }
}

public interface IComponent {
    Switch Switch{get;}
}

Answer 8

Simple answer: no.

That’s not what interfaces do. Each element of an interface is independent of every other element. It is up to the implementor as to what happens when called. Your interface can be implemented by anything, and what it does is up to concrete object.

The Disable method could do something entirely unrelated to the Enable method, and the IsEnabled property might return a value that is unrelated to either (for instance a constant value).

Simplest real world example — when your start implementing a interface, it is common to throw a not implemented exception.

It is up to the implementor to figure out how it all hangs together.