Способ моделирования домена сильно зависит от того, какие данные потребуются и как вы собираетесь с ним работать. Читая ваш вопрос, я пришел к следующим выводам, не стесняйтесь комментировать, если я не прав. - У вас будет набор алгоритмов, которые принимают входные параметры: Пересечение и Отверстие соответственно. - Пересечения и Отверстия бывают нескольких разных видов, некоторые из которых в настоящее время неизвестны.
Первое, что необходимо принять во внимание, - это то, что информация, необходимая для представления Каждый вид отверстия будет отличаться. Например, круглое отверстие и L-образное отверстие не будут иметь одинаковую информацию, первое имеет центр и радиус, а второе - нет. Это происходит аналогичным образом для объектов Crossing. Поэтому мы должны спросить себя, каково было бы лучшее представление, которое могло бы учитывать эти различия.
Если бы мы смоделировали это в модели OOP, то мог бы прийти на ум подход, основанный на Baseclass + Inheritance. Тем не менее, есть два предостережения, во-первых, как указывает @Lini Crossings / Holes, не демонстрируют поведение, это простые данные. Во-вторых, у Baseclass не будет общих атрибутов с подклассами, поскольку каждый вид Crossing / Hole будет представлен различными атрибутами, и то же самое происходит с методами доступа, поэтому у нас будет пустой BaseClass, целью которого является: знать, является ли объект подтипом пересечения или подтипом отверстия. В зависимости от языка, над которым вы работаете, этот подход может быть обязательным, и IMO я тоже не считаю плохим подходом.
Если вместо этого вы используете функциональный язык, такой как Clojure, вы можете смоделировать Crossings и Отверстия в виде словарей с двумя полями для представления Типа и Подтипа, которые позволяют использовать стандартные функции для доступа к данным и их изменения. В конце концов, добавление новых подтипов будет простым в обоих сценариях ios.
Во-вторых, количество возможных пар может стать очень большим, поэтому вам нужен способ упорядочить алгоритмы и решить, при каждом сопряжении, который следует вызывать так, чтобы можно было легко обрабатывать новые подтипы. Лично мне не нравится делать алгоритм обнаружения Классом, потому что это вещь обработки данных, а не сами данные (я немного пурист здесь :). Мой подход к этому был бы мультиметоды , которые являются динамическими c диспетчерскими функциями. Общая идея такова:
- Создайте все необходимые алгоритмы для обработки каждой пары. Если один алгоритм может обрабатывать несколько пересечений или отверстий, вы также можете сделать это.
Alg1 :: (CrossA HoleA) --> Result
Alg2 :: (CrossA HoleB) --> Result
Alg3 :: (CrossB (Either HoleB HoleC)) --> Result
- Создайте функцию сопряжения, чтобы создать процесс сопряжения, который будет возвращать ключевое слово, используемое для определения алгоритма обнаружения. позвонить.
Pairing :: (Crossing Hole) --> Keyword
- Создать мультиметод. Он примет любую пару Crossing и Hole, затем вызовет Pairing и, наконец, отправит соответствующий алгоритм на основе результата спаривания.
Detection :: (AnyCross AnyHole) --> result
При таком подходе каждый алгоритм изолирован и добавление новых просто требуется добавить новое соответствие в функции сопряжения и обнаружения. Кроме того, добавление типов и алгоритмов не нарушит существующий код из-за разделения проблем. Единственный недостаток, который я могу вспомнить, это то, что, возможно, этот шаблон проектирования немного сложнее реализовать на языке OOP, чем на функциональном, но, конечно, в языках обеих сторон будут нюансы.
Надеюсь, этот TL; DR поможет вам немного рассмотреть имеющиеся варианты.