содержимым - удалить html теги php




Разве черты не просто состав? (3)

Я читал статью о новых возможностях в PHP 5.4.0. Одна из самых ожидаемых Traits .

Читая об этих чертах , чтобы увидеть, в чем они заключаются, они просто выглядят как копия-вставка с помощью компилятора для меня; и язык, предоставляющий способ использования композиции, очень похожий на тот, который используется в хорошо известном паттерне стратегии, который использует принцип дизайна «композиция благосклонности над наследованием».

Я правильно понимаю?

Какие еще преимущества могут дать эти черты, которые делают их полезными вместо того, чтобы просто использовать принцип составления композиции?


«Композиция» черт (это просто включение на уровне методов классов) происходит во время компиляции, тогда как композиция, о которой вы говорите, находится во время выполнения.

Когда вы делаете эту композицию, черта уже была там.

Поскольку единственное наследование в PHP, а также часто встречающиеся статические служебные классы препятствуют достижению некоторых целей проектирования, черты предлагают другой аспект для формирования вашей реализации и позволяют уменьшить дублирование кода.


Вы должны быть осторожны с тем значением, которое вы придаете композиции. В более общем смысле черты являются механизмом как разложения, так и состава.

  • Разложение - как мы разлагаем программную базу на подходящие единицы повторного использования (повторное использование кода, DRY).
  • Композиция - как мы составляем эти блоки для получения иерархии классов, подходящей для нашей прикладной области.

Черты являются механизмом для композиции в том смысле, что они могут быть составлены с классом. Многие реализации признаков также позволяют составлять признаки друг с другом.

Мантра GoF - «композиция благосклонности перед наследованием».

Все языки на основе классов по умолчанию предпочитают наследование. Объект может приобретать поведение только у своего класса или у классов более высокого уровня в своей цепочке наследования. Конечно, вы можете достичь одного и того же результата по-разному. Например, вы можете создать класс диспетчера (например, LayoutMananager), а затем добавить ссылку на него в любом классе, обладающем чертой поведения / макета, и добавить функцию, которая не вызывает ничего, кроме вызова методов диспетчера.

public function doSomething() { return layoutManager.doSomething(); }

Черты благоприятствуют композиции. Просто как тот. Ключевой характеристикой черт является то, что они живут вне иерархии классов. Вы можете «приобретать» многократно используемые модели поведения или черты, не используя их ни в одном из ваших суперклассов (различие по горизонтали и вертикали, представленное в других публикациях). Это главное преимущество.

Самая большая проблема с признаками - возникновение конфликта, когда признаки реализованы таким образом, что вы можете напрямую выполнить myObject.doSomething () вместо myObject.trait1.doSometing () (прямо или косвенно, как описано выше с layoutManager). Как только вы добавите более одной черты в класс, конфликты могут легко возникнуть. Ваша реализация должна поддерживать такие механизмы, как псевдонимы и переопределения, чтобы помочь в разрешении конфликтов. Вы получаете некоторые накладные расходы обратно.

Не ясно, что реализация PHP соответствует этому, но предполагается, что черты не должны указывать какие-либо переменные экземпляра, и методы, предоставляемые чертами, никогда не должны напрямую обращаться к переменным экземпляра. (источник: Добавление признаков к (статически типизированным) языкам , PDF). Этот блог обсуждает это. Он утверждает, что в PHP структура с именем trait действительно является смесью (то есть признаками с состоянием). (Хотя этот другой пост в блоге описывает их как лиц без гражданства )

В целом, мышление в терминах черт может помочь в написании лучшего кода. Написание классов черт, чтобы избежать инстанцирования, также может способствовать улучшению кода. Это освобождает черты от любой зависимости, позволяя вызывать их в любом порядке. Но не ясно, что добавление понятия черты в сам язык будет способствовать улучшению кода.


черты являются синонимом поведения больше, чем наследование или украшение. Это не то же самое, что шаблон стратегии, потому что вы можете определить общий алгоритм, в то время как каждый конкретный объект стратегии имеет свой алгоритм. Более того, это скорее «горизонтальное» наследование поведения, чем «вертикальное» наследование со спецификацией поведения.

Вопрос действительно интересный.





traits