The purpose of interfaces continued

Question

OK so I gather that Interfaces are a way to enforce that an object implements a certain amount of functionality, without having to use inheritance. Kind of like a contract.

Answer 1

Using interfaces is more about giving the consuming code a way to know what you expect from it, rather than you needing to be concerned about the details of the consuming code.

For example, one of the ways we use interfaces a lot is in our Business Layer / Data Access Layer.

Because our business layer (BL) assembly will communicate with directly with the data access layer (DAL) assembly, the DAL cannot communicate directly with the BL. What happens if the DAL wants to use objects rather than individual fields? You would have to define your own DAL objects, and hydrate them with the input you've just received. Basically, a lot more work, more resources consumed, and multiple objects that represent the same data which makes for a maintenance nightmare.

But, if you define interfaces in the DAL, you can tell consumers of the DAL what it expects. Then you can implement those interfaces in the BL and pass instances of the interfaces instead of BL objects.

Interfaces are all about abstracting out the details of the implementation where they're not absolutely necessary.

[Edit] If you have a lot of objects that do similar things, a combination of an interface and a base class with overridable/virtual methods might be more useful than just an interface.

Answer 2

and it has no implementation as such then whoever uses your interface has to write it from scratch..every time.

Each implementation of the interface can be different. The point is that you can use interface without knowing the implementation. Consider example:

public interface ILogger
{
    void WriteMessage(string message);
}

Your application may use ILogger interface for logging errors/debug information, etc. But it doesn't matter how logger is implemented - it can be FileSystemLogger, or DatabaseLogger, or any other implementation. So you will be able to substitute implementations at any time without changing all places in code where logging was mentioned.

Answer 3

You are thinking about it backwards. Instead of thinking about the implementation first, you think about behavior (as described by the method signature) first. Then you implement the behavior as appropriate in the base classes giving a much more flexible, extensible system. You dismissed "design by contract' pretty quickly, but it's a key design strategy and the basis for web services, SOA, etc.

Answer 4

And old thread, I know. But I just read "Interfaces are the only way to create multiple inheritance in Java". This is very wrong, because delegation (or "compositon" as Carl said) is the only way to get multiple inheritance (remember: "delegation is inheritance", well, almost).

You only need interfaces to tell the developer "hey, don't forget to delegate this or that class"! Interfaces are only needed as reminder for a correct delegation (or in general: implementation), but they can't inherite any code. With multiple inheritance interfaces wouldn't be needed at all.

Actually, you don't really need interfaces to create a working program, they're just helpers without any function or functional code. Btw Thomas was very right with the abstract classes, these are far more important than interfaces, because that's where you can get reusable code from.

Normally, when I write a java application I only create interfaces in the very end, as a helper for future programmers. Or I don't create any interfaces at all ;D

Answer 5

This isn't really an answer so much as an example that I find helpful when thinking about interfaces, but think about the interface Comparable<T> which requires the method

public int compareTo(T anotherObject)

The user can implement this however he or she wants. If a Person implements Comparable<Person>, for example, the comparison can be based on last name then first name, ignoring capitalization. Or it can be based on age, etc. However the user wants. Implementing this interface is very useful, in that it allows the user to use things like Collections.sort() which require that the elements to be sorted need to be comparable (how else could a comparison be made?)

Answer 6

You should think of an interface as an authoritative declaration of behaviour, which has nothing to do with implementation issues in the first place.

If you want to avoid code duplication, then you use an abstract base class in combination with the interface. Here you then can implement all the stuff that might be repeated in all interface-implementing classes otherwise.

HTH.
Thomas