Добрый день. Делаю сетевые шахматы. Испытываю проблемы в планировании архитектуры. Начал с модуля по авторизации, сделал классы
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.
Большинство людей не понимает, что великое многообразие и красочность мира будут служить им крепчайшей душевной поддержкой на протяжении всей жизни. Иван Ефремов