PHPDoc для интерфейса и класса, реализующего интерфейс - различие [закрыто]
Вопрос довольно прост - как я должен различать phpdoc для интерфейса и для интерфейса, реализующего класс? Должны/могут ли они быть одинаковыми или, возможно, документация по интерфейсу должна быть как можно более общей, а класс, реализующий этот интерфейс, более конкретным?
Я включаю один метод PHPDoc из моего реального кода:
Мой интерфейс:
interface CacheInterface
{
/**
* Adds data to cache
*
* @param string $objectId Name of object to store in cache
* @param mixed $objectValue Data to store in cache
* @param mixed $lifetime Lifetime of cache file
* @param string $group Name of cache group.
* @param array $params Parameters that distinct cache files.
* @param array $files Name of files that are checked if cache is valid.
* @return bool True if cache was created, false if cache was not created
*/
public function put(
$objectId,
$objectValue,
$lifetime = null,
$group = null,
$params = array(),
$files = array()
);
}
Мой класс, реализующий интерфейс:
class Cache implements CacheInterface
{
/**
* Adds data to cache
*
* @param string $objectId Name of object. If it begins with : cache filename will be created using hash
* function. If name doesn't begin with : it should use ASCII characters to avoid
* problems with filenames
* @param mixed $objectValue Data to store in cache
* @param mixed $lifetime Lifetime of cache file. If none provided it will use the one set in contructor.
* Possible lifetime values: time in seconds (3600 means that cache is valid
* for 1 hour = 3600 seconds) or one of TIME_ constants @see CacheInterface
* @param string $group Name of cache group. If none/null provided it will use the one set in constructor.
* Sub-groups should be created using | for example group|subgroup|subgroup2
* @param array $params Parameters that distinct cache files. You can for example pass here array('id' => 1)
* to set cache for user id. If $params is not empty, they are also used to generate
* file name. That's way they should rather include simple ASCII values
* @param array $files Name of files that are checked if cache is valid. It should be numerical array
* (not assosiative). If files are not empty when getting data from cache it's checked
* wheteher those files exists and are created earlier than cache was created.
* If any of those conditions is not met cache file is treated as invalid
* @return bool True if cache was created, false if cache was not created
*/
public function put(
$objectId,
$objectValue,
$lifetime = null,
$group = null,
$params = array(),
$files = array()
) {
// implementation here
}
}
Так ли должна выглядеть документация? Более общий для интерфейса и более конкретно для класса, реализующего этот интерфейс?
2 answers
Прямой ответ на ваш прямой вопрос - "да". Более общие описания интерфейса хороши, и вы должны только дополнить эту информацию в описаниях классов. Я бы предпочел не дублировать теги методов класса, потому что, поступая таким образом, вы предотвращаете отображение информации вашего интерфейса... вы фактически игнорируете его. Я понимаю, что рабочая проблема здесь заключается в том, что не все автозаполнения IDE и всплывающие окна с информацией правильно обрабатывают такое наследование анализ правильно (или вообще).
Как давний пользователь phpDocumentor и IDE, я рекомендую на самом деле только документировать интерфейс. Когда дело доходит до блоков документов для классов, реализующих интерфейс, единственная информация, которую я бы включил, - это тег @internal для записи информации, относящейся к разработчику, которая не должна отображаться в документах API интерфейса. Я ожидаю, что моя среда разработки будет знать, что метод реализации класса должен извлекать свои документы из docblock интерфейса.
Использование of {@inheritdoc} в дикой природе не согласуется с тем, что он действительно намеревается выполнить, и я думаю, что ошибки в обработке phpDocumentor 1.x этого тега с течением времени заставляли людей пробовать разные способы его использования, что затем привело к тому, что IDE также относились к нему по-разному. В результате я вообще больше не использую эту практику.