Say, I have two classes:
Airplane and Bird, both of them fly. Both implement the interface IFly. IFly declares a function StartFlying()
. Thus both Airplane and Bird have to define the function, and use it as per their requirement.
Now when I make a manual for class reference, what should I write for the function StartFlying
?
1) StartFlying
is a function of type IFly .
2) StartFlying
is a function of type Airplane
3) StartFlying
is a function of type Bird.
My opinion is 2 and 3 are more informative. But what i see is that class references use the 1st one. They say what interface the function is declared in. Problem is, I really don’t get any usable information from knowing StartFlying
is IFly type. However, knowing that StartFlying
is a function inside Airplane and Bird, is more informative, as I can decide which instance (Airplane or Bird ) to use.
Any lights on this: how saying StartFlying
is a function of type IFly, can help a programmer understanding how to use the function?
1
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.
13
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.