Варианты дизайна: одноранговое приложение - PullRequest
0 голосов
/ 15 января 2012

Я собираюсь разработать одноранговое приложение для обмена файлами на Java для школьного проекта и обдумывал его дизайн. Я застрял с двумя альтернативами:

1)

Класс Peer, в котором хранится вся информация о состоянии, например, его идентификатор, предпочтительные соседи, количество элементов и т. Д.

и

Класс PeerManager, который действует как интерфейс для класса Peer. Он будет содержать ссылку на объект Peer, а затем методы, работающие над ним. Некоторыми из методов являются updatePreferredNeighbours, подключение или отключение к другому узлу, generateLogs и т. Д.

Но когда я думаю об этом с точки зрения ОО-дизайна, я чувствую, что объект Peer должен отвечать за его поведение. Это подводит меня ко второму варианту:

2)

Интерфейс Peer, содержащий все методы, такие как подключение к другим партнерам, обновление соседей и т. Д. (Которые ранее были в peerManager)

и реализация этого интерфейса, например, PeerImpl, которая содержит всю информацию о состоянии, а также реализует все методы в интерфейсе.

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


Есть ли другой способ решения этой проблемы, какие-либо предложения? Или какой из двух я должен выбрать?

PS: я не могу привести все требования проекта здесь, поскольку это сделает пост слишком большим, но то, что я описал, является более или менее сущностью проекта.

1 Ответ

0 голосов
/ 15 января 2012

Не зная деталей вашей проблемы, сложно быть конкретным. Однако, если вы посмотрите на класс Peer с точки зрения моделирования данных, кажется, что есть (как минимум) две категории данных: вещи, такие как ID, которые являются свойствами объекта Peer, и вещи, подобные предпочтительным соседям, которые являются реляционными свойствами между пирами. , Я бы подумал о том, чтобы разделить их на отдельные классы объектов.

Относительно проблемы сложности второго подхода: не будет ли такой же проблемы в отношении класса PeerManager первого подхода? Мне кажется, что это проблема в любом случае, и она не имеет значения в пользу того или другого подхода.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...