When to Design an Inteface

[Jared Malcolm]

I've read the FAQ: InterfaceVSAbstract

I'm mainly curious when you are designing a new piece of software what is it that tell you do design an Interface vs just building a class and using it? I'm familiar with the use, but I'm still new at designing my own pieces of software and still am just not sure what I should look for as to when I should design and Interface to Implement vs a class to use...

Again, I'm aware of HOW I just don't have the WHEN...

[William P O'Sullivan]

When you want to ensure that every implementer actually implements the methods in the interface.

For example, if you wanted every IMPLementer Class to log or other common methods.

WP

[Jeff Verdegan]

As a rough guideline, a good starting point is, "Is this a very specialized type that only has this one particular useful form? Or is this a higher-level generality that might take different forms in how it's actually implemented, depending on which specific kind of use-case it's supposed to handle.

For instance, I recently wanted to be able to represent ranges, such as 1-5, 10-20 without having to specifically list every element, but still be able to iterate over all the elements, determine how many elements it had, determine whether a particular value was included in that range, etc. I could have just defined a Range<T extends Number> class and done simple arithmetic to realize that functionality. However, at about the same time, I also had a use for specifying ranges of IP addresses the same way, such as 192.168.0.* or 192.168.0.100-200. The operations I would want to do in both cases were the same, but the simple math that work for a range of numbers wouldn't work for IP addresses.

So I defined an interface Range<E extends Comparable<E>> extends Iterable<E>. There are one or two sub-interfaces, a couple of abstract classes, and a couple of concrete classes. I can now do stuff like:

Range<Integer> r1 = new IntegerRange("1-5, 10-20");
for (int i : r1) { ... }

// and

Range<IpAddress> r2 = new IpAddressRange("192.168.*");
if (r2.contains(someIpAddress)) { ... }

[Jeff Verdegan]

William P O'Sullivan wrote:When you want to ensure that every implementer actually implements the methods in the interface.

That doesn't really make any sense. If you just want to ensure that all the methods are implemented, you can create a concrete class.

The point is that when you want there to be able to be multiple implementations, and there isn't any one "default" umbrella that could reasonably encompass them all.

[Randall Twede]

here is an example i recently wrote for solving project Euler problems

interface Problem
{
	String solve();
	
	String getMessage();
}

all problems are solved using a class that implements Problem. this allows you to treat them all the same.

	public void actionPerformed(ActionEvent e)
	{
		output.setText("");
		Problem choice = map.get(problems.getSelectedItem());
		int reply = JOptionPane.showConfirmDialog(frame, choice.getMessage(), "information", JOptionPane.OK_CANCEL_OPTION);
		if (reply == JOptionPane.OK_OPTION)
		{
			output.setText(choice.solve());
		}
	}

[Winston Gutkowski]

Jared Malcolm wrote:I'm mainly curious when you are designing a new piece of software what is it that tell you do design an Interface vs just building a class and using it?...
Again, I'm aware of HOW I just don't have the WHEN...

I think my advice would be to always think about an interface first.

If, as Jeff says, you find that the type is highly specialized and is only ever likely to have one implementation, then you can always drop the interface in favour of a single concrete class; it's more difficult (and sometimes impossible) to retro-fit an interface to an existing class if you find out later that you have an alternative implementation.

Winston