Вопрос проектирования ООП

Question

Я делаю проект по теории графов и реализую некоторые графовые алгоритмы.

Я бы хотел отделить

• код алгоритма (например, BFS, DFS ...),
• код обработки графика (например, сам класс Graph, обработка краев и вершин ... и т. Д.) И
• код, связанный с графическим интерфейсом

У меня есть2 вопроса, связанных с дизайном приложения:

1. Должен ли я использовать отдельный пакет для каждого?Кроме того, все, что кто-либо может добавить о соединении и взаимодействии этих частей, было бы полезно.

2. Какой шаблон проектирования я должен использовать для кода алгоритмов?Должен ли это быть статический класс, синглтон или любое другое предложение?

Answer 1

Нет общего ответа. Решение зависит от того, планируете ли вы повторно использовать систему, которую вы разрабатываете, и каким образом.

Как вы указали, использование хорошо известных дизайнерских шаблонов - хорошая идея. Я не знаю ваших архитектурных целей, но могу порекомендовать следующие общие рекомендации:

Разработка «модели» (структуры данных) в собственном пакете. Этот слой должен включать в себя только «модель» и «состояние» представления вашей системы: график, вершина, ориентация, веса и т. Д. Этот слой, скорее всего, должен также содержать логику обслуживания модели (добавить узел в граф, получить узлы, получить вершина, создание вершин, добавление веса и т. д.) Посмотрите на структурные шаблоны (составные, фасады и т. д.) и посмотрите, можно ли применить какой-либо из них к вашей модели.

Реализация алгоритмов на отдельном слое. Большую часть времени хорошей идеей является сделать эти компоненты «не имеющими состояния» (статические функции, выполняющие операции над моделью). Посмотрите на поведенческие паттерны (посетитель, цепь ответственности, итератор, интерпретатор, команда и т. Д.) И посмотрите, можно ли применить какой-либо из них.

Используйте шаблон проектирования Observer для разработки своего слоя рендеринга (отображения, визуализации). Этот шаблон позволяет отделить наблюдаемое (модель) и вид и, в конечном итоге, предоставить несколько типов видов для одной и той же модели.

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