Кто-нибудь объяснит, когда я захочу использовать Groovy Traits против Mixins (@Mixin) против делегатов (@Delegate)? Возможно, некоторые компромиссы и проблемы дизайна помогут.
Все они, похоже, допускают повторное использование нескольких "классов" поведения. Благодарю.: -)
Этот поток SO был полезен также: Разница между преобразованиями @Delegate и @Mixin AST в Groovy
Я согласен, все они, похоже, позволяют повторно использовать несколько "классов" поведения. Однако существуют различия, и понимание этого, вероятно, поможет вашему решению.
Перед тем, как предоставить краткий обзор/выделение каждой функции и примеры подходящих использование, просто подведем итоги каждого из них.
Заключение/типичное использование:
И теперь давайте рассмотрим каждую из них немного подробнее.
@Delegate
Наследование используется во многих случаях. То есть, это часто неправильно используется. Классические примеры в Java:
расширение входных потоков, считывателей или классов коллекции. Для большинства из них использование наследования слишком
тесно связан с реализацией. То есть фактическая реализация написана так, что одна из
общественные методы фактически используют другой. Если вы переопределите оба, и вы вызываете super, тогда вы можете получить нежелательные
побочные эффекты. Если реализация изменится в более поздней версии, вам придется обновить свою обработку
это также.
Вместо этого вы должны стремиться использовать композицию над наследованием.
Пример, список подсчета, который подсчитывает элементы, добавленные в список:
class CountingList<E> {
int counter = 0
@Delegate LinkedList<E> list = new LinkedList<>()
boolean addAll(Collection<? extends E> c) {
counter += c.size()
list.addAll(c)
}
boolean addAll(int index, Collection<? extends E> c) {
counter += c.size()
list.addAll(index, c)
}
// more add methods with counter updates
}
В этом примере @Delegate удаляет весь утомительный код котельной для всех общедоступных методов, которые вы
хотите оставить "as-is", т.е. добавлены методы, которые просто переадресуют вызов в базовый список. К тому же,
CountingList отделен от реализации, так что вам не нужно заботиться о том, является ли один из этих
методы реализуются путем вызова другого. В приведенном выше примере это действительно так, поскольку
LinkedList.add(Collection) вызывает LinkedList.add(int, Collection), так что это не так прямолинейно
для реализации с использованием наследования.
Резюме:
@Delegate в один класс.
CountingList в приведенном выше примере) не являются экземплярами класса делегата.
CountingList не является экземпляром LinkedList.@Mixin
Преобразование @Mixin будет устаревать с помощью groovy 2.3, из-за поддержки предстоящих признаков. Это обеспечивает
что все, что возможно сделать с @Mixin, должно быть возможно сделать с чертами вместо этого.
По моему опыту, @Mixin является своего рода смешанным благословением.:)
Это, по мнению разработчиков основных разработчиков, связано с ошибками "трудно решаемых". Это не значит, что это было "бесполезный", далекий от него. Но если у вас есть возможность использовать (или ждать) groovy 2.3, то вы должны использовать вместо этого.
Что делает трансформация AST, просто добавить методы из одного класса в другой. Например:
class First {
String hello(String name) { "Hello $name!" }
}
@Mixin(First)
class Second {
// more methods
}
assert new Second().hello('Vahid') == 'Hello Vahid!'
Резюме:
Second не является экземпляром FirstМикширование времени выполнения
Микширование времени выполнения и преобразование @Mixin совершенно разные, они решают разные прецеденты и используются
в совершенно разных ситуациях. Поскольку у них одно и то же имя, легко смутить одно с другим или
думайте, что они одно и то же. Однако смешения в среде исполнения не устарели в groovy 2.3.
Я склонен думать о runtime mixins как способе добавления методов к существующим классам, таким как любой класс в JDK. Это механизм, используемый groovy для добавления дополнительных методов в JDK.
Пример:
class MyStringExtension {
public static String hello(String self) {
return "Hello $self!"
}
}
String.mixin(MyStringExtension)
assert "Vahid".hello() == 'Hello Vahid!'
Groovy также имеет приятный модуль расширения, где вам не нужно вручную выполнять микширование, вместо этого groovy делает это для вас до тех пор, пока находит дескриптор модуля в правильном месте в пути к классам.
Резюме:
Черты характера
Черты новы для groovy 2.3.
Я стараюсь рассматривать эти черты как нечто среднее между знакомым интерфейсом и классом. Что-то похожее на "легкий вес", класс. В документации они дублируются "интерфейсы с реализацией и состоянием по умолчанию".
Черты похожи на преобразование @Mixin, которое они заменяют, но они также более мощные. Во-первых, они
гораздо более четко определены. Невозможно создать экземпляр напрямую, как интерфейс, им нужна реализация
класс. И класс может реализовать многие черты.
Простой пример:
trait Name {
abstract String name()
String myNameIs() { "My name is ${name()}!" }
}
trait Age {
int age() { 42 }
}
class Person implements Name, Age {
String name() { 'Vahid' }
}
def p = new Person()
assert p.myNameIs() == 'My name is Vahid!'
assert p.age() == 42
assert p instanceof Name
assert p instanceof Age
Непосредственная разница между признаками и @Mixin заключается в том, что trait является ключевым словом языка, а не преобразованием AST.
Кроме того, он может содержать абстрактные методы, которые должны выполняться классом. Кроме того, класс может реализовать
несколько черт. Класс, реализующий признак, является экземпляром этого признака.
Резюме: