В настоящее время я самостоятельно изучаю ООП с помощью книг и веб-сайтов. Мне нужно попрактиковаться. Я начал небольшой проект, который умею выполнять процедурно. Но когда я пытаюсь сделать это в стиле ООП, у меня возникают вопросы.
Моя концепция проекта такая. Я хочу организовать / заархивировать / управлять взаимодействием в нашей системе на работе. Использую 2 класса. Устройство и интерфейс.
У устройства есть несколько интерфейсов.
Класс устройства имеет следующие методы:
- void addInterface (имя строки)
- void removeInterface (Интерфейс i)
- Интерфейс getInterface (Интерфейс i) # Я должен был написать: Интерфейс getInterface (String interfaceName)
- void printAllInterface ()
Интерфейсный класс имеет следующие методы:
- void connectInterface (Интерфейс interfaceToConnectTo)
- void disconnectInterface (Интерфейс interfaceToDisconnectFrom)
- void printAllConnection ()
По сути, я создаю два устройства, добавляю к каждому несколько интерфейсов и, наконец, устанавливаю связь между интерфейсами.
Устройство знает все свои интерфейсы. Интерфейс знает все остальные интерфейсы, к которым он подключен.
Но, учитывая интерфейс, как мне узнать, какому устройству он принадлежит?
Если интерфейс знает об устройстве, они становятся тесно связанными. Для того, что я узнал до сих пор, это не совсем хороший объектно-ориентированный подход. Другой способ - просмотреть все устройства, чтобы узнать, есть ли у них тот интерфейс, который я ищу. Это кажется действительно неэффективным. Я уверен, что упустил что-то очевидное. Кто-нибудь может это увидеть?
Благодарность
Обновление: это можно увидеть как фигуры и соединения в файле MS Visio. интерфейс на самом деле просто соединитель формы. Устройство - это форма.
2 ответа
Если у вас есть требование, чтобы вы могли определить Device для данного Interface, это означает, что Device и Interface уже тесно связаны, даже если вы не t закодировал это. Если вы разделите два класса, вы больше не сможете предполагать, что все Interfaces принадлежат Device.
Если это , что все объекты Interface должны принадлежать Device, то я не вижу никаких проблем с setDevice / getDevice методы на Interface. Да, это создает круговую зависимость, но похоже, что это лучший способ смоделировать вашу конкретную область. Перебирать каждый Device только для того, чтобы увидеть, содержит ли он конкретный Interface, на мой взгляд, гораздо худшее дизайнерское решение.
Однако, если желательно, чтобы Interface существовал без принадлежности к Device или, возможно, принадлежал к совершенно другому классу, тогда вам необходимо переосмыслить архитектуру на более высоком уровне. Что-то вроде: Как я могу реструктурировать эти классы, чтобы мне не нужно было получать Device от Interface? Ответ действительно зависит от вашего конкретного домена, о котором мы не очень много знаем только из информации в вашем вопросе.
Небольшой комментарий к вашим существующим интерфейсам. IMHO метод печати на интерфейсах должен быть перемещен в другой интерфейс, чтобы интерфейс устройства имел единственную ответственность только за поддержание интерфейсов, которые он контролирует. Кроме того, что метод «Интерфейс getInterface (Интерфейс pInterface)» получает как входной аргумент и возвращает? Что касается ответа, есть несколько вопросов, которые поднимает ответ выше. Если я правильно понимаю, класс устройства создает интерфейс при вызове addInterface (); Если вариант использования таков, что при заданном интерфейсе устройство должно быть возвращено, getDevice () в интерфейсе в порядке (я бы не стал добавлять метод setDevice (); устройство может быть передано в конструктор интерфейса), если интерфейс всегда принадлежит устройству. Изменить: метод setDevice (), однако, был бы предпочтительнее, если вы хотите создать у пользователя вашего API впечатление, что ваш вариант использования требует, чтобы устройство, связанное с интерфейсом, могло изменяться во время выполнения.
Похожие вопросы
Новые вопросы
oop
Объектно-ориентированное программирование - это парадигма программирования, использующая «объекты»: структуры данных, состоящие из полей данных и методов вместе с их взаимодействиями.
En Español