Programming Languages – Why Interfaces Require Methods Over Members

interfaceslanguage-designprogramming-languages

…As this forces us to create getters and setters, which in practice are often totally extraneous? Is there any good language-design reason why interfaces in most (all?) languages do not allow member fields to help fulfill the interface spec?

In most extant languages, members are treated fundamentally differently from methods, but does this HAVE to be the case? In a theoretical language, couldn't we have an interface that (a) specified a zero-args method as getter, but accepted a readable member as its implementor, and (b) specified a single-arg method as a setter, but accepted a writable member field as its implementor, given a language that supported specifying direct access control on variables when they are declared? A prototypal language allowing multiple inheritance (to address the very valid point some respondents have made), would be ideal for something like this.

Please inform me if something like this already exists.

Best Answer

In most extant languages, member [fields?] are treated fundamentally differently from methods, but does this HAVE to be the case?

Yes, it does.

Member fields are per-instance data. Data must actually exist somewhere in memory for every instance - there must be an address or sequence of addresses reserved for it. In Java, .NET, and many other OO languages, this data goes on the heap.

Methods are per-class data. They are pointers to a vtable. That's how methods get virtual dispatch. There is only actually one instance allocated, per class.

An interface is essentially a special type of class that only contains methods, no instance data. That's part of the definition of interface. If it contained any data, it wouldn't be an interface anymore, it would be an abstract class. Both of those choices are fine, of course, depending on what kind of design pattern you're trying to implement. But if you added instance data to interfaces, you'd take away everything that makes them interfaces.

OK, so why can't an interface method point to a member field? Because there's nothing at the class level to point to. Again, an interface is nothing but a method table. The compiler can only generate one table, and every method in it has to point to the same memory address. Thus it's impossible for interface methods to point to class fields, because the class field is a different address for every instance.

Perhaps the compiler could accept this anyway and generate a getter method for the interface to point to - but then that essentially becomes a property. If you want to know why Java doesn't have properties, well... that's a really long and tedious story that I'd rather not get into here. But if you're interested, you might want to have a look at other OO languages which do implement properties, such as C# or Delphi. The syntax is really easy:

public interface IFoo
{
    int Bar { get; }
}

public class Foo : IFoo
{
    public int Bar { get; set; }
}

Yep, that's all there is to it. Important: These are not fields, the "int Bar" in the Foo class is an Auto Property, and the compiler is doing exactly what I just described above: automatically generating getters and setters (as well as the backing member field).

So to recap the answer to your question:

  • Interfaces require methods because their entire purpose is not to contain any data;
  • The reason that there is no syntactic sugar to make it easier for a class to implement an interface is simply that the Java designers do not will it - and by this point in time, backward compatibility is an issue. Language designers make these kinds of choices; you'll just have to deal with it, or switch.
Related Topic