Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
What happens if there are lots of classes that implement IFly? Are you going to list them all each time? It can be easier to note where the function is declared and look at what classes implement this interface to find which classes may be useful as there may be lots of them. –  JB King Sep 30 '12 at 22:00

2 Answers 2

up vote 4 down vote accepted

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.

share|improve this answer
3  
"Any recent programming book recommends to not name your interfaces with I in front.": what is the motivation for this recommendation? –  Giorgio Sep 29 '12 at 10:09
2  
And that's why all of the interfaces in the .Net library start with I, Just as many other big projects which use this convention. I think you've got it wrong. That is, unless camelCasing also has been deprecated recently.... The comment on the documentation of code is good, but there are conventions to be followed if we want to be able to understand which things are interfaces and which things are classes without diving into the sources. –  Onno Sep 29 '12 at 10:57
1  
@Giorgio - the motivation is that the interface is the place where the abstract concept of your logic is contained. So, naming it accordingly makes not only the code more readable and natural but also easier to remember. And than, there is the fact that interfaces belong to their clients and not to their implementations. You will have, somewhere in your code, a method / object / module using a FlyingObject (instead of a IFly). However that module will not know or care that what it gets is an Aitplane or a Helicopter. It will only care about the fact that it can fly. –  Patkos Csaba Sep 29 '12 at 11:52
4  
@PatkosCsaba well, the Microsoft guidelines for C# say explicitly: - "Do not give class names a prefix (such as the letter C). Interfaces, which should begin with the letter I, are the exception to this rule." No prefix in Java though :) –  Patryk Ćwiek Sep 29 '12 at 13:57
1  
@MainMa It's not mandatory, only recommended. There's nothing in the C# language specification that requires interface names to be prefixed with the letter 'I', but it is a recommended practice. –  pmarflee Sep 30 '12 at 17:06

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.