I am extracting interfaces from some classes in .NET, and I am not completely su

Question

I am extracting interfaces from some classes in .NET, and I am not completely sure about what level of detail of description to use for some of the interface members (properties, methods).

An example:

interface ISomeInterface
{
    /// <summary>
    /// Checks if the object is checked out.
    /// </summary>
    /// <returns>
    /// Returns true if the object is checked out, or if the object locking is not enabled,
    /// otherwise returns false.
    /// </returns>
    bool IsObjectCheckedOut();
}

class SomeImplementation : ISomeInterface
{
    public bool IsObjectCheckedOut()
    {
        // An implementation of the method that returns true if the object is checked out,
        // or if the object locking is not enabled
    }
}
The part in question is the <returns>...</returns> section of the IsObjectCheckedOut description in the interface.

Is it ok to include such a detail about return value in the interface itself, as the code that will work with the interface should know exactly what that method will do? All the current implementations of the method will do just that. But is it ok to limit the possible other/future implementations by description this way?

Or should this not be included in the interface description, as there is no way to actually ensure that other/future implementations will do exactly this? Is it better to be as general as possible regarding the interface in such circumstances?

I am currently inclined to the latter option.

Explanation / Answer

I would advise taking a step back and looking at what you're trying to achieve.

What does the XML documentation give you? XDoc Documentation? Think about what you want to see in that document. Intellisense? Think about what you want to see when someone is using that method from the interface. Or are you just doing it because you think you should? If so then stop it, you're wasting valuable time.

Already I can see that the method name doesn't match what the method does. And that's probably the reason you're having to ask this question.

Should the method really be named IsObjectCheckedOutOrNonLockable()? Or does IsObjectNonLockable() implicitly include "checked out" on the objects you currently have implemented? Or is there a better description that covers all those conditions?

Does renaming the method make it more obvious what you should put in the XML documentation andmore obvious what is expected of future implementations?

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.