Вопрос довольно прост – как мне отличать 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 } }
Так должно выглядеть документация? Более общий для интерфейса и более конкретный для класса, реализующего этот интерфейс?
Прямой ответ на ваш прямой вопрос – «да». Более общие описания интерфейса хороши, и вы должны только увеличить эту информацию в описаниях классов. Я бы предпочел не дублировать теги в методах класса, потому что, делая это, вы не видите информацию о вашем интерфейсе … вы фактически переопределяете его. Я понимаю, что рабочая проблема заключается в том, что не все автозаполнения IDE и всплывающие окна информации правильно обрабатывают такой анализ наследования правильно (или вообще).
Как давний phpDocumentor и пользователь IDE, моя лучшая практика заключается в том, чтобы фактически документировать интерфейс. Когда дело доходит до docblocks для классов, которые реализуют интерфейс, единственная информация, которую я бы включил, – это тег @internal для записи информации о конкретном разработчике, которая не должна появляться в документах API интерфейса. Я ожидаю, что моя IDE узнает, что метод реализации класса должен вытащить свои документы из docblock интерфейса.
Использование {@inheritdoc} в дикой природе несовместимо с тем, что он действительно намеревается выполнить, и я думаю, что ошибки в обработке phpDocumentor 1.x этого тега с течением времени заставляли людей попробовать разные способы их использования, а затем привели к созданию IDE рассматривая его по-разному. В результате, это уже не практика, которую я использую вообще.
Часть ответа здесь .
/** * @implements CacheInterface */ class Cache implements CacheInterface