Mamy więc taki interfejs
/// <summary>
/// Interface for classes capable of creating foos
/// </summary>
public interface ICreatesFoo
{
/// <summary>
/// Creates foos
/// </summary>
void Create(Foo foo);
/// <summary>
/// Does Bar stuff
/// </summary>
void Bar();
}
Niedawno odtworzyliśmy historię dokumentacji, która polegała na wygenerowaniu i zapewnieniu dużej ilości dokumentacji XML, jak wyżej. Spowodowało to jednak znaczne powielanie dokumentacji. Przykładowa implementacja:
/// <summary>
/// A Foo Creator which is fast
/// </summary>
public class FastFooCreator : ICreatesFoo
{
/// <summary>
/// Creates foos
/// </summary>
public void Create(Foo foo)
{
//insert code here
}
/// <summary>
/// Does Bar stuff
/// </summary>
public void Bar()
{
//code here
}
}
Jak widać, dokumentacja metody jest prostym zgrywaniem z interfejsu.
Najważniejsze pytanie brzmi: czy to źle? Moje jelita mówi mi tak z powodu duplikacji, ale z drugiej strony może nie?
Mamy też inne podobne powielanie dokumentacji z override
funkcjami i virtual
funkcjami.
Czy to jest złe i należy tego unikać, czy nie? Czy to w ogóle się opłaca?
Odpowiedzi:
Ogólnie rzecz biorąc, dodawałbym nową dokumentację do metod implementacji tylko wtedy, gdy jest coś konkretnego w tej implementacji, o czym trzeba wspomnieć.
W javadoc możesz połączyć się z innymi metodami, które pozwoliłyby ci po prostu utworzyć link w implementacji do dokumentacji metody w interfejsie. Myślę, że tak powinno się to odbywać w .Net (na podstawie mojej lektury dokumentacji online, a nie własnego doświadczenia):
Dokumentacja
<see/>
elementu: http://msdn.microsoft.com/en-us/library/acd0tfbe.aspxźródło
Collection<T>
i chcę zastąpić jejCount
właściwości dokumenty XML.