2

I do not know the "correct" name of that pattern, so I'd like to describe it with a simple example.

In C#, System.Windows.Window contains a ShowDialog method. I can define an interface containing this method (plus some other functionality). When I create a new Window class, it will inherit from Window, and I can add my interface. Now, I do not need to care for the ShowDialog method at all: "magically" the method of Window is used, though Window does not know my interface.

A simple sample code:

public interface IMyWindow
{
    bool? ShowDialog();
    // some additional other methods/properties
}

public class MyWindow : Window, IMyWindow
{
    // ShowDialog is "magically" implemented by Window
    #region additional other methods/properties
    #endregion
}

public class MyClass
{
    public void DoSomething()
    {
        IWindow w = new MyWindow();
        bool? result = w.ShowDialog();
    }
}

How is that pattern called? How common is its use? Or is it just some side-effect of other functionality of .Net, actually nothing intentionally designed? How do other object-oriented languages deal with that?

Edit:

Long ago I asked the question https://stackoverflow.com/questions/23242308/combined-type-generics-something-else - I'd now use an approach based on the method described above.

  • This feels like a form of Mixin inheritance (where each mixin implements some fragment of a complete interface) - but that describes the structure rather than the language feature that allows it. – Useless Nov 12 '18 at 11:40
  • I don't think duck-typing applies to statically typed languages, and I'm not sure what you're talking about is duck-typing related (I am admittedly confused by your question). You have to explicitly make sure that the types line up in a statically typed language, or your code won't compile. Whether or not you auto-gen that code is irrelevant. The power of duck-typing is that you don't have to make sure the types line up, and you can just pass around things that look and feel the same w.r.t. certain functions/interfaces, even though they may be wildly different. – Matt Messersmith Nov 12 '18 at 16:38
  • 1
    @MattMessersmith System.Windows.Window does not know anything about my interface - from its point of view, the method declared in my interface just happens to coincide with one of its methods. That's why it looks like duck typing to me, though eventually I get a strongly typed item (and that may be confusing - you can surely read my uncertainty about the pattern between the lines). – Bernhard Hiller Nov 14 '18 at 8:42
  • @MattMessersmith Well there is some duck-typing going in in C#, e. g. for the foreach construct which works on any type that exposes a valid GetEnumerator method. Something similar with await which needs a GetAwaiter method (I think). – germi Nov 14 '18 at 11:15
1

This is an instance of the class adapter pattern, where you use multiple inheritance to inherit from both a base class, and from an interface that you want to adapt the base class to. That you do not have to explicitly implement the interface function is merely a side effect of how interfaces work in C#.

5

This isn't actually "magic", and as far as I'm aware there is no specific name for it. It is the default behavior of interface implementation.

The core issue of your question is not that there is an explicit "duck typing like" feature that enables this behavior. The core issue is that you misunderstand what an interface contract stipulates and expects from any type that implements it.

public class MyWindow : Window, IMyWindow
{
    // ShowDialog is "magically" implemented by Window
}

The fact that you call it "magic" suggests that you expect an interface contract to require that this class must explicitly implement a certain method, but that is not the case.

A similar but slightly simpler example:

public interface ITest
{
    string ToString();
}

public class Test : ITest
{

}

The compiler does not complain. Because every class inherently inherits from object, and object already has a string ToString() method, the Test class satisfies the interface contract because Test has a string ToString() method.

It's a fairly common misunderstanding of inheritance, where developers think of a derived class and its base class as if they are two separate elements of "the full package". But that is not the case.

For all intents and purposes, when considering the derived class, the features that are defined in the base class are equal in every way to the features that are defined in the derived class itself. The derived class would work exactly the same way if you were to copy/paste the base class' definition inside of the derived class' definition (instead of using inheritance).

Think of it as a "one way partial classes". Two partial classes operate exactly as if they were a single class definition - there is no difference between the two whatsoever (other than the ability to spread it over multiple files). For the inheritance example, I call it "one way" because the derived class includes the base class, but the base class does not include the derived class.


From a comment you made:

System.Windows.Window does not know anything about my interface - from its point of view, the method declared in my interface just happens to coincide with one of its methods.

But you're not expecting System.Windows.Window to implement your interface - which is why your expectation is irrelevant.

All you are doing is expecting MyWindow to implement the IWindow interface, whose contract can be summarized as "must have a bool? ShowDialog() method".

MyWindow does in fact have a bool? ShowDialog() method. Whether it explicitly defines its own bool? ShowDialog() method or inherits one is absolutely irrelevant. The compiler doesn't care about the source of the method, only that it exists.

Therefore the contract (MyWindow : IMyWindow) is satisfied, and thus no error is encountered.

As a very simple (and somewhat oversimplified) analogy: when I want to buy a $5 drink, does the shopkeeper care where the money comes from? E.g. I could be paying from my inheritance, I could've earned the money myself, I could've borrowed it from a friend.
The shop keeper doesn't care where the money comes from. All the shopkeeper cares about is that I have $5 to pay for the drink.

  • Thanks for this long detailed answer. The twist of thought is that I "expected" an interface to be defined first, then create some classes implementing it. Now I can "add" interfaces to classes which were designed without the interface and are outside of my control. That's an inversion of my workflow. – Bernhard Hiller Nov 16 '18 at 9:46
  • @BernhardHiller: To be fair, I've never intentionally used this, I don't think it was intentionally ut in for some explicit purpose. – Flater Nov 16 '18 at 11:12
1

I don't think this has a name.

C# interface implementation is based on available methods. Base methods are available. While this is in contrast to C++, where a method from one base doesn't override the abstract method from another, C++ doesn't have designated interfaces as such. Java works the same way as C#.

Unless you can find a language that has designated interfaces and behaves differently from C# and Java, there's no need to name this feature; it's just the way interfaces work.

If you really want to make the point of calling this out, you could call it explicit interface method binding vs implicit interface method binding. Note that C# has the "explicit interface implementation" feature.

0

I'm not sure what the point of this construction is. All that implementing an interface does is promise that a certain signature exists in that class - it doesn't matter whether the class defines the method itself or inherits it.

Now, MyWindow already guarantees that the method exists because it extends Window, so the additional promise made via IMyWindow does nothing. This makes sense only if you want to use such objects in a context where you prefer not having to know about Window objects, just about IMyWindow. This could be called a form of interface segregation.

But is this likely? Even if you don't want to deal with all the complexity of the API of Window, will you conceivably want to show dialogs without ultimately making use of the system Window class? Do you plan other classes which show dialogs via some completely different channel?

  • That's the point: I can now pass that item as an IMyWindow to other functions - they do not need to know about other implementation details. The example above was made up with a Window base class - but it could be something totally different. Could be a List, where I only need specific parts of the functionality (but with Lists, there are so many interfaces available making such a construction unlikely). – Bernhard Hiller Nov 14 '18 at 8:37

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.