@KEKSOV
1. Да, просмотрел. В любом случае это был пример и я уже немного сомневаюсь что в контексте задачи стоит вообще такие штуки делать.
2. Да, меньше трех проверок там сделать не выйдет, как ни крути. Можно конечно извратиться но пострадает читаемость кода.
3. да, но зато устраняется дублирование кода, условия становятся чище и лаконичнее, что и было конечной целью.
4. Я тоже об этом, мотивировать вынос результатов условий в переменные следовало не с позиции оптимизации производительности а с точки зрения уменьшения дублирования кода.
Реализация @Rsa97 отличается от моей только заменой блоков if на тернарный оператор. Я посчитал такой вариант чуть менее читабельным и решил оставить блоки.
к слову за счет лишних операций ветвлений даже JS код работает чуточку медленнее. Если уж касаться вопросов производительности - развертка циклов дает намного более существенный прирост производительности при вычислениях. Даже в JS (благо JIT умеет хорошо это разруливать).
@AndreySolo а какова вообще исходная задача? Мне просто кажется что вы изначально придумали себе проблему на пустом месте.
Обновил ответ, предложил решение которое покрывает большинство возникающих задачь. Основная суть - управлять всем должен контроллер, но никак не шаблон. Из представления вы можете только сообщить контроллеру что состояние изменилось и попросить контроллер как-то среагировать на это.
Стоит проверить этот вариант на android-планшетах. Точно знаю что mousemove не эмулируется в iOS (как минимум до 6-ой версии включительно). Но за другие системы сложно отвечать.
Вам нужен класс RankDetector в таком случае. Старайтесь выделять компоненты по их функциям а не придумывать абстрактных коней в вакууме. Он же будет единым интерфейсом, а что будет происходить внутри - не столь важно. По сути интерфейс этого класса должен иметь один метод - getRank(User $user), который будет либо возвращать нужную сущность либо алиас ранка либо что там вам нужно по бизнес логике.
Реализовать внутри него можно уже при помощи отдельных драйверов-детекторов, каждый под вой ранг. Тогда и тестами покрывать удобно, и архитектура упрощается для понимания.
Как минимум да, хотя делать для рангов отдельный класс... хотя я не вкурсе особенностей логики вашего приложения. Мне кажется вы излишне усложняете и утяжеляете логику.
@nepster09 просто не просто предлагать решение, когда в исходных данных каша. У вас в коде мягко скажем треш. И почему у вас нету автозагрузчика? Почему такие кастыли?... Вот честно, лет 7 назад я не особо удивился бы такому коду, но сейчас подобное повергает меня в уныние... Хоть запускается это нечто через гермен а не по крону, уже радует.
@Csklassami а чем плохо 40 fps? Вообще у вас забавная логика таймера... Я так понимаю что у вас все это добро запущено в бесконечном цикле... если так, то попробуйте выставить приоритет процессу повыше.
лапшакод, процедурное программирование и т.д. очень сильно бьет по производительности труда. Имхо в 99% случаев дешевле докупить еще сервак чем третить деньги на рефакторинг.
Не пишите подобную чушь, ради бога, а то тут публика впечатлительная и будет воспринимать ваш совет слишком близко к сердцу ни разу не задумываясь.
@PiloTeZ, просто старайтесь делать как можно более слабосвязанные системы, завязывайтесь только на интерфейсах, старайтесь избегать статических методов а если этого не избежать - инкапсулируйте в сервисы и прячьте их за интерфейсы. Ну и да - тесты. Обызательно писать тесты если вы хотите масштабировать систему и делать ее рефакторинг. С первого раза у вас в любом случае не выйдет написать все правильно, да и ни у кого, затем и придумали рефакторинг.
@PiloTeZ Ух... Yii это не тот фреймворк на котором надо тренироваться писать гибкий и расширяемый код. В контексте Yii я бы порекомендовал вам посмотреть в сторону DTO (Data Transfer Objects), хотя это в большинстве случаев избыточно, зато позволяет полностью отвязать ваши сущности от ActiveRecord, что может пригодиться при возникновении необходимости использовать другие хранилища.
DI - Dependency Injection. В Yii2 вроде что-то смутно напоминающее DI контейнер уже ввели. Вообще почитайте в сети информацию по принципу инверсии зависимостей.
