Использование черт, чтобы покрыть требования реализации интерфейсов
Недавно я наткнулся на несколько статей, в которых подразумевается использование черт для освещения реализации интерфейсов.
Пример:
interface ArticleInterface
{
/**
* @return mixed
*/
public function getTitle();
}
trait ArticleTrait
{
/**
* @return string
*/
public function getTitle()
{
return "article_title";
}
}
abstract class AbstractArticle implements ArticleInterface
{
use ArticleTrait;
}
Немного даже думаю, что Traits, реализующие интерфейсы, должны быть доступны в ядре PHP.
Поэтому я пытаюсь получить правильный ответ на вопрос, следует ли следовать этому шаблону проектирования?
Если да, следует ли писать описание PHPDoc как на интерфейсе, так и на черте (то есть дублировать его)?
Любые другие детали, на которые я должен обратить внимание при использовании этого дизайна?
Решение
Черты обеспечивают для копирования и вставки с помощью компилятора. Они являются формой повторного использования кода. В то время как наследование классов дает вам код для повторного использования по вертикали (дочерние классы совместно используют код, определенный в их родителях), черты дают вам код для повторного использования по горизонтали: классы совместного использования интерфейса могут использовать код, определенный в характеристике.
Так что да, если у вас есть множественный братья и сестры, имеющие общий интерфейс а также реализации, то вы можете использовать черты, чтобы уменьшить дублирование кода. Но нет, если у вас есть только один класс, реализующий интерфейс — как в вашем примере — тогда черты добавляют незаслуженную сложность.
Я хотел бы добавить один важный момент: черты сами по себе не сохраняют состояние. Любая переменная-член в признаке будет в конечном счете сохранена в объекте, потребляющем признак. Если у вас есть некоторая информация о состоянии, которую следует считать «частной» для признака (и, следовательно, недоступной для объекта), не используйте признаки для повторного использования. Вместо этого используйте сервисные делегаты.
Другие решения
Других решений пока нет …