Один класс за проверку токена, другой за аутентификацию пользователя, третий за получение ролей пользователя.
Зачем СТОЛЬКО-ТО?! Класс на блокировку/разблокировку юзера - тоже есть?!)
У Вас связанные зависимости через оператор AND.
Отношение токена к юзеру: 1-к-1. Нет токена или юзера - нет мультиков!
Вы не можете двигаться дальше по бизнес-логике без получения всех параметров из базы (user exist = true, user token = true, roles=[.....]).
Т.е. это "if-then"-конструкция: "Если всё есть - дай мне роли юзера".
Это один класс - "юзер" с методом "получения ролей".
Метод уже сам всё проверяет: лезть в базу, не лезть, юзер авторизован или нет, и т.д. и возвращает или список методов, или иной результат (например, ошибку), или сам осуществляет все необходимые действия для получения запрошенных методов по токену.
Советую - с блок-схем начать понимание логики и не плодить лишних объектных зависимостей в виде классов: это жрёт и память и проц...
Sadus, ну и что тут сложного? просто "плоский" список критериев.
Только вот по баллам - странно.
Должно быть 1.0/11=0.0909... - на каждом критерии. А общий балл: 1.0 (т.е. 100%)
И уже в этих рамках - можно менять веса при необходимости у пунктов критериев или добавлять новые, распределяя эти 100% по всем равномерно или не равномерно.
Как я понял коэффициенты критериев привязаны к экспертам 1-го и 2-го уровня. И у каждого уровня - они разные. (Или даже у конкретного человека?!)
Нужно составить взаимосвязи между 3-мя параметрами:
1. перечень критериев
2. уровень эксперта (или конкретный человек-эксперт)
3. коэффициенты по списку критериев (п.1) по каждому уровню(человеку) (п.2)
Т.е. создание связи у нас в обратном порядке: п.2 или 3., затем оставшийся (п.2 или п.3), и только в конце - п.1: здесь мы связываем все записи в одну законченную логическую цепочку.
Dorothy, Большой кадр: Выкл => Включить.
Приоритет & VLAN: Приоритет & VLAN вкл => Выключить
Управление потоком: Вкл => Выключить
Энергосберегающий Ethernet: Вкл => Выключить