Нужна помощь в определении обязанностей классов - PullRequest
0 голосов
/ 26 августа 2011

В настоящее время я изучаю ООП самостоятельно с книгами и веб-сайтами.Я нахожусь в точке, я должен практиковать.Я начал небольшой проект, который я знаю, как это сделать процедурно.Но у меня возникают вопросы, когда я пытаюсь сделать это ООП-методом.

Моя концепция проекта такая.Я хочу организовать / архивировать / управлять взаимосвязью в нашей системе на работе.Я использую 2 класса.Устройство и интерфейс.

Устройство имеет несколько интерфейсов.
Класс устройства имеет следующие методы:

  • void addInterface (String name)
  • void removeInterface (Interface i)
  • Интерфейс getInterface (Interface i) # Я должен был написать: Интерфейс getInterface (String interfaceName)
  • void printAllInterface ()

Интерфейсный класс имеет следующие методы:

  • void connectInterface (Interface interfaceToConnectTo)
  • void disconnectInterface (Interface interfaceToDisconnectFrom)
  • void printAllConnection ()

По сути, я создаю дваустройство, добавьте несколько интерфейсов для каждого и, наконец, установите некоторое соединение между интерфейсами.

Устройство знает все свои интерфейсы.Интерфейс знает все другие интерфейсы, к которым он подключен.

Но, учитывая интерфейс, как узнать, к какому устройству он относится?

Если Интерфейс знает об устройстве, они становятся тесно связанными.Для того, что я изучаю до сих пор, это не очень хороший ООДругим способом было бы просмотреть все устройства, чтобы узнать, есть ли у них интерфейс, который я ищу.Это кажется действительно неэффективным.Я уверен, что пропустил что-то очевидное.Кто-нибудь может это увидеть?

Спасибо

Обновление: это можно рассматривать как фигуры и соединения в файле MS Visio.интерфейс на самом деле просто разъем на форме.Устройство имеет форму.

Ответы [ 2 ]

1 голос
/ 26 августа 2011

Если у вас есть требование, что вы должны иметь возможность определить Device для данного Interface, это означает, что Device и Interface уже тесно связаны, даже если вы не закодировали его.Если вы разъедините два класса, то вы больше не сможете предполагать, что все Interfaces принадлежат Device.

Если оно равно , то если все Interface объекты должны принадлежатьDevice, тогда я не вижу проблем с использованием setDevice / getDevice методов на Interface.Да, это создает круговую зависимость, но, похоже, это лучший способ для моделирования вашего конкретного домена.Поиск по каждому Device, чтобы увидеть, содержит ли он конкретный Interface, на мой взгляд, является гораздо худшим дизайнерским решением.

Однако, если желательно, чтобы Interface существовал без принадлежности кDevice или, возможно, принадлежащий к совершенно другому классу, тогда вам нужно переосмыслить архитектуру на более высоком уровне.Что-то вроде: Как я могу реструктурировать эти классы, чтобы мне не нужно было получать Device от Interface? Ответ действительно зависит от вашего конкретного домена, который мы не делаемзнаю очень много только из информации в вашем вопросе.

0 голосов
/ 26 августа 2011

Небольшой комментарий о ваших существующих интерфейсах. ИМХО метод печати на интерфейсах должен быть перемещен на другой интерфейс, чтобы интерфейс устройства нес единственную ответственность за поддержание интерфейсов, которыми он управляет. Кроме того, что метод «Интерфейс getInterface (Interface pInterface)» получает в качестве входного аргумента и возвращает? Что касается ответа, есть несколько вопросов, которые поднимает ответ выше. Если я правильно понимаю, класс устройства создает интерфейс при вызове addInterface (); Если вариант использования таков, что при заданном интерфейсе устройство должно быть возвращено, то getDevice () для интерфейса в порядке (я бы не добавил метод setDevice (); устройство можно передать в конструктор интерфейса), если интерфейс всегда принадлежит устройству. Изменить: метод setDevice (), однако, будет предпочтительнее, если вы хотите, чтобы пользователь вашего API впечатление, что ваш сценарий использования требует, чтобы устройство, связанное с интерфейсом, могло измениться во время выполнения.

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