In a language where it is possible to define interfaces and typedefs (using Dart here):

abstract class Receiver {
  void receive(int quantity);

typedef void Receive(int quantity);

abstract class Transport {
  void deliver(Receiver receiver);
  void deliver(Receive receive);

Conceptually, are single method interface and type definition on functions the same thing? Is there any benefits from using one over the other?

  • I don't know much about Dart, but if that amounts to a global function declaration, it means that you don't need a class or object reference to call it; you can simply call it. – Robert Harvey Feb 21 '15 at 18:47
  • @RobertHarvey a type definition in Dart doesn't include an implementation. It only assigns a name to a function signature. In this case, Receive is just a void (int). As long as you provide a function with that signature, it matches that definition. – ebelanger Feb 21 '15 at 19:45
  • An interface defines not just a signature, but also a semantic contract. Two one-method interfaces with the same method signature are not interchangeable. To make signatures more restrictive, you can use value types. Check programmers.stackexchange.com/questions/286942/…, as proposed by AlexFoxGill. – donquixote Apr 24 '18 at 0:48
  • Also some languages (e.g. PHP in current versions) do not allow to constrain the allowed signatures for callable parameters, so there interfaces are the better choice. – donquixote Apr 24 '18 at 0:50

Single method interfaces and functions (or functions type definitions) are almost the same. Function type definitions are just anonymous interfaces. Interfaces and function type definitions both serve the same purpose. And together with their implementation they could be described as mathematical duals. An object (or in this case a single method interface with implemention) is data (state) with behavior and a function is behavior with data, called a closure when data is partially applied. In C# e.g. the compiled IL code is similar in both cases (at least when it is reverse engineered). This and the correspondence to the concept of duals is described by Mark Seemann here. Note that this holds for C# and might be different in other languages or with other compilers.

In object oriented languages the intent of interfaces is to decouple the code and to be able to inverse the control (as in IoC). This gives you lots of benefits like reduced dependencies and therefore maintainability, evolvability, testability etc. In functional programming the same thing is achieved by using functions type definitions. In some languages you can do both.

Major differences is that interfaces are a bit more verbose with some boiler plate code. Functions are more concise. I'm not sure if all IoC Containers can handle functions as parameters. Also and even more important the way of programming might become very different when you go for one or the other depending on the context. If it's not convenient (meaning not idiomatic) in the language to use type definitions e.g. it can make things complicated when working in a team. So a good advice is probably to check the language's coding guide lines and conventions. (I don't know Dart so I can't help you here.)

  • I don't know what you're talking about. The invocation of delegates and interface functions are decidedly different in IL. – Telastyn Feb 22 '15 at 1:56
  • Hi @Telastyn, I quoted Mark Seemann on this. Please check out the link. Anyway I made my answer a little more precise because actually dependency injection and partial application is involved. Thanks for pointing that out. – leifbattermann Feb 22 '15 at 8:39
  • Sure closures look and act like classes because they effectively are classes. But not all delegates are closures. Either way, delegates (closures or not) are called via IL to call System.Action::Invoke (or Func) whereas interface calls are callvirt <interface method>. The performance also often differs (though less significantly these days due to optimization on delegate calls). – Telastyn Feb 22 '15 at 14:54

Conceptually, are single method interface and type definition on functions the same thing?


In most languages that allow both, the function typedef defines a type whose values are functions and nothing else. The abstract class defines an interface which has a function (and likely, other things).

Things can get muddled with closures (which are functions, but often have other things) and/or C++ style functors (classes that have operator() overloaded), or even with implicit conversions to function types.

But the two mechanisms serve different purposes and should be conceptually different, even if mechanically they can be made to do the same things.

  • Could it be possible to elaborate on what purposes the mechanisms serve? It's still not clear to me how they differ. Isn't passing an implementation on an interface or passing the implementation method pointer that same thing? – ebelanger Feb 21 '15 at 19:49
  • @ebelanger - not quite... an analogy: you want something to make light. If I give you a flashlight, it has a button (expected input) and makes light (expected output). If I give you a car, you still have a button and you can still make light, but it's surrounded by a whole lot of other unrelated functionality. If you use the typedef, it's saying that you want a flashlight. If you use the interface, it's saying that you want a flashlight, but a car will do. – Telastyn Feb 21 '15 at 19:53
  • Still not clear for me, I'm sorry. I still don't see a difference between providing me a void CreateLight() vs a interface LightMaker {void CreateLight()}. A typedef is only named function with no implementation, just like an interface is a named abstraction with no implementation. – ebelanger Feb 21 '15 at 20:04
  • @ebelanger - but you can extend the interface though. – Telastyn Feb 21 '15 at 20:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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