Шаблон для работы с типами с различными интерфейсами в коллекции - PullRequest
Новая
       7

Шаблон для работы с типами с различными интерфейсами в коллекции

0 голосов
/ 27 марта 2020

Начну с того, чего я хочу достичь. У нас есть граф БД, в котором хранятся разные типы узлов. Каждый тип узлов имеет определенный набор свойств. Каждое свойство является строкой в ​​БД, но может быть кодировкой более сложной структуры данных. Например, скажем, у нас есть: 

PersonNode {
  name,
  age,
}

DogNode {
  breed,
  favorite_foods, // JSON-encoded list of strings
}

В нашем клиентском коде у нас есть низкоуровневый класс Node, который представляет свойства узла в виде карты ключ-значение. Мы хотим опираться на этот низкоуровневый Node, чтобы предоставить конечным пользователям интерфейс с безопасным типом, чтобы им не приходилось самим проверять наличие ключей / декодировать их.

Сотрудник предложил нам Можно создать разные классы для каждого типа узлов с разными получателями для свойств. Например (в псевдокоде): 

class PersonNode {
  string get_name() { ... }

  int get_age() { ... }
}

class DogNode {
  string get_breed() { ... }

  list<string> get_favorite_foods() { ... }
}

Но меня беспокоит этот подход: если мы хотим вернуть разные типы узлов из БД, нам нужно сохранить их в коллекции, а это значит, что нам нужно чтобы различные типы узлов наследовали от BaseNode. Но тогда пользователю необходимо будет выполнить проверки типов во время выполнения для каждого узла, прежде чем они смогут использовать свои методы получения. Я чувствую, что это противоречит цели полиморфизма: 

list<BaseNode> nodes = get_nodes_from_db()

for node in nodes:
  if instanceof(node, PersonNode):
    ...
  elif instanceof(node, DogNode):
    ...

Существует ли какой-либо шаблон, который мы можем использовать, который позволяет избежать проверок типов во время выполнения, но также может обеспечить нам безопасность типов при доступе к свойствам каждого типа узла?

1 Ответ

1 голос
/ 28 марта 2020

Рассматриваемые узлы кажутся структурами данных , а не объектами. Если они не инкапсулируют какие-либо логики c, узлы не являются объектами в смысле ОО, и полиморфизм не имеет значения. Объектно-ориентированный полиморфизм связан с представлением нескольких поведений , а не нескольких состояний данных.

При этом, если вы программируете на языке ОО, вы, скорее всего, примете решение, аналогичное проверка типов, которая была бы анафемой, если бы это были фактически объекты. Если вы программируете на языке FP, для этого решения есть более интересный термин: сопоставление с шаблоном .

...