How do you define an interface, knowing that it should be immutable once published?

Question

Anyone who develops knows that code is a living thing, so how do you go about defining a "complete" interface when considerable functionality may not have been recognised before the interface is published?

Answer 1

Just make you best reasonable guess of the future, and if you will need more create second version of your interface.

Answer 2

Test it a lot. I've never encountered a panacea for this particular problem - there are different strategies depending on the particular needs of the consumers and the goals of the project - for example, are you Microsoft shipping the ASP.NET MVC framework, or are you building an internal LoB application? But distilled to its simplest, you can never go wrong by testing.

By testing, I mean using the interface to implement functionality. You are testing the contract to see if it can fulfill the needs. Come up with as many different possible uses for the interface you can think of, and implement them as far as you can go. Whiteboard the rest, and it should become clear what's missing. I'd say for a given "missing member", if you don't hit it within 3-5 iterations, you probably won't need it.

Answer 3

You cannot do it in a one-shot release. You need feedback.

What you can do is first make a clean interface that provide all the functionalities your library should provide; then expose it to your user base for real-world usage; then use the feedbacks as guide to update your interface -without adding features other than helper function/classes- until it starts to be stable on the interface.

You cannot rely only on experience/good-practice. It really helps but it's never enough. You simply need feedback.

Answer 4

Make sure the interface, or the interface technology (such as RPC, COM, CORBA, etc), has a well-defined mechanism for upgrades and enhanced interfaces.

For example, Microsoft frequently has MyInterface, followed by MyInterfaceEx, followed by MyInterfaceEx2, etc, etc.

Other systems have a means to query and negotiate for different versions of the interface (see DirectX, for one).

Answer 5

Version Numbers.

Define a "Complete Interface". Call it version 1.0.

Fix the problems. Call it version 2.0.

They're separate. They overlap in functionality, but they're separate.

Yes, you increase the effort to support both. That is, until you deprecate 1.0, and -- eventually -- stop support.