Какая разница между данными и кодом?

Чтобы взять пример, рассмотрим набор скидок, доступных покупателю супермаркетов.

Мы могли бы определить эти правила как данные в стандартном порядке (списки квалификационных элементов, применимые даты, коды купонов) и написать общий код для их обработки. Или, мы могли бы написать каждый как кусок кода, который проверяет соответствующие вещи, учитывая список покупок клиентов и возвращает любые применимые скидки.

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

Часто бывает сложно критиковать код, который смешивает данные в операторах if, которые проверяют 6 разных вещей, которые должны быть в файле или базе данных, но есть ли правило, которое помогает в случаях краев?

Или это точка объектно-ориентированного дизайна, чтобы мы не беспокоились о линии между данными и кодом?

Чтобы уточнить, основной вопрос заключается в следующем: как бы вы закодировали приведенный выше пример? Есть ли правило, которое заставило вас решить, что такое данные и что такое код?

(Примечание: я знаю, код может быть скомпилирован, но в мире динамических языков и компиляции JIT, даже это размытое понятие.)

Ответ 1

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

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

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

Это уже сложнее, чем думают многие люди, когда на самом деле это всего лишь несколько строк и чисел, которые настроены (я лично был свидетелем сбоя в работе мейнфрейма производства, потому что он имел одно логическое значение, заданное иначе, чем другая система, о которой он говорил), Когда ваши "данные конфигурации" содержат сложную логику, ее почти невозможно достичь. Но ситуация не будет лучше, потому что вы используете плохо спроектированный ad hoc "язык конфигурации правил" вместо "реального" кода.

Ответ 2

Это довольно философский вопрос (который мне нравится), поэтому я отвечу ему философски: ничего не стоит для его поддержки.;)

Данные являются частью системы, которая может измениться. Код определяет поведение; способ изменения данных в новые данные.

Чтобы сделать это более точным: данные могут быть описаны двумя компонентами: описание того, что должно представлять представление (например, переменная с именем и типом) и значение. Значение переменной может изменяться в соответствии с правилами, определенными в коде. Разумеется, описание не меняется, потому что, если это так, у нас есть целая новая информация. Сам код не изменяется, если не будут изменены требования (что мы ожидаем от системы).

Для компилятора (или виртуальной машины) код фактически является данными, на которых он выполняет свои операции. Тем не менее, скомпилированный код не указывает поведение для компилятора, это делает собственный код компилятора.

Ответ 3

Все зависит от требования. Если данные похожи на данные поиска и часто меняются, вы действительно не хотите делать это в коде, но такие вещи, как "День недели", не должны чередоваться в течение следующих 200 лет или около того, поэтому код, который.

Возможно, вы захотите изменить свою тему, поскольку первое, о чем я думал, когда я это увидел, - это старое обсуждение LISP кода и данных. Lucky in Scheme code и data выглядят одинаково, но об этом, вы никогда не можете случайно смешать код с данными, что очень возможно в LISP с негигиеничными макросами.

Ответ 4

Данные - это информация, которая обрабатывается командами Code. Я не уверен, что я чувствую, что в OOD происходит размытие, все еще есть свойства (данные) и методы (код). Теория OO инкапсулирует как гештальт-сущность, называемую классом, но все еще дискретна в классе.

Насколько гибко вы хотите сделать свой код в выборе. Включение постоянных значений (то, что вы делаете с помощью операторов if, как описано выше) является негибким без повторной обработки вашего источника, тогда как использование динамически полученных данных является более гибким. Является ли подход неправильным? Я бы сказал, что это действительно зависит от обстоятельств. Как сказал Леппи, есть определенные "данные", которые являются инвариантными, как дни недели, которые могут быть жестко закодированы, но даже там может быть выгодно делать это динамически при определенных обстоятельствах.

Ответ 5

В Lisp ваш код - это данные, а ваш данные - это код

В предложениях Prolog указаны термины и термины являются предложениями.

Ответ 6

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

Это просто для безопасности. Если скидка меняется, вам не придется переписывать код скидки, вам нужно будет просто войти в свой репозиторий скидок (DB, или файл приложения, или XML файл, или, как вы решите его реализовать), и сделать небольшое изменение числа.

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

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

Ответ 7

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

В конечном итоге важны вопросы разработки программного обеспечения/разработки, такие как производительность, эффективность и т.д. Например, программы с управлением данными могут быть не такими эффективными, как программы, которые имеют жестко закодированные (и, следовательно, хрупкие) условные операторы. Поэтому я решил определить код как любые данные, которые могут быть эффективно выполнены, а все остальное - это простые данные.

Это компромисс между гибкостью и эффективностью. Исполняемые данные (например, правила XML) предлагают большую гибкость (иногда), тогда как одни и те же данные/правила, когда закодированные как часть приложения будут работать более эффективно, но их изменение часто становится громоздким. Другими словами, исполняемые данные легко развернуть, но неэффективны и наоборот. Поэтому в конечном итоге решение лежит на вас - разработчике программного обеспечения.

Пожалуйста, поправьте меня, если я ошибаюсь.

Ответ 8

Линия между данными и кодом (программа) размыта. Это, в конечном счете, просто вопрос терминологии - например, вы могли бы сказать, что данные - это все, что не является кодом. Но, как вы писали, они могут быть смешаны вместе (хотя обычно лучше держать их отдельно).

Ответ 9

Данные - это информация. Это не о том, где вы решите поместить его, будь то db, конфигурационный файл, config через код или внутри классов.

То же самое происходит и для поведения/кода. Это не о том, где вы решите поместить его или как вы его представляете.

Ответ 10

Я бы сказал, что различие между данными, кодом и конфигурацией - это что-то, что нужно сделать в контексте конкретного компонента. Иногда это очевидно, иногда меньше.

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

В вашем случае вы, похоже, описываете вариант особо мощного файла конфигурации, который может содержать код. Так же, как, например, GIMP позволяет вам "настраивать" плагины с помощью Scheme. Как разработчик компонента, который читает эту конфигурацию, вы можете думать об этом как о данных. Когда вы работаете на другом уровне - записываете конфигурацию, вы можете думать о нем как о коде.

Это очень мощный способ проектирования.

Применяя это к основному вопросу ( "Как бы вы закодировали приведенный выше пример?" ), одним из вариантов может быть принятие или разработка высокоуровневого доменного языка (DSL) для указания правил. При запуске или при первом требовании сервер считывает правило и выполняет его.

Предоставить административный интерфейс, позволяющий администратору

проверить новый файл правила
замените текущую конфигурацию на новый файл правила

... все это произойдет во время выполнения.

DSL может быть чем-то таким же простым, как синтаксический анализатор таблицы или парсер XML, или он может быть чем-то сложным, как язык сценариев. С C легко вставлять Python или Lua. Из Java легко вставлять Groovy или Clojure.

Вы можете скомпилировать скомпилированный код во время выполнения, с умными связями или трюками загрузчика классов. По-моему, это кажется более сложным и менее ценным, чем встроенный параметр DSL.

Ответ 11

Взаимосвязь между кодом и данными выглядит следующим образом:

код после компиляции в программу обрабатывает данные во время выполнения

программа может извлекать данные, преобразовывать данные, загружать данные, генерировать данные...

Также программа может извлекать код, преобразовывать код, загружать код, генерировать код tooooooo...

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

Например,

Исходные коды Sourcecontrolsystem

здесь исходный код сам является кодом

Файлы сценариев резервного копирования

здесь файлы - это данные и т.д.

Ответ 12

Лучший практический ответ на этот вопрос, который я нашел, таков: Любой класс, который должен быть сериализован, теперь или в обозримом будущем, является данными. Все остальное - это код. Вот почему, например, Java HashMap - это данные, хотя у него много кода, методы API и конкретная реализация (т.е. может выглядеть как код на первый взгляд).

Ответ 13

Огромная разница. Данные передаются системе, а код является частью системы.

Неверные данные бессмысленны: наш код === обработчик хорош, и то, что вы положили, что вы берете, это не проблема системы, если вы имели в виду что-то другое. Но если код плохой - система плохая.

Например, давайте рассмотрим немного JSON, плохой код parser.js мной и скажем, хороший V8. Для моей системы плохой parser.js - это код, и моя система работает неправильно. Но для системы Google мой плохой парсер - это данные, которые никоим образом не говорят о качестве V8.

Вопрос очень практичный, не сложный. https://en.wikipedia.org/wiki/Systems_engineering пытается заработать хороший ответ и деньги.