I think your confusion comes from the fact that you named your interface IFly. Any recent programming book recommends to not name your interfaces with I in front. Give your interface a proper name.

In your particular example it would be a little bit harder to do this, but let’s take this situation:

• Interface is: FlyingObject
• Implementation1: Airplane implements FlyingObject
• Implementation2: Helicopter implements FlyingObject
• Implementation3: UFO implements FlyingObject

If you do this and you try to write a documentation for it, it will be quite clear what StartFlying on FlyingObject means.

In some extreme cases, when it’s impossible to find the proper abstraction, you may name your interface with a concrete name like Foo and than the implementation FooImplementation or FooImpl.

UPDATE: Of course it always depends on what you are documenting and how. If you document your business logic, you can simply say that any FlyingObject has a startFlying() method. Your business logic will not create those objects, so you don’t care what are they exactly. In fact, this makes things much more clearer once you document that your business logic can use any object that has the startFlying() method and you connect that knowledge to the interface. You don’t care who creates the Airplane or Helicopter. All you know and document from the point of view of the business logic is that you can start flying if you have an object capable doing so.

On the other hand if you document your factories or whatever logic you have that decides what type of flying object to create, there you can document something like ‘Airplane, Helicopter, etc. must implement FlyingObject, otherwise they can’t take you to Japan’.

I hope this update clarifies all the question you were asking.

Say StartFlying() is a method/function in IFly. The documentation should include:

• How to find IFly, such as the namespace (.net or Java)/header file (e.g. C++) and file (such as an assembly in .Net or JAR file in Java).
• Specify what the caller needs to supply, such as arguments to the method and their allowable values,
• What the implementer needs to do, such as changes to other properties or return values.
• Error handling, such as what exceptions thrown and under what conditions.
• Security requirements. For example, does the user need to be a member of the Pilots group?
• Links to similar interfaces (e.g. IWalk, IRun)
• Link to an example or overview

You may want to include links or references to classes that implement IFly, such as Bird and Aeroplane but this may be manual and, therefore, prone to omissions or copy and paste errors.

Why describe StartFlying() in IFly in than Bird or Aeroplane? StartFlying() has been abstracted into an interface to standardize access similar functionality across disparate classes. This means other classes may implement it in the future beyond Bird and Aeroplane, both inside your library and outside.

Reference the documentation for IFly in the documentation for Bird and Aeroplane as well but these should also include implementation specific details. Aeroplane, for example, may require IsFueled() to be true, and including this in IFly would be confusing.