Добрый день. Делаю сетевые шахматы. Испытываю проблемы в планировании архитектуры. Начал с модуля по авторизации, сделал классы AccountManager - для хранения и проверки на создание аккаунта\логина; класс ConnectionManager - для актуального ведения открытых каналов с аккаунтами.
Несколько вопросов:
В каком виде отсылать сообщения клиенту? Скажем список он-лайн пользователей с их рейтингом, кол-вом побед, поражений, игр - в виде списка объектов User, или же лучше перегонять их в текстовый массив? - Просто в объекте User есть поле password - и в таком случае оно тоже передастся клиенту.
Отсюда вытекает второй вопрос: может сделать так, чтобы класс AccountManager скрывал конфиденциальную инфу от всего остального кода? Но как такое сделать - обнулять поле Password перед "отдачей" его в своих public методах или хранить пароли не в классе User, а в другом классе? Как принято делать?
Третий вопрос, наверно вряд ли получится понятно объяснить. Он звучит - как лучше сделать архитектуру класса\ов управляющих всеми и подключенными пользователями на сервере.
В данный момент у меня так:
_______________________
class AccountManager:
+ createNewUser (String userName, String password)
+ login (String userName, String password) - в случае успеха возвращает объект типа User
_______________________
class ConnetcionManager:
+ ConnetcionManager (IAccountManager accountManager) - конструктор принимает AccountManager
- updateConnection (Channel senderChannel, User user) - связывает канал с пользователем. Если связано, значит он онлайн, private метод.
+ createNewUser (String userName, String password, Channel senderChannel) - обертка для CreateNewUser
+ login (String userName, String password, Channel senderChannel) - обертка для Login. В случае успеха вызывает private метод updateConnection(). Таким образом нет никакого способа из других модулей добавить пользователя "онлайн", кроме как вызвать метод Login у ConnectionManager.
+ access (Channel senderChannel) - когда с какого-то канала приходит сообщение, мы вызываем этот метод. Он ищет канал и находит соответствующего пользователя, либо выкидывает ошибку. Таким образом мы проверяем - проходила ли процедура логина ранее с этого канала.
_______________________
Мне сложно продумать архитектуру... И как потом надо будет расширять функционал. До самих шахмат я так ещё и не дошел. Пока сделал только общий чат.
Так вот, вопрос по архитектуре всего этого:
Не уверен вообще надо было разделять это на два класса... ConnetcionManager просто делает функции обертки для AccountManager. И при добавлении новых public методов (banByIP, banByLogin, updateUser) в AccountManager'е - придётся писать новые обертки и в ConnetcionManager. Как лучше сделать - объединить эти два класса в один, сделать наследованием, сделать внутренние\вложенные классы или как щас - оставить "разбитыми" на два разных класса?
Сейчас конструктор класса ConnetcionManager ожидает реализацию интерфейса IAccountManager - экземпляр класса AccountManager.