Назначение социального графика

Question

У меня есть задание Social Graph, и у меня есть довольно хорошее представление о том, что я хочу сделать, я просто хочу знать, нахожусь ли я на правильном пути, и любые советы, которые вы, ребята, можете дать.

В любом случае, довольно простая реализация (я нашел здесь очень сложную - Как моделировать социальный граф на Java , но я думаю, что это гораздо больше, чем мне действительно нужно). По сути, моя идея состоит в том, чтобы создать объект «Пользователь» и хэш-карту для хранения всего. Объект пользователя будет иметь 4 структуры данных: имя (строка), учащийся (логическое значение), школа (строка) и друзья (целочисленный массив ).

Каждый пользователь будет добавлен в хэш-карту и получит уникальный ключ. Когда нужно установить дружбу, скажем, между A и B, я перехожу к пользователю A в хэш-карте и добавляю ключ для пользователя B в массив друзей A, и наоборот. Таким образом, я могу отслеживать всех и с кем они дружат.

Имеет ли это смысл? Это работает у меня в голове, но я чувствую, что мне не хватает чего-то в реализации, что сделает это не так хорошо, как я думаю.

Answer 1

Ответ на этот вопрос будет зависеть от требований и того, что вы хотите сделать со своим социальным графом (особенно от того, хотите ли вы сохранить данные или нет).

Если вы используете hashmap в качестве хранилища пользователей, то я предполагаю, что у вас есть отдельный класс, который генерирует ваши идентификаторы (или у вас есть класс UserStore, который упаковывает hashmap и генерирует их)? Если вы не удаляете пользователей, вам может быть достаточно иметь ArrayList при хранении с индексом, являющимся ключом пользователя.

Когда речь заходит о самих пользователях, вы можете хранить их друзей в списке, но это может немного усложнить удаление кода пользователя (при условии, что у вас есть такая функциональность).

UPDATE:

Если вы хотите провести анализ, вы можете получить некоторую выгоду от хранения друзей пользователя в виде набора <"UserKey">, а не в виде массива (но зависит от того, как вы планируете проводить анализ). Вам все еще потребуется класс счетчика (или мастер-класс UserStore, который назначает идентификаторы).

Answer 2

Ну, это может сработать.

Единственное, чего вам точно не хватает, так это того, что добавление User к HashMap не "дает" ему ключ.Ключ должен быть создан вами как-то.Вы можете выбрать имя пользователя, фамилию или создать дополнительный идентификатор.Вы добавляете User к HashMap, давая ему этот ключ, а User в качестве значения.Вам придется использовать этот ключ каждый раз, когда вы хотите извлечь User из HashMap.

В вашем случае, если имя и фамилия являются уникальными, используйте firstName + " " + lastName в качестве ключа.

Существует множество других рекомендаций, которые во многом зависят от ожидаемого использования модели.Так что я не вижу причин, чтобы разобраться во всем этом.

Answer 3

Я бы добавил некоторую форму «первичного ключа» к объекту User, число, которое могло бы быть синтетическим (взятие следующего числа из глобального целочисленного счетчика).Таким образом, вы можете избежать ситуации генерации значения hashCode () из данных другого пользователя, а затем избежать конфликтов внутри карты.