Мені відомо, що поведінки можна налаштовувати перевизначаючи метод behaviors, який буде повертати масив з конфігураціями кожного прикріпленого поведінки. Я хочу, щоб крім цього методу, був ще інший, припустимо, behaviors2, формат якого був індентічен, який робив би абсолютно те ж саме - зберігав дані про поведениях.
Завдання таке: збирати інформацію про поведениях з обох методів.
Дослідивши код компонентів, я зрозумів, що за збір інформації з методу behaviors відповідає ensureBehaviors, який в свою чергу запускається мало не на початку кожного іншого методу, який хоч якось пов'язаний з поведінками. Перша думка - перевизначити його:
Де я в ensureBehaviors2 якраз і прикріплений всі інші поведінки.
Труднощі: метод, який відповідає за прикріплення поведінки до компоненту, attachBehaviorInternal є приватним, а метод attachBehavior викликає ensureBehaviors. Разом: рекурсія.
Вихід: додати в клас властивість:
І написати ось так:
І тут я задумався. Начебто працює, але схоже на великий і важкий милицю. Але працює. Хочеться дізнатися вашу думку і можливі рішення цього завдання.
Функціонал методу behaviors повинен залишитися незмінним. Знаю, що можна було б використовувати behaviors2 і behaviors3, а в behaviors просто Мержа результати цих методів. Або в behaviors дописати функціонал, який брав масив, який в ньому, і Мержа з іншими. Але тоді не можна було б використовувати спадкування.
Я пораджу вам відмовитися від ідеї розділити підключаються поведінки на кілька методів. Ось мої аргументи:
Нестандартний механізм. Так, ми повинні програмувати з використанням фреймворку, а не на фреймворку. Але перший аргумент такий що все знають що таке behaviors. Що таке analyticsBehaviors. customBehaviors доведеться всім пояснювати.
Хибна гнучкість. Вам недостатньо в одному місці додати behaviors2. Я припускаю що ви оберіть іншу назву і питання в тому чи всім моделям це буде потрібно. А що якщо деяким знадобиться behaviors3. Код який ви привели не є милицею, може тільки трохи. Він адекватно вирішує завдання поділу, але я не думаю що це буде досить гнучко.
Стандартне рішення цього завдання для мене виглядає цілком нормальним і максимально гнучким.
Не потрібно гадати що де і як. Стандартний behaviors, їх велика кількість можна розкидати як захочеться.
Проблема з успадкуванням вирішується так:
Програміст завжди буде працювати з behaviors. способи формування якого будуть визначатися завданням. Це просто і круто.