«Плоская лучше, чем вложенная» - для данных и кода?

Question

Этот вопрос заставил меня задуматься: должны ли мы применять принцип, согласно которому «плоские данные лучше вложенных» как для данных, так и для кода? Даже когда есть «логическая древовидная структура» для данных?

В этом случае, я полагаю, это будет означать представление детей в виде списка идентификаторов, а не фактического списка детей со всеми узлами в одном списке:

[ {'id': 4, 'children': ()},
  {'id': 2, 'children': (1, 7)},
  {'id': 1, 'children': (6, 5)},
  {'id': 6, 'children': ()},
  {'id': 5, 'children': ()},
  {'id': 7, 'children': (3,)},
  {'id': 3, 'children': ()} ]

(Я использовал кортежи, потому что я предпочитаю не давать себе гибкости при мутировании объекта, пока эта гибкость не окажется полезной и понятной для использования. В любом случае, я бы никогда не использовал None здесь вместо пустого последовательность, потому что это усложняет логику, и «особые случаи не достаточно особенные» - здесь, это вовсе не особенное.)

Конечно, это короче, но древовидная структура скрыта. Означает ли это, что «явное лучше, чем неявное»?

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

Что скажете вы?

Answer 1

Это совершенно субъективный вопрос.Ответ: «Это зависит».

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

"Плоское" представление - это одна из основ модели реляционной базы данных: каждый тип данныхсуществует в таблице только для этого типа, и любые связи между элементами содержатся в отдельных таблицах.Это полезная абстракция, но порой сложно работать в коде.С другой стороны, обработка всех данных определенного типа тривиальна.

Рассмотрим, например, хочу ли я найти всех потомков записи с идентификатором 2 в данных вашего примера.Если данные уже находятся в иерархии (т. Е. Нативное представление является «вложенной» структурой), то легко найти идентификатор записи 2, а затем пройти по ее дочерним, дочерним дочерним элементам и т. Д.

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

Итак, как я уже сказал,«это зависит».

Answer 2

Должны ли мы применять принцип, что "плоские лучше, чем вложенные" к данным, а также к коду?

номер

Даже когда существует «логическая древовидная структура» для данных?

То, что «квартира лучше вложенной», не относится к данным. Только для кода.

... древовидная структура скрыта. Означает ли это, что «явное лучше, чем неявное»?

Это даже не сравнимо. «Плоское дерево» является распространенной реализацией SQL, потому что SQL не может обрабатывать неопределенную рекурсию правильного дерева.

Сравнение Zen of Python (языка) с дизайном структуры данных бессмысленно. Эти два не более сопоставимы, чем число «2» и разбивают кирпич сыра на «2» кусочка. Одна вещь, другая - действие.

Структуры данных - это вещи.

Python описывает действия.

Answer 3

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

Если структура важна, вложение упрощает жизнь. Если вы регулярно работаете над каждым узлом, плоская структура упрощает использование for node in tree. Конечно, если вы определяете свой собственный класс, его достаточно просто абстрагировать, поэтому оба варианта просты; но это может быть сложнее использовать с внешними системами, такими как преобразование в JSON.

Answer 4

«Все должно быть сделано как можно проще, но не проще».Квартира проще, чем вложенная.Если вы имеете дело с вложением данных , то его выравнивание, вероятно, нарушает «но не простую» часть.Вместо этого я взял Zen of Python, чтобы поощрять вас не усложнять свою жизнь вложением, в котором вы на самом деле не нуждаетесь, например XML-файл конфигурации, где может быть достаточно более простого плоского формата.

Answer 5

На этот вопрос нельзя ответить "в общем" - правильного ответа нет.

В этом конкретном примере мне на самом деле нравится древовидная структура. Ничего не зная об исходном приложении и просто глядя на структуру, связь между элементами очевидна. С плоской структурой я должен прочитать некоторую документацию или код приложения, чтобы «знать», что ваш кортеж детей ссылается на идентификаторы.

Древовидная структура является самодокументированной, плоская структура - нет.

Answer 6

Это противоречит "явному лучше чем неявный "?

Да, особенно, когда явные слова не позволяют вам неявно выстрелить себе в ногу. У «дерева» в вашем примере может быть несколько родителей, утверждающих, что они являются одними и теми же детьми. Он также может иметь несколько корневых узлов (и он имеет: 2 - корневой узел; 4 - корневой, а также конечный узел.)