Являются ли черты не просто составом?

Ответ 1

Нет, черты не просто композиции из-за того, что правила, по которым свойства "вставляются" в класс, совершенно разные.

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

С другой стороны, черты становятся частью API самого экземпляра, в котором они используются. Они не являются подсистемами в экземпляре. Они даже не экземпляры, а только многоразовый шаблонный код. Одно из преимуществ, которое это обеспечивает, - это удовлетворительные интерфейсы с признаком, как я показал в Черты в PHP - любые примеры/лучшие примеры в реальном мире?

Ответ 2

Характеристики "состав" (это просто включение на уровне метода классов) происходит во время компиляции, тогда как состав, о котором вы говорите, находится во время выполнения.

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

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

Ответ 3

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

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

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

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

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

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

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

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

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

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

Ответ 4

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

Вопрос интересен.