Why does the use of interface-based programming appear to be limited to behaviour?

Question

I have been doing a little thinking about inheritance vs. realization vs. composition. I am not about to post the whole detail here. So I was wondering, when we are not talking about creating interfaces to facilitate unit testing: Why does interface-based programming seem to focus upon the grouping of common behaviour, e.g., IPettable (for an animal), IEditable (for a user control), ISubmitable (for a form), etc. Why does the use of interface-based programming appear to be limited to behaviour and not essences. We could pragmatically use an interface, not so much realize behaviour but, to realize commonsense physical similarities which could have nothing to do with behaviour? It is not that there is some limiting feature within interface-based programming that we do not think to do this. This means that there is a tendency to use an interface in a fraction of its possible ways; so how come?

Answer 1

It's not a limitation but rather an advantage - Interfaces should be written to make life easy for the consumer of an interface, and the consumer is interested in what it can do with the object. Thus successful interfaces are those that align closely with how an object is used by others (by petting, editing, or submitting to use your examples).

In any case there do exist marker interfaces in the wild, such as Serializable in the Javaverse or IDisposable in the .NET world. Personally I've always found them kind of kludgey but your mileage may vary.

Answer 2

Interfaces are a small building block that can be used to build up a number of design patterns (see Design Patterns, Gamma et al., or http://en.wikipedia.org/wiki/Design_pattern_(computer_science) for a summary). A scan over the different sorts of design patterns will show you a wider variety of ways interfaces are used.

Particularly, you may want to compare the decorator pattern and the façade pattern. The examples you have are almost all decorators, little add-ons that add functionality. In contrast, façades are like contracts that define an expected set of actions to be implemented. (note: those are both simplified explanations, do review these in my suggested references). Interfaces can be used to implement both of those patterns, and you will find them implemented that way often in interface driven languages like Java.

Answer 3

I am under the impression that what you are looking for is General Programming... not sure though :/

In general programming you will have:

interface Pettable {
  void eat(Food f);
  void move(Direction, Distance);
}

And then you'll create a class:

class Cat {
  void eat(Food f);
  void move(Direction, Distance);
}

And any method that accepts a Pettable will instantly accept a Cat, not because you have derived from Pettable but because it simply models it, and the compiler realizes it.

Some languages are even more "generic" and do not require you to declare an interface at all, rather they derive it from the requirements of the method (C++ in templates at compile-time, Python at runtime).

Answer 4

Interfaces effectively define a presentation contract, and provide a means to offer compatibility between classes at a very abstract level. When you use an interface, you are effectively saying "this class is defined in one way, but can be used in another way to be compatible with another class".

Basically you are defining a use case. You aren't usually going to ask an object for it's properties via an interface if you have access to the object itself. You will however be normally asking that object to behave in a manner that might be consistent with the behavior of other class types in a system, so that each can be called and expected to behave in a similar and consistent manner. That's Polymorphism 101.

Now, I'll contradict myself a little. I said earlier that you normally don't ask the class for it's properties via an interface. The intention with interfaces as defined is certainly to behave that way. However you can request that a class provide you with it's properties via an Interface, but you use method instead of property syntax. In this case, you are requesting the class (via an interface) to behave in a manner that allows you to retrieve values via a getter method. It's classic request/response behaviour, which is totally in keeping with the fundamental behavioral nature of Interfaces, while not precluding the ability to treat a class as if it were merely a simpler data structure, or a type compatible with other classes via a common Interface abstraction.

Getter/Setter behavior is also in keeping with providing encapsulation for all of your internal variables. Languages such as Delphi, and now C# with it's automatic properties tend to blur the lines and make properties seem as if they act like mere variables, yet the reality is that for each property there is a getter and setter method underneath the hood for each property. And if not, there should be in order to preserve encapsulation.

Taken from this perspective, Interfaces aren't limited to only behavior. They effectively are enhanced by it, and in turn enhance the classes which implement them.

Answer 5

OOP is not limited to behaviours, rather it contains characterstics, so do the interfaces. e.g. IPerson can have both Characterstics{a.k.a properties} as well as behaiours{a.k.a methods}. Interface based programming tend to abstract the real world problems into the programming world while on the other hand inheritance/realization/compositions actuates the real world. In short interfaces defines contracts/types {which who ever will fulfill, will become that type.} while classes(inheritance/composition) defines implementations of those contracts. e.g. say I have an interface ICandian that has a boolean characterstic BornInCanada , defining that interface does nothing but defines a contract that to be canadian you must provide a boolean value, so any person who gives an implementation of BornInCanada becomes that Type i-e ICanadian. Hope you got my point.